Policy Provision and Governance Inheritance from an Organisational Identity Substrate

Introduction Artificial-intelligence agent runtimes operated by a human principal require, at the moment they begin acting on the principal's behalf, a corpus of policy artefacts that constrain their behaviour: permitted and refused actions, vocabulary and tone rules, escalation procedures, audit destinations, and the standard operating procedures the principal's organisation has adopted. In current practice these artefacts are supplied to the agent runtime by a governance plane architecturally separate from the principal's identity infrastructure. The agent runtime authenticates to one substrate (an identity provider) and receives policy from another (a governance platform, an orchestration framework's configuration plane, a per-tool policy console). The two substrates are joined by out-of-band integration work specific to each deployment. This memo specifies a different arrangement and the wire surface that supports it. An organisational identity substrate, addressable by the same identity handle that authenticates the principal as a member of the organisation, exposes typed surfaces over the Model Context Protocol that carry the policy artefacts the agent runtime requires. The agent runtime resolves the substrate at session initialisation, fetches the typed surfaces, applies them as runtime constraints, and emits audit signals to the same substrate. The arrangement composes with the discovery mechanism of , the handle namespace of , the attribution grammar of , the cross-session coordination posture of , and the cross-organisational ceremony of . No new transport, no new handle category, and no new attribution slot is introduced. This memo specifies the typed surface set, the session-initialisation flow that retrieves them, the runtime application of the retrieved enforcement-gate specification, the audit-signal flow back to the substrate, the live-update propagation, the multi-organisational composition rule, and the compliance-state inheritance posture.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined for the purposes of this document. Terms defined by the companion memos referenced here keep their meaning and are repeated here only where this document uses them. A handle named in this document corresponds to the alter: URI formed from it as defined in ; for example, ~alice is addressed as alter:~alice.

~handle: A principal identity handle as defined by , classified into the trust tiers of and referenced under the conventions of . A Sovereign-tier handle is human-controlled (e.g. ~alice); an Instrument-tier handle is agent-runtime-vendor-controlled and conventionally prefixed ~cc- (e.g. ~cc-example-model). A handle's trust tier is a property of the handle, not a property of any session it appears in.
Organisational identity substrate: A network-addressable system that authoritatively recognises a set of ~handles as members of an organisation, maintains the organisation's policy artefacts, and exposes typed surfaces by which authenticated agent runtimes of recognised members may retrieve those artefacts and submit audit signals back. The substrate is itself addressable by a handle, conventionally domain-qualified (e.g. ~example.com, addressed as alter:~example.com).
Policy artefact: A datum retrieved from the organisational identity substrate that constrains an agent runtime's subsequent behaviour. The required policy artefacts specified by this memo are the handbook, the standard-operating-procedure registry, the enforcement-gate specification, and the audit-signal ingestion endpoint.
Enforcement gate: A single rule within the enforcement-gate specification comprising a trigger predicate evaluated against tool name and arguments, an action selected from a defined action set, an applicability scope, and an explanation string. Enforcement gates are policy retrieved from the substrate; they are not hardcoded behaviour of the agent runtime.
Audit signal: An append-only record submitted by the agent runtime to the organisational identity substrate's ingestion endpoint following a runtime event that meets a substrate-specified significance predicate.
Session-bind: The discrete act, at agent runtime instantiation, of authenticating the bound principal handle to the resolved organisational identity substrate and retrieving the policy artefacts that will govern the session.
Manifest source: A configuration surface bound to the agent runtime's working context (DNS TXT record under the _alter. scheme of , project-resident anchor file, environment variable, or handle- scoped fallback) that names the target organisational identity substrate for the session. Section 4 gives the normative evaluation order, which is this one, and states why it runs from least to most writable by a party who controls only the working directory tree.
Accord: The peer-protocol cross-organisational ceremony defined by . Referenced here as the terminator of unresolvable multi-organisational policy-composition residuals.

Architecture The arrangement specified by this memo comprises four operative surfaces and three flow stages.

Operative Surfaces The organisational identity substrate SHALL expose at minimum the following four typed surfaces over the Model Context Protocol to authenticated agent runtimes of recognised members. Each surface is addressable as a tool invocation against the substrate.

org_alter_handbook: Returns the organisational handbook artefact. The handbook comprises the body of prose policy that an organisation customarily supplies to a contractor at the commencement of an engagement: voice and tone rules, vocabulary constraints, positioning rules, decision-routing rules, and any further prose policy the organisation considers operative. The surface SHALL support both whole-handbook retrieval and section-scoped retrieval by section identifier.
org_alter_sop_registry: Returns the registry of standard operating procedures maintained by the organisational identity substrate. Each registry entry carries a stable identifier, a title, a status (live, draft, deprecated), a body, and an invocation verb under which the agent runtime may execute the procedure. The surface SHALL support both registry listing and individual-procedure retrieval.
org_alter_enforcement_gates: Returns the specification of enforcement gates the agent runtime is to apply to subsequent tool invocations. The grammar of an enforcement gate is defined in Section 5.
org_alter_ingest: Accepts audit signals submitted by the agent runtime per Section 6. The surface is append-only; admitted signals are written to the organisational identity substrate's append-only event log and are not retractable or amendable.

Additional surfaces (a roster surface, a decisions surface, a compliance surface) MAY be exposed by the organisational identity substrate; agent runtimes consulting such surfaces operate beyond the required minimum specified here.

Flow Stages The session-bind flow comprises three stages, executed in order:

Resolve. The agent runtime determines the target organisational identity substrate by consulting the manifest source, as specified in Section 4.
Retrieve. The agent runtime authenticates to the resolved substrate using the bound principal handle's session credential and retrieves the four required policy artefacts via the surfaces of Section 3.1.
Apply. The agent runtime translates the retrieved enforcement-gate specification into runtime hooks, registers the audit-signal endpoint as the destination for subsequent significant-event emissions, and surfaces the handbook and SOP registry to the bound principal as in-context advisory material.

The three stages constitute session-bind. All three SHALL complete before the agent runtime acts on the principal's first prompt of the session. If any stage fails, session-bind SHALL fail; partial inheritance of policy is not permitted (Section 9).

Discovery and Resolution The agent runtime SHALL resolve the target organisational identity substrate from a manifest source bound to the runtime's working context. Manifest sources are evaluated in the priority order below, from the source least writable by a party who controls only the working directory tree to the source most writable by such a party. The first source that yields a handle is operative; later sources are not consulted.

DNS TXT record under the _alter. scheme of . The agent runtime resolves the working directory's source- control remote (where present) to a domain name and queries _alter.<domain> per . The TXT record's org_alter field, when present, names the target substrate. Writing this source requires control of the domain's DNS zone in the sense of , which a party who controls only the working directory tree does not by that fact possess.
Project-resident anchor. A file at an implementation- defined path within the working directory tree (a recommended path is .alter/org-alter.toml or an [org-alter] block within pyproject.toml, package.json, or Cargo.toml) names the target substrate by handle. This source carries no cryptographic binding to the substrate it names; it is consulted only when source (1) does not resolve.
Environment variable. An implementation-defined environment variable (a recommended name is ALTER_ORG_HANDLE) carries the target substrate handle.
Handle-scoped fallback. If sources (1) through (3) do not resolve, the runtime falls back to the principal's own handle-scoped substrate, which exposes the same typed surfaces as an organisational identity substrate but is scoped to the principal alone and does not participate in multi-organisational composition (Section 8).

The resolved handle is translated to a substrate endpoint via the DNS-based resolution mechanism of . The agent runtime opens a Model Context Protocol session against the endpoint, authenticating with the bound principal handle's session credential obtained from the implementation-defined session manifest. A substrate that does not recognise the authenticating handle as a member SHALL refuse the session; an unrecognised handle MUST NOT receive policy artefacts. The substrate MAY further refuse on trust-tier grounds: an Instrument-tier handle SHALL be admitted only when the substrate's policy explicitly admits Instrument-tier sessions from the corresponding Sovereign-tier handle's delegation.

Enforcement Gate Grammar The org_alter_enforcement_gates surface (Section 3.1) returns an enforcement-gate specification. An enforcement-gate specification is a list of enforcement gates. Each enforcement gate is an object with the following fields.

id (string, REQUIRED)

A stable identifier for the gate, unique within the specification. Identifiers are used as the addressing target for audit signals (Section 6) and for policy-update propagation (Section 7).

trigger (object, REQUIRED)

The trigger predicate evaluated against each prospective tool invocation. The object's keys are predicate operators; the values are operator-specific patterns. Minimum operator set:

tool_name_match (string): regular expression matched against the tool name.
path_glob (string): glob pattern matched against any argument resolvable as a filesystem path.
command_substring (string): substring matched against any argument carrying a command string.
arg_arity (object): minimum and maximum bounds on argument list length.

A trigger object matches when every operator present in the object matches. Additional operators MAY be defined by the substrate and SHOULD be ignored by agent runtimes that do not understand them.

action (enum, REQUIRED)

One of:

block: the tool invocation is refused. The runtime returns the gate's explanation string to the agent reasoning loop as a synthetic error and emits a policy.violation audit signal.
prompt-for-confirmation: the tool invocation is paused and a confirmation prompt is rendered to the Sovereign-tier principal. The invocation proceeds only on principal confirmation. A gate.confirmation-requested audit signal is emitted on prompt; a gate.confirmation-granted or gate.confirmation-denied signal is emitted on outcome.
allow-with-audit: the tool invocation proceeds, and a gate.allowed-with-audit audit signal is emitted.

scope (object, OPTIONAL)

An applicability scope restricting the gate's effect. Recognised keys:

trust_tiers (array of strings): the trust tiers (Sovereign, Instrument, Bot) to which the gate applies. Omission indicates all tiers.
working_context_glob (string): a glob matched against the agent runtime's working directory path. Omission indicates all contexts.

explanation (string, REQUIRED)

A human-readable explanation of the gate, returned to the agent runtime on action execution. The explanation SHOULD be sufficient for the reasoning loop to surface to the principal without further substrate round-trip.

audit_emit_on (array of strings, OPTIONAL)

A list of event types for which audit signals are emitted on this gate's evaluation, beyond the action-implicit signals enumerated above. Substrate-significance predicates (Section 6) may select event types not directly tied to a gate; this field carries the per-gate overrides.

When two or more gates trigger on a single prospective tool invocation (after applicability-scope filtering), the gate whose action is most restrictive prevails. Order of restrictiveness, from most to least, is block, prompt-for-confirmation, allow-with-audit. The agent runtime SHALL NOT maintain enforcement gates outside the specification retrieved from the substrate. Gates are policy, sourced from the substrate; an agent runtime that hardcodes a gate operates outside the surface of this memo.

Audit Signal Flow The agent runtime emits audit signals to the substrate's org_alter_ingest surface for runtime events that meet a substrate-specified significance predicate. The significance predicate is itself policy retrieved from the substrate; the substrate determines which events are significant, not the runtime. An audit signal is an object with the following minimum fields:

type (string, REQUIRED)

The event type. The minimum-set of event types a conformant runtime SHALL emit when triggered comprises:

session.start at session bind, carrying the bound principal handle, trust tier, resolved substrate handle, and manifest source used for resolution.
session.end at session termination, carrying the bound handle and a structured summary of session activity.
tool.invoke per tool invocation that meets the substrate- specified significance predicate, carrying the tool name, a redacted argument summary, the gate evaluation outcome, and the result classification.
policy.violation when a block gate action fires, carrying the gate identifier and the offending invocation.
policy.update on receipt of a live-substrate policy update (Section 7), acknowledging the new policy epoch.
gate.confirmation-requested, gate.confirmation-granted, gate.confirmation-denied on prompt-for-confirmation flow.
gate.allowed-with-audit on the corresponding action.

payload (object, REQUIRED)

Event-type-specific structured data. The substrate's significance predicate MAY constrain payload shape per event type.

attribution (object, REQUIRED)

Carries the Sovereign-tier handle and any in-scope Instrument-tier handle. The grammar follows the trailer slots defined by ; the audit-signal attribution field is the protocol-layer companion to the commit-trailer block.

timestamp (string, REQUIRED)

Timestamp in the format of at which the runtime emitted the signal.

gate_id (string, OPTIONAL)

When the signal arises from a gate evaluation, the identifier of the gate.

The substrate's audit-signal endpoint is append-only. Admitted signals SHALL NOT be retracted or amended by the emitting runtime or by the substrate operator. This section requires policy and audit to be co-located at the same substrate; an audit channel addressable separately from the policy that governed the audited events does not satisfy this specification.

Live Policy Updates The agent runtime maintains, for the duration of the session, a subscription channel against the resolved organisational identity substrate over which the substrate emits policy-update notifications. The subscription channel SHOULD be implemented as a server-sent events stream or equivalent unidirectional-from-substrate transport that the existing Model Context Protocol session can carry without additional authentication round-trip. On receipt of a policy-update notification, the runtime SHALL:

Re-fetch the affected policy artefact via the corresponding typed surface of Section 3.1.
Recompute the runtime hooks of Section 5 from the updated enforcement-gate specification.
Atomically replace its in-memory policy state. No tool invocation issued after the atomic replacement observes a partial composition of the pre-update and post-update gate sets.
Emit a policy.update audit signal acknowledging the new policy epoch.

A runtime SHALL NOT require process restart to apply a policy update. An update notification that the runtime cannot apply (because the substrate returned a malformed artefact, or because the runtime's hook surface cannot represent the updated gate set) SHALL cause the runtime to emit a policy.update-failed audit signal and either retain the prior policy state and surface the condition to the principal, or terminate the session at the substrate's configured failure-mode.

Multi-Organisational Composition A principal MAY be concurrently recognised by multiple organisational identity substrates. When more than one substrate recognises the principal for a session (for example, when the manifest-source resolution of Section 4 names a primary substrate and the session credential carries auxiliary memberships), the agent runtime composes the retrieved policy stacks under the following rules.

org_alter_handbook composition: Handbooks compose by union. Where two handbooks declare conflicting sections, the substrate declared earlier in the manifest's precedence order prevails. In the absence of explicit precedence, the substrate resolved from the working- context anchor (Section 4(1) or 4(2)) prevails.
org_alter_sop_registry composition: Standard-operating-procedure registries compose by union. Procedures are identified by the tuple (substrate-handle, procedure-identifier) to permit identically-named procedures across substrates without collision.
org_alter_enforcement_gates composition: Enforcement gates compose by union under a strictest-applicable rule: where two gates from distinct substrates trigger on a single prospective tool invocation, the gate whose action is most restrictive prevails (order as in Section 5).
org_alter_ingest segregation: An audit signal arising from a gate whose evaluation drew on policy from multiple substrates SHALL be emitted only to the audit-signal endpoint of the substrate whose own policy contributed the gate, and SHALL carry only that substrate's share of the evaluation. A runtime MUST NOT emit an audit signal to a substrate whose policy did not participate in the evaluation. A runtime MUST NOT include in an emitted signal a field, count, identifier, gate reference or timing correlation from which the receiving substrate could infer that the principal is bound to another substrate. Where a gate cannot be evaluated without disclosing that a peer contribution exists, the runtime SHALL suppress the invocation and record a local diagnostic visible to the principal only. The prohibition this rule enforces is stated in the Privacy Considerations under Identity-Binding Leakage.

Cross-organisational residual conflicts that the composition rules above cannot resolve (for example, two substrates' handbooks declaring mutually-inconsistent positioning rules where neither is clearly subordinate under the manifest precedence) SHALL cause the agent runtime to suspend the conflicting action and to record a local diagnostic visible to the principal only. The runtime MUST NOT emit a residual-conflict signal to any substrate and MUST NOT name one substrate to another, because either act discloses the principal's other binding. Where the principal elects to have the conflict resolved between the substrates, the principal discloses each binding to the other as a deliberate act, and the peer-protocol Identity Accord ceremony then proceeds between the participating substrates on that disclosure. Resolution does not proceed via a meta-federation authority, and the composition rules of this section define none.

Compliance-State Inheritance At session-bind, the agent runtime inherits the organisational identity substrate's then-current compliance state as a single coherent snapshot. The snapshot comprises at minimum:

The audit-signal endpoint URI and its current write credential.
The enforcement-gate specification at its current epoch.
The standard-operating-procedure registry pointer at its current revision.
A hash of the handbook artefact at its current revision.
The set of compliance commitments the substrate has accepted and currently asserts (for example, a refusal of a specified category of automated invocation, or a specified regulatory posture).

Inheritance SHALL be atomic. Either all snapshot elements are inherited at a single substrate epoch, or session-bind fails. A session that proceeds with a partial snapshot is non-conformant. The runtime SHALL surface session-bind failure to the principal with the substrate-returned diagnostic; it SHALL NOT silently degrade to a fallback policy stack. Subsequent live updates (Section 7) modify the snapshot at the runtime in place but do not retroactively alter the snapshot epoch recorded at session-bind. The audit trail of a session is the sequence of policy epochs the runtime observed across its lifetime, anchored by the session-bind snapshot.

IANA Considerations This memo requests no IANA action. The four required typed surfaces named in Section 3.1 (org_alter_handbook, org_alter_sop_registry, org_alter_enforcement_gates, org_alter_ingest) are illustrative of the reference substrate operated by Alter Meridian Pty Ltd. Conforming substrates MAY name their surfaces by any convention consistent with their addressing primitive. This memo specifies the typed-surface enumeration over an organisational identity substrate, not the surface names themselves. Where a substrate elects to advertise its handle in the discovery record, the org_alter field is added under the field-extension mechanism of ; this memo requests no separate registry allocation. No new DNS RR types, transport identifiers, port numbers, URI schemes, or media types are introduced. The reuse of the _alter.<domain> DNS label (Section 4(1)) is per and requires no further allocation here. The project-resident anchor path of Section 4(2), the environment-variable name of Section 4(3), and the session-manifest layout referenced in Section 4 are implementation-defined and are not registered.

Security Considerations The arrangement specified by this memo concentrates policy, attribution, and audit on a single substrate addressable by the principal's identity credential. The arrangement depends on that concentration, and the concentration is the main source of the following security considerations.

Manifest-Source Spoofing The subsections below reason about a substrate that has already been correctly resolved. This subsection addresses the step that precedes all of them. A party able to influence the working directory tree that an agent runtime resolves against (a compromised or malicious repository, a poisoned pull request checked out for review, a dependency that ships an [org-alter] block) may attempt to cause the manifest-source resolution of Section 4 to name a substrate that party controls. Such a party need not compromise a substrate; it is enough that content it controls is consulted as the resolution input. Mitigations:

Section 4 orders the DNS TXT source ahead of the project- resident anchor because writing the former requires control of a DNS zone, and writing the latter requires only write access to the working directory tree. A conformant implementation SHALL NOT consult the project-resident anchor when the DNS source resolves, so resolution does not depend on working-directory content whenever the DNS source resolves. The org_alter field lies outside the Ed25519 signing input of the envelope; its integrity rests on the DNSSEC validation that requires for that record.
The project-resident anchor carries no cryptographic binding to the substrate it names. A runtime that resolves the session's governing substrate via the project-resident anchor SHOULD surface that fact to the principal, so that governance derived from working-directory content is not silently indistinguishable from governance derived from a cryptographically-bound source.
Section 8's handbook-composition tie-break defers, in the absence of explicit precedence, to the substrate resolved from the working-context anchor. Because Section 4 places the DNS source ahead of the project-resident anchor, this tie-break resolves to the DNS-bound substrate whenever DNS resolves, and to the project-resident anchor only when DNS does not.

Substrate Compromise A compromised organisational identity substrate may serve falsified policy artefacts to authenticated members, induce the runtime to emit audit signals to an attacker-controlled endpoint, or suppress update notifications to keep runtimes operating under stale gates. Mitigations:

The substrate's policy artefacts SHOULD be served over a channel authenticated by the cryptographic identity envelope of (the _alter.<domain> Ed25519 binding) so that a consuming runtime can verify the artefact bears the substrate's declared signing key.
Audit-signal endpoints SHOULD be pinned at session-bind time to the endpoint URI recorded in the compliance snapshot (Section 9); mid-session redirection of the endpoint SHALL require a policy.update notification carrying the new endpoint under the same signing key.
Runtimes SHOULD treat suppressed update notifications as an observable substrate signal under the substrate-observation posture of ; prolonged absence of update events on a substrate that asserts an active policy lifecycle is itself diagnostic.

Trust-Tier Escalation An Instrument-tier handle that successfully presents a Sovereign- tier session credential (through credential theft, compromised session manifest, or substrate misissuance) would receive the Sovereign-tier gate set, which is the more permissive set. Mitigations:

The substrate SHALL bind trust tier to the handle itself, not to the session, and SHALL refuse Instrument-tier handles presenting Sovereign-tier credentials at the recognition step.
Audit signals SHALL carry attribution per Section 6; an Instrument-tier session writing to the audit log under a Sovereign-tier attribution is detectable by post-hoc audit and by the cross-tier checks defined in .
Sovereign-tier confirmation prompts (Section 5's prompt-for- confirmation action) SHOULD be rendered through an out-of- band channel addressable only by the human principal, so that an Instrument-tier session in possession of the Sovereign-tier session credential cannot satisfy a confirmation on the principal's behalf.

Multi-Organisational Conflict Exploitation A principal recognised by multiple substrates may be the vector for an exploit in which one substrate's gate is suppressed by a falsified or absent gate from a second substrate. Mitigations:

The strictest-applicable rule of Section 8 SHALL be evaluated over the gates actually retrieved from each substrate. A substrate that fails to return its enforcement-gate specification at session-bind SHALL cause session-bind to fail for that substrate (no implicit empty-gate-set composition).
The principal's manifest precedence declarations SHOULD be authenticated against the key bound to the principal's handle under so that a forged precedence claim cannot install a less-restrictive substrate as the primary.

Live-Update Replay An attacker positioned to observe the subscription channel may attempt to replay an aged policy.update notification to roll a runtime back to an earlier policy epoch. Mitigations:

Update notifications SHALL carry a monotonic substrate-emitted epoch identifier.
Runtimes SHALL reject notifications carrying an epoch less than or equal to the runtime's currently-applied epoch.
The substrate's append-only audit log retains the ordered history of issued epoch identifiers and is consultable for post-hoc replay detection.

Pseudonymous Discovery Substrates The handle-scoped fallback of Section 4(4) operates the typed surfaces against a principal-scoped substrate that does not assert organisational membership. An agent runtime in this configuration inherits the principal's own policy stack but does not benefit from multi-organisational composition. Implementations SHOULD surface to the principal that the session is operating in the fallback configuration so that the absence of an organisational substrate is not silently consumed.

Privacy Considerations The audit-signal flow of Section 6 records the agent runtime's tool-invocation activity on the substrate. The substrate operator has visibility into the principal's session activity at the granularity of the substrate-specified significance predicate. Three privacy postures arise.

Significance-Predicate Scope The substrate determines which events are significant and therefore audited. A significance predicate covering every tool invocation yields a complete activity log; a narrower predicate audits only events the substrate considers operative. Substrate operators SHOULD publish their significance predicates as part of the handbook artefact so that authenticated members understand the scope of audit they consent to as a function of membership.

Argument Redaction Tool-invocation arguments SHOULD be redacted before inclusion in the tool.invoke audit signal payload. Minimum redaction practice is removal of secret material (credentials, signing keys), personally-identifying information about third parties referenced in the invocation, and any field the principal has marked sensitive in a per-session redaction profile. Substrate operators SHOULD specify their argument-redaction expectations in the handbook artefact.

Identity-Binding Leakage A principal may be concurrently bound to more than one organisational substrate. The fact of that concurrency is itself identifying: a substrate that learns a peer substrate participated in an evaluation learns that the principal is bound to that peer, and no party other than the principal can consent to the disclosure. names this failure Identity-Binding Leakage and treats it as an anti-pattern. Accordingly, a substrate MUST NOT be told, and MUST NOT be able to infer, that the principal holds a binding to any other substrate. The prohibition covers the existence of the other binding, its count, its name, its handle, its domain, and any gate, signal field, error, latency or ordering artefact from which any of those could be derived. It is not satisfied by pseudonymising the peer substrate, because a stable pseudonym still discloses that a peer exists, and it is not satisfied by notice, because notice does not make the disclosure consented to by the principals it identifies. Revisions -00, -01 and -02 of this memo specified in this position a Cross-Substrate Audit Fan-Out, under which audit signals arising from a multi-substrate evaluation were broadcast to every contributing substrate. That mechanism is withdrawn. It performed the disclosure this section prohibits, and it cannot be made conformant by notice or by declaration in a handbook artefact. Implementations of an earlier revision SHOULD disable the fan-out and emit under the segregation rule of Section 8.

Relation to Companion Memos This memo composes with five companion Internet-Drafts. supplies the DNS-based discovery surface from which the manifest-source resolution of Section 4(1) draws and the cryptographic identity envelope referenced in Section 11. This memo introduces no new DNS records or labels beyond those specified by . supplies the conventions for referencing a handle, over the handle of and the trust tiers of used throughout this memo. This memo introduces no new handle category. supplies the attribution grammar that the audit- signal attribution field of Section 6 mirrors at the protocol layer. An audit signal and an Acted-By: / Drafted-With: commit trailer block carry the same attribution shape, one at runtime, one at version-control commit time. supplies the substrate-observation posture under which the runtime treats absence of expected update notifications as a substrate signal (Section 11). Substrate observation also supplies the cross-session coordination floor against which multiple concurrent runtimes of the same principal deconflict without exchanging coordination messages. supplies the peer-protocol ceremony by which Section 8's cross-organisational residuals are resolved, where the principal has disclosed each binding to the other.

Implementation Status A partial reference implementation of the agent-runtime side of this specification is operated by the present author against a production substrate. Of the four typed surfaces of Section 3.1, the SOP registry and the audit ingest are reachable as tool invocations; the handbook and the enforcement-gate specification are not yet exposed as typed surfaces. The provisioning path (the session-bind flow of Section 3.2) is implemented as a service and is not yet invoked by any agent-runtime session, so the supply of policy artefacts described in earlier revisions of this section is intent rather than experience. The instrument-tier and recognised-member admission of Section 4 is specified but not enforced by the reference deployment. The audit-signal flow of Section 6 is not exercised by the reference deployment. As describes, this section documents implementation experience and is to be removed before publication as an RFC. No claim of interoperability is made; the reference deployment is a single substrate operated by the specification's author.

Document History draft-morrison-org-alter-policy-provision-05 (October 2026):

Replaces the hand-typed BCP 14 key-words paragraph with the standard boilerplate.
Corrects the reference for server-sent events in Section 7. [RFC8441] specifies WebSocket bootstrapping over HTTP/2, not server-sent events; the reference is now the WHATWG HTML Standard .
Adds as a normative reference for the audit-signal timestamp field of Section 6.
Corrects the reference to that draft's full title and both of its authors.
Attributes the ~handle to and the trust tiers to in Section 2 and Section 13, as itself does. Section 11.4 authenticates manifest precedence against the key bound to the principal's handle under , which does not define.
Corrects Section 11.1. The org_alter field is not within the Ed25519 signing input of the envelope, so the subsection no longer describes DNS resolution as Ed25519-bound; it states that the field's integrity rests on DNSSEC.
Corrects Section 8, which described the manifest-source resolution of Section 4 as returning more than one substrate handle. Section 4 yields one; further substrates arise from memberships the session credential carries.
Corrects the Abstract to the residual-conflict route of Section 8 as revised in -03: the action is suspended, and the ceremony proceeds only on the principal's disclosure.
Corrects Section 10, which attributed the session-manifest layout to Section 4(2) and Section 4(3); those name the project-resident anchor and the environment variable. Removes the statement about what a future revision might request.
Corrects the section references in Section 14: the provisioning path is the session-bind flow of Section 3.2, member and instrument-tier admission is in Section 4, and Section 6 has no substrate-to-substrate audit leg. Aligns the RFC 7942 sentence with RFC 7942.
Removes statements of the memo's own contribution from Section 1 and Section 10 and from the -01 entry below, a statement that a meta-federation authority is structurally precluded from Section 8, and the essential-property wording from Section 6.
Replaces "Morrison-family" with "companion" in Section 2 and Section 13.
Removes the name of a draft that was never posted from the -01 entry below, and removes the Acknowledgements section.
Rewrites sentences in Sections 1, 2, 11 and 14 in plainer terms and removes bold labels from the lists in Sections 3.2 and 4.
States in Section 2 that a handle corresponds to an alter: URI, and adds an informative reference to .
No change to the typed surface set, the session-bind flow, the enforcement-gate grammar, the audit-signal fields, the live-update mechanism, the composition rules, the compliance-state inheritance posture, or the IANA position.

draft-morrison-org-alter-policy-provision-04 (September 2026):

Corrects the Implementation Status. Earlier revisions described the supply of policy artefacts, its instrument-tier and recognised-member scoping, and the Section 6 audit leg as operating; each is specified but not exercised by the reference deployment. Two of the four Section 3.1 surfaces are recorded as reachable and two as not.

draft-morrison-org-alter-policy-provision-03 (August 2026):

Withdraws the Cross-Substrate Audit Fan-Out. The org_alter_ingest fan-out rule that applied under multi- organisational composition is replaced by a segregation rule under which an audit signal reaches only the substrate whose own policy contributed the gate, with a normative prohibition on any field from which a receiving substrate could infer a peer binding.
Replaces the Cross-Substrate Audit Fan-Out subsection of the Privacy Considerations with Identity-Binding Leakage, which states the prohibition directly and records the withdrawal. already names that failure as an anti-pattern, and the two positions in this memo were inconsistent with it.
Revises the cross-organisational residual-conflict route. The runtime no longer emits an accord.residual signal to the participating substrates; it suspends the action and records a local diagnostic, and the ceremony proceeds only on the principal's own disclosure of each binding to the other.
No change to the typed surface set, the session-bind flow, the enforcement-gate grammar, the audit-signal shape, the live- update mechanism, the compliance-state inheritance posture, or the IANA position.

draft-morrison-org-alter-policy-provision-01 (May 2026):

Retitles the memo from "Org-Alter-Mediated Policy Provision and Governance Inheritance for Agent Runtimes Bound to a Principal Identity" to "Policy Provision and Governance Inheritance from an Organisational Identity Substrate". The retitled framing generalises the substrate above the operator-specific org_alter_* surface naming and clarifies that what the memo specifies is the typed-surface enumeration over the substrate, not the surface-name convention. The abbreviated title and the body terminology are retained.
Softens the IANA Considerations section. The previous revision requested establishment of a Model Context Protocol Tool Surface Names registry with the four org_alter_* names as initial entries. The revised section requests no IANA action; the surface names are explicitly illustrative of the reference substrate, and conforming substrates MAY name surfaces by any convention consistent with their addressing primitive. A future revision or companion specification proposing such a registry remains possible.
Adopts the organisational-identity-substrate framing, in which the substrate is the core primitive.
No substantive change to the typed surface set, the session-bind flow, the enforcement-gate grammar, the audit- signal flow, the live-update mechanism, the multi-organisational composition rules, or the compliance-state inheritance posture.

draft-morrison-org-alter-policy-provision-00 (May 2026):

Initial submission.
Specifies the four required typed surfaces of the organisational identity substrate (org_alter_handbook, org_alter_sop_registry, org_alter_enforcement_gates, org_alter_ingest).
Defines the session-bind flow (Resolve, Retrieve, Apply).
Specifies the enforcement-gate grammar and the strictest- applicable composition rule.
Specifies the audit-signal flow and the append-only ingestion endpoint.
Specifies the live-policy-update subscription and atomic- replacement requirement.
Specifies multi-organisational composition and the cross- organisational residual route to .
Specifies compliance-state inheritance and the atomic-snapshot requirement.