Accepted as a distinct terminal status
LOGOS must distinguish between two fundamentally different
terminal states for any topic with a workflow: Done, meaning
the issue is resolved, and Accepted, meaning the constraint
is consciously acknowledged and will be lived with. These
are not the same thing and conflating them misrepresents
the nature of the content.
Why It's Needed
This distinction was discovered while choosing a topic type
for Talkyard limitation records. The Problem type offers
Done as its terminal state — implying resolution. But
Talkyard limitations are not being resolved. They are
constraints of an interim platform that are being
consciously accepted for as long as LOGOS runs on Talkyard.
Marking them Done would be false. Leaving them open
indefinitely would imply they are being actively worked
on. Neither is accurate.
The same distinction applies broadly. A CORTEX limitation
may be accepted as a known gap in the current maturity
stage. A NEXUS methodology gap may be accepted as outside
scope for now. A design decision may be accepted as a
deliberate tradeoff. In each case the honest status is
not Done — it is Accepted.
The Requirement
Any topic type with a workflow status model supports
Accepted as an explicit terminal state, distinct from Done.
- Done — the issue is resolved, the requirement is
satisfied, the work is complete - Accepted — the situation is consciously acknowledged,
understood, and deliberately not being resolved — either
because resolution is out of scope, deferred, or a
conscious tradeoff
Both are terminal — no further action is implied. But they
carry different meaning and that meaning should be
preserved in the record.
Accepted Is Not Giving Up
Marking something Accepted is an active decision, not a
passive one. It means: we have looked at this, we
understand it, and we are choosing to live with it for
stated reasons. The reasons should be recorded in the
topic. A future reviewer can see both the constraint and
the reasoning behind the decision to accept it.
Acceptance
A topic in any workflow-enabled type can be moved to
Accepted status. The status is visually distinct from
Done in topic listings. The transition to Accepted is
an event with author and timestamp. A topic marked
Accepted can be reopened if circumstances change —
the acceptance was a decision at a point in time,
not a permanent seal.
Sources
- LOGOS → Requirements → Custom topic types with definable status workflows (Accepted is a required status in the custom type system)
- LOGOS → Talkyard Limitations → No custom topic types or type-specific workflows (the situation that exposed this gap — limitations needed Accepted, not Done)