Skip to the explainer
Those Dark Arts Authority

Interactive explainer · Authority

Approve the Change, Not the Name

Ines asks a drafting agent to tighten one section of her field notes. Who is allowed to make that change, what does the document service actually check when the write arrives, and what happens if the request or the document moves after she says yes? This is an invented example: no real system, person or incident. Follow the guided route, or change any control and the service re-runs its nine checks on your combination.

Free exploration
    Commit attempt at 10:06
    The delegated edit The grant, the approval and the request arrive at the document service, which runs nine checks and either writes or refuses. The result is stated in words beside this drawing.
    • check passed / approved write
    • check failed / harm flag
    • not checked
    • delegated authority
    • the agent's request

    Free exploration

    Your own combination

    Technical notes

    The drawing and the sentences are computed in your browser from the same rules as the technical companion's reference model: the grant is a real (toy) HMAC caveat chain, versions are the first twelve hex digits of SHA-256 over each section's text, and the approval digest is SHA-256 over the canonical description of the change. Nothing is looked up from a table and nothing is live: the clock is a fixed story clock.

    The nine checks, in the order the service runs them

      Every check is evaluated even after one fails, so every reason for a refusal is visible. A check shown as not checked was skipped by the service's configuration; it did not pass.

      Initial inputs (what Reset restores)

        Assumptions that keep the example honest

        • The grant is a simplified illustration of macaroon-style attenuation: each caveat narrows it, and a holder can add a caveat but cannot remove one without breaking the chain. It is not an OAuth token format.
        • The version check (C8) and the write happen in one step. If they were separate, Tomas's edit could land between them and be lost anyway.
        • C8 compares current bytes with the approved base. An edit that is later restored to identical bytes passes; revision history is outside the model.
        • The approval is recorded by Ines's own authenticated interaction with the service; the agent cannot write to that record. The digest identifies bytes; it is not a signature or proof of consent.
        • C3 verifies a proof key associated with the agent when the grant was issued. It identifies a key, not a person or an operating-system process, and says nothing about the content of the request. With a bearer grant no sender is verified at all.
        • In the bypass mode the service still verifies the grant's chain, audience, presentation, expiry and revocation. It has the same storage privilege in both modes; what changes is whether it checks the delegated request.
        • These nine checks implement this example's policy of approving one exact edit. Standing permissions, owner-applied changes and merge-aware approvals are legitimate designs with different checks.
        • "Harm" means one of five flags defined against what Ines asked for. It is not a security rating.

        Across every combination of the controls

        Opening these notes computes the model over every combination of the eight controls.

        Read the full derivation, the standards and their scope in the technical companion, or the argument in plain prose in the article.