ADR 0006: Addresses and action envelopes

Context

Step 0 proved that a storage source can be separated from a trusted projection contract. Step 1 applies the same discipline to actions: API, CLI, DOM, GUI, email, Stow, agents, and future transports need one representation of who is acting, on what target, with what claimed context and authority, and what the trusted system says happened.

Without a shared address and envelope grammar, each adapter would invent identifiers and action shapes that later become accidental canonical models.

Decision

Pre adopts a bounded canonical address syntax:

<kind>:<segment>[:<segment>...]

Addresses are lowercase ASCII, colon-separated, and bounded to 255 characters. The initial grammar permits lowercase letters, digits, hyphen in the kind, and lowercase letters, digits, dot, underscore, tilde, and hyphen in segments.

Examples:

human:pace
agent:pre:research-01
controller:local-main
task:grant-review:01k123
request:01kstep1a0000000000000000

Colon-separated segments provide namespacing and readability only. They do not imply ownership, ancestry, authority inheritance, membership, or permission.

The initial registered kind vocabulary is informative rather than a closed parser enum. Unknown syntactically valid kinds may be carried forward by generic infrastructure, but a participant must not invent semantics for an unrecognized kind.

Step 1A also adopts two versioned envelopes:

• pre.action.v1 represents a participant's request;
• pre.result.v1 represents the trusted boundary's disposition and result.

An action envelope carries a request: address, participant, acting identity, source interface, context-grant references, intended action, target, claimed authority references, bounded JSON input, caller-visible risk class, idempotency key, expected-evidence descriptors, and canonical UTC issue time.

claimedAuthority is never permission by itself. Step 1B will define how a trusted boundary resolves identity, memberships, grants, capabilities, expiry, revocation, and policy into resolvedAuthority.

A result envelope keeps three questions separate:

admission: did the trusted boundary accept or deny the request?
execution: did the admitted operation run, succeed, fail, or remain pending?
objective: was the underlying objective verified, not met, not applicable, or still unverified?

A successful execution therefore cannot silently become a verified objective. verified objective status requires a durable verdict reference.

Deferred

Step 1A does not settle:

• authority resolution or capability semantics;
• context-grant contents or inheritance;
• event ordering and receipt semantics beyond addressable references;
• evidence sufficiency or objective-verdict structure;
• external-binding conflict rules;
• succession semantics;
• persistence technology or Har ownership.

Those remain Step 1B through Step 1E work.

Consequences

• protocol clients can exchange stable identifiers without sharing a database schema;
• address syntax cannot be mistaken for an authorization hierarchy;
• self-asserted authority remains visibly distinct from trusted resolved authority;
• API, CLI, HARnest, Stow, mail, and later surfaces can use the same action shape;
• process success and objective verification are structurally distinct;
• future storage engines implement these contracts rather than defining them.