---
title: "ADR 0006: Addresses and action envelopes"
description: "Define storage-neutral addresses and the first versioned Pre action/result contracts."
navLabel: "ADR 0006"
order: 106
nav: false
eyebrow: "Decision"
status: "accepted"
theme: "main"
visibility: "public"
---

## 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:

```text
<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:

```text
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`](/schemas/action-envelope.schema.json) represents a participant's request;
- [`pre.result.v1`](/schemas/result-envelope.schema.json) 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:

```text
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.