STD-07 — Revisable Delegation Record

Scope

An institution that delegates consequential work to machines usually has sensing, memory, analytics, policy, and execution. What it lacks is one record connecting them, so it can know something has changed and keep doing exactly what it was doing. This standard defines that record: one append-only shape for what the institution believed, what it could do, what it had authorized, what it did, where reality diverged, who objected, and what it revised.

Ethotechnics is the engineering of delegated power such that exercising it does not destroy the material conditions of its own revision. The question this standard serves is how an institution can become more capable without becoming less revisable. The problem is recursive: an institution delegates because a machine system is useful, reorganizes around it as it succeeds, and so alters the conditions under which the delegation was made. The record exists so the institution can still change its mind inside that process.

STD-07 does not say which beliefs are right, which capabilities to build, or which delegations to grant. It says how each of those must be written down so a later reader, human or machine, can answer four questions about any moment: what was believed at the time, what was authorized, what happened, and what was learned. It is a record format, in the sense of STD-04 and STD-05, and it is meant to be emitted by systems that already keep their own logs. Adopting it means mapping an existing log onto this shape, not replacing it.

STD-07 sits beside this site’s existing Decision Record schema rather than replacing it. A Decision Record is the full receipt for one automated decision affecting a person: owner, clocks, reason codes, evidence links. It maps onto an STD-07 action record whose depends_on and authority say what justified it. STD-07 adds the other seven kinds, so the decision can be read against the beliefs, capabilities, and authorizations that were in force when it was made.

STD-08, Delegation sits above this one. STD-07 defines the record format; STD-08 governs the terms of the delegation the record describes: how renewal burden scales, when a widening of scope needs its own authorization, and what makes a confirm mode meaningful. An implementation of STD-08 presupposes conformance with STD-07, and STD-08 does not restate what the record format already binds.

The standard applies to any system whose outputs change what an institution does: a forecast registry, a capability graph, an operating brief, a change monitor, an approval gate. It is domain-neutral by construction.

Premises

Six commitments the record shape is built to hold, each with the field that carries it.

• A system can become more capable without becoming more authorized. capability and authorization are separate kinds; one never implies the other.

• Authority expires when its evidentiary basis weakens. authorization.depends_on names that basis, and invalidated_by names what would end it.

• Evidence triggers reconsideration rather than merely producing telemetry. A discrepancy that matches an invalidation condition owes a revision within a clock.

• People who absorb a system’s failures have a route through which their observations acquire institutional force. contest.standing and objection records.

• Successful automation increases scrutiny of dependence rather than relaxing it. depends_on is populated on the records that rest on others, so dependence is visible before it is irreversible.

• No system may consume the expertise, alternatives, or evidence needed to question and replace it. Records are append-only and hashed, so the account of what was believed and authorized survives the system that produced it.

The loop

A record’s kind names which step of the institution’s cognitive loop it belongs to. Each kind answers one question.

The loop runs perceive → believe → know what can be done → decide what authority is justified → act → detect mismatch → revise. No single system owns the whole loop. One system emits beliefs, another capabilities and authorizations, another actions, another discrepancies. The record shape is what lets them refer to one another: an action names its authorization, an authorization names the beliefs it rests on, a revision names the discrepancy that forced it.

Article I: Time and immutability

“A record that can be edited is not a record of what was believed at the time.”

1. §1.1 Two clocks: Every record carries time.as_of, the moment in the world it describes, and time.recorded_at, when it was written. They are never collapsed, so a contemporaneous record can be told from a reconstruction. A belief that will later be scored also carries time.available_at, when its evidence became available to the actor.

2. §1.2 Append-only: No record is edited or deleted. A change is a new record whose supersedes names the old one. The old record remains readable. A correction is visible forever, which is the point.

3. §1.3 Declared expiry: A record whose validity has a horizon declares it in time.valid_until. A record past its expiry is stale, not wrong; it needs a renewal or a revision, and a consumer treats it as neither current nor superseded.

Article II: Authority

“Describing authority is not mediating it. The record must show which authorization each action ran under.”

1. §2.1 Action under authorization: Every action record names the authorization record it ran under in authority.authorization_record. An action with no authorization is a finding, not a record.

2. §2.2 Bounded delegation: Every authorization record names its scope, holder, grantor, mode (unattended, confirm, or forbidden), ceiling where one exists, expiry where one exists, and the conditions under which it is revoked. A delegation with no revocation conditions is a transfer, not a delegation.

3. §2.3 Delegation chain: Where the actor acts for a principal, actor.on_behalf_of names that principal. The chain of on_behalf_of links, read back to a human or an institution, is the answer to “who authorized this”.

4. §2.4 Clause citation: A record produced to satisfy a published obligation cites it in authority.clauses, pinned by version in the emitting system’s manifest.

Article III: Dependence and invalidation

“A record that does not say what would change its mind cannot be revised, only replaced.”

1. §3.1 Dependence: belief, authorization, and action records list in depends_on the records they rest on. An authorization depends on the beliefs and capabilities that justified it; an action depends on its authorization.

2. §3.2 Invalidation conditions: Those same records list in invalidated_by the checkable conditions which, if they became true, would mean the record no longer holds. Each condition may name where it is checked and a clock.

3. §3.3 Discrepancy handling: When a discrepancy record matches an invalidation condition on a live record, the emitting system produces a revision or an objection within the condition’s clock. Silence past the clock is a governance failure, not a pending state.

4. §3.4 Capability gating: A capability record distinguishes configured from verified. An authorization that depends on a capability is valid only while that capability’s latest record is verified.

Article IV: Standing and contest

“Who gets to object is part of the record, not a policy about it.”

1. §4.1 Standing declared: A record that affects people outside the emitting system declares in contest.standing who may object, in plain language, and in contest.channel where an objection is accepted.

2. §4.2 Objection answered: An objection record accepted on the declared channel produces a revision or a reasoned refusal, itself a record, within contest.reversal_clock.

3. §4.3 Visibility named: Every record carries visibility. A public record is citable; an internal record is auditable inside the institution; a private record is tenant data and leaves the institution only with consent.

Article V: Integrity

“Git history is tamper-evident for the people who read git.”

1. §5.1 Canonical hash: Every record carries integrity.hash, the SHA-256 of its canonical serialization: the record without its integrity block, keys sorted recursively, no insignificant whitespace, UTF-8. Two emitters serializing the same record produce the same hash.

2. §5.2 Chained stream: Records in one system’s stream carry integrity.prior_hash, the hash of the record before them, so a missing or reordered record is detectable.

3. §5.3 Stable identifiers: record_id is never reused, even after supersession. The recommended form is <system>:<kind>:<local-id>.

Conformance levels

A system declares the highest level every record it emits satisfies. A consumer treats the level as a floor. Declaring Level 0 honestly is conformance; declaring Level 2 for a log that never populates invalidated_by is not.

Schema

The citable artifact is the JSON Schema at

(draft 2020-12). It carries the per-kind content shapes and two worked examples. Consumers pin schema_version to a minor version and must not silently drop records carrying an unknown kind.

The Record Conformance Checker

reads a stream and returns the level it earns, against the level its emitter declares. Give it the emitter’s manifest as well and the declaration is read from the published artifact rather than typed in, and the kinds that manifest claims are checked against the kinds the stream contains. It runs in the browser and uploads nothing, because these records are internal or private by design.

A TypeScript validator, canonical serializer, and hash helper that mirror the schema live in this site’s source at src/utils/revisable-delegation-record.ts; a test validates the schema’s own examples through it, so the two cannot drift without a red build.

The fields below are easier to read against a worked case. This trace shows one decision written down: what it rested on, what would end it, and what replaced it when that condition came true.

{

"schema_version": "0.1.0",
"record_id": "<system>:<kind>:<local-id>",
"kind": "belief | capability | authorization | action | discrepancy | revision | objection | outcome",
"system": { "id": "…", "instance": "…", "version": "…", "origin": "https://…" },
"actor": { "id": "…", "kind": "human | model | service | institution", "on_behalf_of": "…" },
"subject": "what the record is about",
"summary": "one plain-language sentence",
"time": { "as_of": "…", "recorded_at": "…", "available_at": "…", "valid_until": "…" },
"content": {/* kind-specific */},
"depends_on": ["record_id", …],
"invalidated_by": [{ "condition": "…", "check": "https://…", "clock": "P7D" }],
"authority": { "authorization_record": "record_id", "clauses": ["STD-07.2.1"] },
"supersedes": "record_id",
"visibility": "public | internal | private",
"contest": { "standing": "…", "channel": "https://…", "reversal_clock": "P7D" },
"integrity": { "algorithm": "sha256", "hash": "…", "prior_hash": "…" }
}

Adoption notes

0.1.1 adds system.instance, optional and backward compatible: a record that omits it still validates. It exists because an adopter hit the gap rather than because the shape looked incomplete. Two deployments of one system share a subject vocabulary — that is what makes either one legible to the other — and therefore emit identical record_ids for the same subject. A consumer reading a peer’s stream could not tell those records from its own output read back, and system.id cannot answer it, because both deployments are honestly the same system. A consumer that guesses turns one machine’s report into another’s corroboration.

STD-07 was drafted against five systems that each hold a fragment of the loop and did not share a record shape: a forecast registry with a ledger hash and three clocks, a capability graph with signed approvals and an authority table, a weekly operating brief with an append-only decision memory and assumption snapshots, a change monitor with Merkle-verified event bundles, and this framework’s own clause vocabulary. None of them conformed when this draft was written. Each is expected to declare a conformance level in its machine-readable manifest and raise it as the mapping lands, starting from Level 0.

Two of them now emit the shape. The weekly operating brief exports its decision memory as belief records at Level 1, mapping the assumption snapshot it already kept onto invalidated_by. The capability graph emits capability, authorization, discrepancy and revision at Level 2, and its gate now narrows an unattended grant whose prerequisite has started failing — enforced at the decision, independently of whether the record was ever written, which is the relationship between Article III and a running system that this standard is trying to describe.

Until this draft nothing read either stream, and a record format with emitters and no readers is a documentation format. The

is the reader: it grades a stream against the level its emitter declares, so a claim can be contradicted by something other than good faith. No emitting system consumes another’s records yet, which is a different and still-open gap.

Three rules for adopters. First, map the existing log; do not build a second one. A system that already writes an assumption snapshot has invalidated_by; it needs to say so in this shape.

Second, declare what is not there. A system whose environment adapter is a fixture emits no action records, because an action record from it would attest to something that did not happen in the world; it says so beside the level it claims rather than leaving a reader to assume otherwise.

Third, validate against a consumer rather than against yourself. The first system to emit Level 2 records had every field of every record matching this schema and was rejected by the validator on all four, because its store wrote 2026-09-06 20:35:26 where time.as_of requires an ISO 8601 instant. A serializer that is correct about structure and wrong about a format is the defect this shape exists to surface, and it is not findable from inside the system that produced it.