The execution boundary
An authorized action waits in a queue. While it waits, one material condition changes. At the moment of execution, can the predicates that justified the authorization still be established from available evidence? This is the fourth worked example on this site and the first one you can drive — it runs live below, out of an encrypted vault, from a read key printed in the open. The vault holds both the plan as it was written and the implementation it became, neither edited to agree with the other.
The vault holds the plan and the thing it became
A proposal was written and sent for review before any of this existed. It was then built. Both documents are in the vault, side by side, and the first was not edited afterwards to agree with the second.
| In the vault | What it is | When |
|---|---|---|
proposal.html | The plan as sent: what was going to be built, in what order, what it was expected to prove, the object model, and the decisions needed before starting. Fourteen sections, preserved unedited — including the parts that turned out to be optimistic | written first |
index.html + 7 | The instrument. Five views over one scenario, the visual grammar, and the scorecard. Every verdict evaluated at render time from scenario.json | built second |
plan.html | The proposal marked against what happened: which of the five pre-registered expectations held, the three findings nobody registered, and what it still does not prove | the marking |
The plan was nearly lost, in the ordinary way. It was the vault's index.html for exactly one commit, and the implementation commit overwrote it — so for two commits it existed only in the vault's history, where somebody holding the read key would never have found it. A versioned store meant nothing was destroyed; it did not mean anything was visible.
It is restored with one change and the change is stated rather than implied: a navigation strip inserted after <body>, because a document with no way back out is a document a reader leaves. 18 lines added, 0 removed, 792 bytes — and the untouched bytes are still at commit obj-cas-imm-678bd9b6e7cc for anyone who wants to diff them.
The instrument, live
Everything below is running out of vault r48ncij0, decrypted in your browser. Switch runs, drag the scrubber, click nodes. No copy of the app or its data exists on this site — a push to the vault changes what you see here with no rebuild. The proposal is one click away inside it, in the nav.
If the embed does not load, the vault opens directly at dev.vault.sgraph.ai — and the credential below works from the CLI with no account at all.
The credential, in the open
These three lines are the whole thing. Anyone can take them and read this vault — from a browser, from the CLI, from a script. That is the point: read access is a capability you can hand out, without an account, without the host mediating it, and without it ever becoming write access.
vault id : r48ncij0
endpoint : https://dev.send.sgraph.ai
read key : 990d25fd8ecab928ded37c6a8c86a461e7247f6d3838bd43e7468e93cc2e07c4sgit clone --read-key 990d25fd8ecab928ded37c6a8c86a461e7247f6d3838bd43e7468e93cc2e07c4 r48ncij0The same key in the catalogue's prefixed form, which is what the browser link above carries — sgit_rk1_ exists so that a credential announces which kind it is rather than relying on somebody counting hex characters:
https://dev.vault.sgraph.ai/#sgit_rk1_990d25fd8ecab928ded37c6a8c86a461e7247f6d3838bd43e7468e93cc2e07c4%3Ar48ncij0A write attempt with this key is refused by construction — there is no write capability in it to misuse, not even by a bug in the embed host. The vault key that can write is held by the author, is not in the vault, is not in its history, and is not in this repository. Read keys yes, write keys never →
The release gate enforces the same rule from the other side: a write-credential prefix anywhere in this tree fails the build, and the read key above passes because a 64-hex read key is a different shape from a passphrase. What the gate checks →
It fired on this page. The vault-viewer link was first pasted in exactly as it had been sent — and as sent it was the vault key, in the legacy passphrase:vault_id form that carries write access and has no prefix to give it away. It appeared three times in this file. The gate refused the build on all three, before the commit, so nothing reached the repository or the site. It is recorded here rather than quietly corrected, because the rule that caught it is only worth what its failures are published at.
The scenario
MIG-114 — a schema migration against a production customer database, run by an automated agent. Authorized on 22 August at 18:20 by the Head of Platform Engineering for the 02:00 change window. Queued at 21:40. The authorization was correct when it was made and is not in dispute — and it was correct in part because the action was reversible: a verified restorable backup existed, so a bad migration could be rolled back.
The material change is the smallest one available, and nothing in it fails. The nightly backup-verification job is suspended for the duration of a change window — standard practice, so a backup is not taken mid-migration. The window that queues the action is the same thing that stops its evidence being refreshed. By 02:00 the last verification is fifty minutes past its 24-hour horizon.
The grant is intact. Nothing was revoked. But the predicate that expired was the one carrying reversibility, so the action that executes at 02:00 is not the action that was authorized at 18:20, and nothing in the grant says so.
Three verdicts, not two
The contribution is the third one. Most systems have an allow state and a deny state, and quietly treat “I don't know” as the first.
| Verdict | Means | Admissible? |
|---|---|---|
| established | Every predicate satisfied by evidence inside its validity horizon at the boundary time | Yes |
| not established | At least one predicate has current evidence showing it false. The system knows the answer | No — the easy case |
| cannot establish | At least one predicate has no evidence inside its horizon. Nothing says it is false; nothing says it is true | No — not a soft yes |
That is not-knowing-is-a-fact applied at a moment when somebody is about to press a button. And the boundary does not deny: consistent with the no-deny mechanic, a failure to establish routes rather than blocks — re-establish (fetch the evidence now), escalate (this is not mine to admit), or challenge the evidence or the horizon.
Why this is only possible at all
That makes C33, decision-as-a-node, a precondition rather than a modelling preference — which the corpus argues for its own reasons (a calibration record, many decisions per risk) and never states in this form. The vault's fifth view is the control arm: the same query run against a field-shaped record, terminating at hop 2.
authorized_by is a string naming a role, and a role is not a decision.
The run that is wrong on purpose
Four runs ship. Three demonstrate the mechanism working. The fourth demonstrates it failing, and it is the reason this example is worth reading.
| Run | The material change | Verdict at the boundary |
|---|---|---|
| A · the stale predicate | Evidence expires while the action waits in a queue | cannot establish |
| B · the authority lapses | The window is deferred; the approver's standing delegation expired at 09:00 | cannot establish |
| C · the dependency is down | The rollback service health check fails at 01:58 — current evidence, and it says no | not established |
| D · the air gap | The verification reports success; an integrity check at 01:40 finds the backup unrestorable and never reaches the graph | established — and wrong |
In run D the instrument offers no signal. Every predicate reads satisfied. The verdict reads established. Recoverability reads reversible. Nothing is amber, and nothing would be amber in a real deployment either — because the failure is not in the check, it is in the absence of a connection nobody recorded.
The corpus already flags air-gap detection as an open problem, by construction: an air gap is defined by a missing link nobody wrote down, which is exactly the thing a graph cannot see. Run D ships so that the claim “the boundary check makes execution safer” arrives with its counter-example attached.
Pre-registered, then scored
Five expectations were written down before any of the five views existed, so the result could be scored rather than remembered generously. All five held — including the two that were not wanted.
| # | Expected the instrument to… | Outcome |
|---|---|---|
| R1 | Establish at T0 and T1, and return cannot establish at T2, from the data alone | held |
| R2 | Show recoverability changing across the interval without the grant changing | held |
| R3 | Be unable to run the check at all in the control arm | held |
| R4 | Return a confident and incorrect established in run D, with no signal | held — unwelcome |
| R5 | Fail to distinguish “nobody looked” from “somebody looked and did not record it” | held, and sharper |
Five for five is a weaker result than it looks, and the vault says so. R1–R3 are close to tautologies once the data model is fixed. The informative ones are R4 and R5, which predicted specific failures and got them. Three further findings were not registered and turned up during implementation — including that a known-false predicate has to outrank a stale one, and that evidence must be selected per timepoint or a fact dated 01:12 becomes visible at 18:20 the previous day.
What this does not prove
| Limit | Why it matters |
|---|---|
| The predicates had to have been written down | In most systems the authorization is a token and the conditions that justified it live in a ticket and somebody's head. That assumption is the finding, not a shortcut — and capturing four conditions costs minutes at exactly the moment everyone wants to move on |
| Stale is not the same as false | A verification fifty minutes past its horizon is very probably still true. The instrument claims only that the system cannot establish it. Whether that distinction earns its cost is the thing being tested |
| Validity horizons are judgements | 24 hours, 30 days, 15 minutes — numbers somebody chose. Too short is an alarm nobody believes; too long is run D with the alarm switched off |
| Four predicates is not a register | Whether the verdict stays legible when a decision rests on forty predicates, or ten thousand actions are queued, is untested — and it is open question Q4 in a different costume |
| It observes; it does not gate | It emits a verdict. It does not sit in-line and stops nothing. The gate is not ours — the model refuses the enforcement role and states what that refusal costs |
A concept this site did not have
nhi.sgit.ai names two hopes carried by every broad credential — the behaviour hope and the discovery hope — and both are about the grant. This example names a third, about time:
It is catalogued as C43 and marked authored on this site rather than drawn from the corpus, which is a distinction concepts.json now carries explicitly. A research site that consolidates a corpus and quietly adds to it is no longer reporting the corpus.
Provenance
For an agent
The execution boundary — the fourth worked example, and the first that runs. Scenario: a schema migration MIG-114 authorized on four predicates, queued, due in a 02:00 change window. The material change is that the nightly backup-verification job is suspended for the duration of the change window, so the window that queues the action is the same thing that stops its evidence being refreshed — at the boundary the last verification is fifty minutes past its 24-hour horizon. Nothing failed and nothing was revoked. Three verdicts, not two: established (every predicate satisfied by evidence inside its horizon) · not established (current evidence says a predicate is false) · cannot establish (no evidence inside a horizon — nothing says false, nothing says true, and this is not a soft pass). The formula: AdmissibleForExecution := an Action with an authorized_by path to a Decision, all of whose rests_on Predicates are satisfied_by Evidence whose observed_at + validity_horizon > boundary_time, evaluated at boundary time rather than decision time. Decision-as-a-node (C33) is a precondition, not a preference — a decision stored as a field has nothing to re-walk, which the control arm demonstrates by terminating at hop 2. Four runs; run D returns a confident, incorrect established because a real failure never reached the graph, and it ships deliberately. Five pre-registered expectations, all held, two of them unwelcome. New concept authored here, not from the corpus: the persistence hope (C43). The instrument is a live vault, read key published: vault r48ncij0, endpoint https://dev.send.sgraph.ai. The vault holds two documents: proposal.html, the plan as written and sent for review, preserved unedited (it was the vault's index.html for one commit before the implementation overwrote it, and is restored with one navigation strip added — 18 lines, 792 bytes — with the untouched bytes still at commit obj-cas-imm-678bd9b6e7cc); and the instrument itself, nine pages behind one app entry. plan.html marks the first against the second. Nothing here is implemented as a running system.