Post-alpha.6 roadmap · planning record

From one host to explicit network boundaries

Constellation already has exact identities, bounded authorization, durable attempt custody, reconciliation, signed local RPC, and versioned records. Its qualified composition is nevertheless local. This roadmap names the contracts and evidence required before any network-separated composition is called supported.

What exists now

The current release qualifies one disposable Linux installation. Its manifest explicitly excludes production deployment, arbitrary executor/provider integration, and federation.

• Reusable semantics: AG's signed local RPC binds protocol version, request identity, exact body digest, signer, audience, nonce, time, request echo, and response digest. The current listener is a Unix connection, and its replay guard is process-local.
• Local custody: Docket's executor transport v1 defines bounded dispatch, outcome, exact replay, restart, and non-effecting reconciliation. It explicitly does not define remote transport.
• Read surface: AG-hosted Phosphor has a bounded read-only HTTP presentation, but the qualified reader is loopback-only. Its output is not a currentness, reliance, permission, or objective-completion verdict.
• Remote-claim semantics: Standing implements bounded entitlement-to-assert records and replay checks, but remains an embedded library/CLI rather than a network service. Its current remote-boundary contract explicitly excludes federation and cross-realm trust.
• Outbound provider I/O is not component distribution: Switchyard can make bounded HTTPS provider calls. That does not establish an internal Constellation wire plane. Likewise, Porter or SSH can bootstrap an enrolled host but do not supply Docket's runtime custody protocol.

Roadmap progression

distributed-custody/v1

The first runtime split keeps the effect boundary local to its custodian:

governance host                         effect host
Nightshift → AG  ── exact signed grant ──→ Docket → local executor
                 ← custody / settlement ──

lost response ──→ inspect/reconcile the same occurrence
                  never submit replacement work

SSH may install software, enroll identities, and place configuration under an operator's deployment procedure. It is not the runtime execution protocol, does not carry a generic remote shell command as governed work, and cannot stand in for Docket custody.

Execution locality

An execution locality is an enrolled executor placement near the systems it may affect. Its network position, routing access, installed adapters, trust domain, and current operational reachability are qualification properties—not authority. The governing invariant is reachability does not confer authority.

This deliberately borrows the useful operational position of an install gateway or bastion without inheriting an ambient-authority model. It does not introduce a mandatory Constellation Gateway component, make arbitrary remote shell access a supported primitive, or require AG to have direct access to the effect network. The first proving composition below binds this concept to closed, versioned action adapters rather than a general command channel.

• Standing or another named evidence source may assert qualified locality properties. Those assertions remain evidence with explicit provenance, scope, and freshness.
• AG evaluates the admitted locality claims and other inputs, then issues narrowly scoped, audience-bound, one-use authority for exact work.
• Docket retains custody beside the effect-local executor and reconciles the same occurrence and attempt after response loss.
• The executor performs only an enrolled, versioned capability such as deploy.service/v2, restart.unit/v1, or inspect.release/v1. Enrollment and credential possession do not authorize its use.
• NQ, Monitor/Pulse, and Phosphor may observe evidence, currentness, health claims, custody, and settlement. None may infer or grant authority from reachability.

Required identities and contracts

• Versioned realm/trust-domain, issuer, audience, Docket, executor, and stable occurrence identities. Realm naming does not itself create cross-realm trust.
• A logical execution-locality identity and trust domain, bound to the exact Docket, executor implementation, enrolled capability versions, intended audience, and permitted resource scope.
• A bounded placement/reachability qualification with named source, observation time, freshness policy, and explicit missing/stale/indeterminate outcomes. It is an input to judgment, never an authority artifact.
• An exact authorization envelope binding the occurrence, sealed work and body digests, subject, scope, issuer, audience, Docket, expiry/not-before bounds, nonce, protocol version, and applicable evidence/review identities.
• Signed Docket acceptance, custody, inspection, reconciliation, and settlement records. A transport acknowledgment is not custody; custody is not settlement; settlement is not necessarily success.
• Versioned execute, inspect, reconcile, custody, settlement, and uncertain-outcome state machines that terminate wire objects at the adapter boundary while preserving Docket's existing executor semantics. The executor stays authority-neutral and local.
• A common canonicalization and digest specification with shared golden and negative conformance vectors. Every implementation must consume the same vectors.
• Strict protocol/version refusal, bounded message and retained-record sizes, and named malformed-input outcomes.
• Documented TLS/mTLS responsibilities for channel confidentiality, endpoint authentication, and operational key handling, distinct from durable application signatures that survive transport termination.
• Enrollment, rotation, revocation, recovery, and key-compromise procedures. Old in-flight occurrences need an explicit rule during rotation; a new key must not create a replacement occurrence.
• Deadlines, cancellation requests, authorization expiry, not-before checks, and clock-skew policy. Cancellation after acceptance is a state transition to reconcile, not proof that mechanics stopped.
• Durable replay and deduplication state across service and host restarts, atomically related to Docket acceptance. Capacity exhaustion fails closed rather than evicting an unexpired record.
• Typed refusal before mechanics for the wrong locality, wrong executor implementation, unsupported capability version, expired locality qualification, mismatched audience, or resource outside the enrolled scope.
• Backup, quiescence, restore, migration, rollback, observability, and notification procedures. Restore must preserve terminal occurrence and executor-marker knowledge.
• A public installation/operator guide and a versioned compatibility manifest containing exact component commits, contract versions, runtime requirements, configuration identities, qualification evidence, and limitations.

Headline case: deliberate response loss

First proving composition

Use two independently restartable, non-production hosts or local VMs and a small closed vocabulary of reversible actions: pinned service deployment, restart, backup verification, projection rebuild, rollback, and cache invalidation. Each action needs its own sealed plan, preconditions, executor implementation, qualified observation, and reconciliation evidence; there is no arbitrary-command escape hatch.

The protocol remains application-neutral. No ATProto-specific repository, schema, maintenance declaration, or deployment assumption is part of distributed-custody/v1. Selection and binding of a concrete proving deployment are separate operator decisions.

If an ATProto proving deployment is selected separately, phlogiston.app names the actual software, demonstration, visualization, and operator surface; phlogiston.social names the ATProto identity, public social surface, and protocol-facing experiments. Neither identity is part of the shared custody protocol or evidence that production binding is complete.

The custody milestone may begin with evidence already admitted on the governance host and must say so. It does not claim general remote NQ/Pulse ingress until milestone 3 qualifies that boundary.

Required qualification cases

Dependency order and ownership

1. Freeze semantics and vectors: AG and Docket jointly define the exact authorization/custody envelope, transcript, states, and shared conformance corpus. Existing authority and executor semantics remain owned by their current components.
2. Qualify remote inspection independently: Phosphor/AG own read projection and bounded presentation; deployment owns TLS identity, disclosure policy, and audit retention.
3. Build the custody boundary: AG owns judgment and issuance; Docket owns remote acceptance, durable attempt custody, inspection, settlement, and reconciliation; the executor owns only sealed local mechanics and factual receipts.
4. Exercise two-host recovery: Nightshift owns the stable occurrence and continuation posture. Operators own host enrollment, service lifecycle, backups, clocks, and credential placement.
5. Publish an experimental profile: the integration release owns exact pins, public reproduction, qualification references, and limitations. Component versions continue independently.
6. Add remote evidence ingress: NQ owns evidence disposition; Pulse owns proposition-specific present support; acquisition stays near the observed system. Standing may supply entitlement-to-assert semantics only through an explicit consumer binding; it does not automatically become a network authority service.
7. Consider claim federation: only after single-governor distributed custody and evidence ingress have operational evidence. The receiving AG remains the local judgment and authority owner.

OpenTelemetry / OTLP convergence

Use OpenTelemetry as the preferred commodity observability substrate across the operational family where it fits. Use standard OTel APIs and semantic conventions for ordinary traces, metrics, and logs, and prefer OTLP for telemetry interchange/export. Preserve every component's authority, custody, admissibility, expiry, coverage, refusal, and judgment semantics above that substrate. OTLP carriage does not make telemetry authoritative state.

Two related tracks stay distinct. A service may emit ordinary operational telemetry directly to an enrolled collector; it does not pass through Monitor or Pulse merely to report a trace. Monitor/Pulse has a separate possible role: carrying exact OTLP bytes as a governed observation payload with additional evidence semantics.

A. Constellation instrumentation survey

AG and NQ already depend on Rust tracing and tracing-subscriber, but current use is limited to a small number of startup and service call paths. That is an implementation foothold, not a shared observability profile.

• Inventory existing tracing, structured logging, metrics, correlation fields, exporters, and bespoke telemetry code in AG, NQ, Docket, Nightshift, Monitor/Pulse, Continuity, and adjacent operational services.
• Establish which paths are current runtime dependencies. Historical fixtures and retired compatibility surfaces do not become migration obligations.
• Propose a minimal shared convention for service.name, operation names, stable occurrence/attempt correlation fields, durations, outcomes, and resource attributes. Authority artifacts and private evidence must not be copied wholesale into telemetry attributes.
• Prefer maintained OTel bridges/exporters over another Constellation telemetry protocol. Start by instrumenting existing tracing call paths rather than introducing a new service or framework.
• Identify the bespoke naming, encoding, transport, and scraping code that a qualified standard path could delete. Do not promise deletion before a current consumer and equivalent behavior are established.

Completion evidence: one component-by-component inventory tied to current revisions, a proposed convention with disclosure and cardinality bounds, one deterministic local exporter exercise, and an explicit keep/replace/delete disposition for each active bespoke path. No fleet-wide migration follows automatically.

B. Monitor/Pulse EvidenceEnvelope<OTLP> experiment

EvidenceEnvelope<OTLP> is shorthand for using Monitor's existing ObservationCustodyEnvelopeV1; it is not a proposal for a new generic envelope framework. Source inspection found that the envelope already retains opaque payload_hex, a byte-exact payload_digest under transport.observation-payload.v1, observation kind, source/session identities, sequence, and qualification bindings. Pulse separately retains subject/observer incarnations, policy generation, coverage, validity, judgment, and consumer-relative reliance semantics. The canonical Monitor repository publishes the current implementation and hosted Pulse subsystem. Older Nightshift source cuts remain pinned compatibility exports for immutable released profiles; they are not the canonical development source.

• Add one bounded OTLP metrics payload variant to the existing custody envelope and change no evaluator or judgment vocabulary merely to accommodate it.
• Retain the exact received protobuf bytes. Bind admission/custody to their existing transport digest; never derive byte identity from protobuf reserialization.
• Keep transport identity and semantic identity separate. The exact-byte digest answers which bytes arrived; an explicitly versioned semantic projection may support equivalence or deduplication. Neither substitutes for the other.
• After ordinary Monitor verification and admission, unwrap the retained bytes and demonstrate that a stock OTel consumer accepts those same bytes unchanged.
• Measure the minimal payload against the current 640-byte decoded custody limit and 1232-byte canary datagram limit before proposing any production transport or changing a bound. A size refusal is a useful result, not permission to broaden the envelope.
• Record coverage, expiry/currentness, source and subject incarnations, policy generation, sequences, judgment, custody, and qualification outside the OTLP payload. Remote evidence remains evidence and grants no action authority.

Completion evidence: a frozen OTLP metrics fixture; received-byte and transport-digest identity; admitted and rejected cases; exact size measurements; an unchanged-byte stock-consumer read; and confirmation that Pulse's existing coverage, freshness, reliance, refusal, and authority-free posture remain intact.

Scope decision and non-goals

Monitor's current normative scope excludes generic observability ingestion and OpenTelemetry compatibility. Before Track B begins, an explicit bounded decision must establish that one opaque OTLP payload experiment does not turn Monitor into an OTel-compatible monitoring product. This roadmap records the question; it does not amend that scope boundary.

• Do not replace Pulse's judgment vocabulary, CoverageDescriptorV1, expiry/currentness, consumer-relative reliance, qualification, or custody with OTel concepts.
• Do not route every component's ordinary logs, metrics, or traces through Monitor/Pulse.
• Do not turn Monitor into a generic Prometheus/OTel backend, long-term telemetry store, or collector fleet.
• Do not introduce Kubernetes or a large observability platform to demonstrate the protocol.
• Do not treat collector acceptance, export success, a trace correlation, or an OTLP semantic convention as evidence admission, execution success, or authority.

The survey and bounded experiment may proceed independently of the numbered distribution milestones once separately authorized. A broad migration waits for their results and is neither required for distributed-custody/v1 nor implied by this roadmap.

Open-decision register

These decisions are prerequisites for implementation. The roadmap deliberately does not decide them by implication.

Candidate and deferred work

Claim federation

A foreign governor may eventually submit a signed claim, provenance, and receipts through a versioned import profile. The receiver must authenticate the speaker, decide whether it may make that claim to that audience, verify freshness and provenance, and then perform fresh local judgment. A foreign acceptance, permission, or settlement record is never directly spendable by the receiving Docket.

Authority federation

Authority federation is not the default objective and is not a natural upgrade from claim federation. Before it could become a roadmap commitment, a concrete need would have to resolve delegation law, trust-root governance, revocation and freeze propagation, partitions, clock behavior, conflicting governors, shared budget accounting, duplicate/double-spend prevention, and final settlement ownership. Consensus or multi-writer authority is not introduced merely to make deployment symmetric.

Explicit non-goals

• Changing, retagging, or broadening alpha.6.
• Treating TCP, HTTP, TLS, SSH, MCP, or a valid signature as semantic compatibility or permission.
• Moving an authority-neutral executor away from Docket before the Docket boundary is qualified.
• Using SSH, Porter, a remote shell, or a generic command service as the runtime custody protocol.
• Introducing a universal gateway or god-box, or describing an execution locality as one.
• Requiring AG to have direct effect-network access.
• Offering “SSH, but governed” as an arbitrary-shell capability.
• Deriving authority automatically from topology, reachability, executor enrollment, or possession of credentials.
• Introducing authority federation through execution-locality enrollment.
• Making Standing a network service, identity provider, or universal authority service by default.
• Embedding ATProto or another consumer's production migration in the shared protocol.
• Federated authority, shared multi-writer budgets, general campaign execution, or arbitrary plugin/executor substitution.

Promotion from experimental to supported

distributed-custody/v1 may be described as supported only when all of the following are public and pass against one immutable integration manifest:

1. The wire, identity, signature, custody, state-machine, and receipt contracts are versioned; two independently built endpoints consume the same positive and negative conformance vectors.
2. The real two-host proving composition completes the closed action set and every required failure case above, especially deliberate response loss, without replacement execution.
3. A clean public-only installation from exact source pins reproduces enrollment, start/stop/restart, inspection, execution custody, reconciliation, backup/restore where supported, and safe cleanup without private dependencies.
4. Operator documentation covers configuration and credential references, clocks, rotation/revocation, state locations, logs, audit records, backup, recovery, migration/rollback limits, notification behavior, and existing-attempt inspection before retry.
5. The immutable release manifest records exact component commits, contract/configuration versions, runtime/toolchain requirements, artifact digests where applicable, qualification evidence, tested topology, and limitations.
6. All remaining unsupported behavior is explicit. Component tests, loopback demonstrations, transport success, or one favorable run cannot substitute for the two-host qualification evidence.

Smallest coherent implementation tranche: freeze DC-01 through DC-06 plus the minimum DC-10 through DC-14 execution-locality decisions, publish the common transcript and conformance corpus, and implement only AG→Docket acceptance/inspect/reconcile for one sealed local-copy-style executor while keeping Docket and that executor together. Bind the logical locality, trust domain, exact executor and capability version, audience, resource scope, and fresh placement qualification. Qualify the wrong-locality refusals, deliberate response loss, and restart before adding more action adapters or remote evidence ingress.