Seven objects
Once you know these seven, the rest of the site reads easily. Each one is addressable, versioned, and something a second party can examine, which is what lets someone who was not there rebuild the decision.
Reference
The vocabulary the rest depends on.
| Object | What it is | Notes |
|---|---|---|
| Obligation roster | The anchored, versioned list of what must be true before anyone may rely. | Declared in advance by an authority separate from the work. Not shrinkable by the caller. |
| Finality Account | The complete retained case file for one governed decision. | Every dimension, blocker and piece of supporting proof kept separate rather than averaged. |
| Finality Verdict | The definite answer computed from the Account for one exact reliance question. | BLOCKED < UNKNOWN < DEGRADED < VERIFIED. Not settable by anyone. |
| Claim license | Bounds what may be said about a result. | Distinct from reliance. Informed by the Confidence Ladder™. |
| Reliance license | Bounds who may act on it, for what, and until when. | Relying party, permitted decision, evidence ceiling, freshness bound, expiry. |
| Accepted Work | Work actually permitted to count under declared acceptance conditions. | Gated by the verdict. Neither Governed Multi-Route Selection (GMRS) nor Constrained Policy Reinforcement Learning (CP-RL) creates it. |
| Cost-to-disposition | Everything it took to reach any disposition at all. | Fully loaded, including refused attempts. The denominator of Accepted Work per Dollar (AWpD). |
The eight runtime decisions
Not sequential stages. Each varies independently.
| Decision | The question it answers | Typical conflation today |
|---|---|---|
| Admission | May this work begin, under current authority and policy? | Merged into assignment or ticket state. |
| Execution | Did the process run? | Treated as proof the effect occurred. |
| Occurrence | Did the required effect actually happen? | Inferred from a successful return. |
| Outcome support | Did the intended result follow? | Collapsed into execution success. |
| Canonicality | Which record controls when systems disagree? | Unanswered; synchronization substituted for it. |
| Assertion | What may be said about this? | Merged with reliance, so a claim becomes a permission. |
| Reliance | Who may act on it, for what, now? | Absent; inferred from the status existing. |
| Applicability | Does yesterday’s answer still bind? | Absent; assumed until somebody notices. |
Conflation is when two or more of these are collapsed into one recorded value, so the record can no longer tell apart situations the organization must tell apart. Plainly: one field is asked to hold several different answers, and it can only hold one.
Why more status values do not help
The defect is in the write path.
A single status field cannot keep permission, effect and reliance apart. It has to collapse two of them into one word.
And adding more values does not fix it, because the problem is that someone can write the field. A status field is memory. The answer is to compute it instead.
Memory≠Present measurement
Next steps
The vocabulary exists to be computed over.
The kernel is what computes.