Capabilities and Writs

Archipelago represents authority as a signed capability. A capability names its subject, verb, scope, issuer, parent, expiry, and revocation status. The Effect Interpreter checks it before an authorized mutation reaches the event store.

A writ is the same authority materialized as an entity. It can carry a name and brief, appear as a copper disc in the fiction, and render its grant, scope, issuer, expiry, attenuation, and revocation terms without exposing signature bytes.

What the engine can do

The domain implementation can:

• mint and verify signed capabilities
• restrict scope by entity, tag, or realm
• delegate along a narrowing chain
• expire and revoke capabilities
• issue, transfer, attenuate, and revoke writ entities
• cascade revocation through descendant writs
• render a writ safely when examined

The chain narrows. A child cannot gain a broader verb, wider scope, or later expiry than its parent.

Current player surface

Writ examination is integrated with perception, and capability checks protect build/admin transitions and effects. The public SSH login does not yet load account capabilities, and there are no complete player commands for transferring or attenuating a writ.

Older examples that showed watch> issue writ ... or promised that carrying a disc automatically opened a particular door were ahead of the command wiring. The authority model exists; the full diegetic workflow does not.

That distinction is temporary but important. A sealed token in a unit test is not yet a social object in a live realm.