Live on this site fixture data

Your rules, visibly enforced.

Grant a function access to one field. See the result. Watch it get refused for a private field. Revoke, retry, and see the retry fail. Every decision is enforced between the function and your data, and written down.

Scene state is announced in the trace below; the picture carries no information the trace does not.

Six steps, sixty seconds

Switching language (NL · EN in the header) opens the other language's page at its top and restarts the demonstration; nothing you did here is kept.

  1. 1
    StartCreate the sample data (a week of calendar events, one private note, three contacts). Nothing leaves this tab.
  2. 2
    GrantGive the scheduling assistant access to your free time only.
  3. 3
    RunIt proposes three slots. It also asks for your event titles, and is refused.
  4. 4
    Watch the refusalThe brief writer asks for your private note and your contacts without any grant.
  5. 5
    Revoke and retryTake the grant back and run the assistant again. It fails, and says why.
  6. 6
    Reset, or play freelyGrant and revoke any field for either function below, then run.

Permissions live on this site

Function fixture

Each grant is for one function and one field. A function can only reach a field through the policy, which writes every decision to the trace first.

Result fixture

Press Start.

Trace live on this site

Nine fields per decision: used, permitted, objective, actor, action, contacted, why, rule, result.

    Network measured

    – resource requests observed · – fetch/XHR attempts

    Two separate counters, both since you pressed Start: resource requests this page's browser observed (PerformanceObserver), and fetch or XHR calls this page attempted (counted at send). They are a measurement of this page in your browser, not proof about anything else.

    What this proves live on this site

    • one bounded workflow of individual control: grants, refusals and revocations enforced at the point of data access
    • the enforcement is not the picture: the function's output changes because the read was allowed or refused — read, run and reproduce the contract
    • every decision is written to a nine-field trace you can read and export

    What it does not prove architecture

    • a complete Agent of One: the two functions are fixtures with no side effects; no appointment is made, nobody is contacted
    • anything about servers: the request counter measures this page only
    • the origin's independence: the verification below shows consistency with what this origin published, not independence from it

    Export, verify, then tamper live on this site

    Verify the site that served this page

    Every page and asset this site serves is listed in a manifest with its sha256 — all but the manifest itself and its signature; the manifest is signed with the site's Ed25519 release key. Your browser downloads the manifest, its signature, the key and the listed static files from this origin and checks them here; the exported trace and the tamper check below stay in your browser. Outside this scope: the lead endpoint and anything a server executes.

    1 · Signature and files measured in your browser

    Fetches /built-manifest.json, its signature and the public key from this origin, verifies the Ed25519 signature with WebCrypto, then downloads every listed file and compares its sha256 with the manifest.

    filesha256 observedbytes

    2 · Tamper with an export measured in your browser

    The trace you export above carries a sha256 digest over every field of the export except digest and digest_of (keys sorted), and names the release it accompanied. Load it here, change any covered value — a rule, a field, a timestamp, the fixture flag — while keeping the original digest, verify again: the digest no longer matches and the first changed field is named. Changing only digest_of is not detected, and an edit whose digest was recomputed matches again: the digest is unsigned.

    What this proves live on this site

    • asset consistency: what this origin serves right now matches the manifest it published, file by file, hashed in your browser
    • signer attribution: the manifest was signed by the holder of the key whose public half this origin publishes
    • change detection: while the original digest is kept, an edit to any covered value of an export no longer matches its content digest and the first changed field is named; digest and digest_of are not covered, and a recomputed unsigned digest matches again

    What it does not prove boundary

    • the origin's independence: key, manifest and verifier all come from the same origin; compare the manifest sha256 printed on /built with one you obtained elsewhere
    • complete execution or exclusive storage: a signed manifest says what was served, not what every part of a system did
    • who produced an export: its digest is unsigned; it detects a change of the text, not its author