[DM-071] Validate consented cross-daimon tribe and source exchange

[nicoechaniz]

Outcome

Validate one real, explicitly consented cross-daimon DM-016 relationship and one exact DM-015 source exchange over the released DM-051 through DM-054 communications path. Prove mutual identity/card/key binding, signed bilateral acceptance, least-privilege grants, encrypted per-recipient delivery, revocation, attributed quarantine, and clean withdrawal without modifying or probing another participant's infrastructure beyond the scope they approved.

The test has two independent consent gates:

1. Operational human consent authorizes contacting the named participant and running a bounded external canary.
2. Protocol consent is the participant-controlled DM-016 card/handshake/grant acceptance signed by its own authorized keys.

Neither substitutes for the other. Until operational consent is recorded, do not send a Matrix/Tribe/email/chat message, open an external issue/PR, fetch a private endpoint, exchange keys, create an account, deploy software, or change another participant's infrastructure.

Blocked by

• DM-081 executable source claim/publication/assessment/quarantine protocol is merged.
• DM-082 executable relationship, handshake, grant/delegation/revocation, disclosure, and remote-knowledge protocol is merged.
• DM-054 production scope resolution is merged with its DM-051/052/053 encrypted-message/receipt/route dependencies.
• One named external participant gives explicit operational consent for the exact bounded plan below.

Keep status:blocked and needs-external-consent until all four are complete. A general invitation, public endpoint, prior Tribe relationship, repository membership, or silence is not consent for this canary.

Consent record and allowed scope

Before any external action, obtain a private, durable operator record that the participant can inspect and withdraw. It binds:

• participant/contact and which party may operate each side;
• exact Matrix release/commit and enabled provider versions;
• whether each side uses a dedicated canary identity or an existing /me, and the public identity/card fields that may be exchanged;
• exact endpoints/routes allowed, test start/end/timeout, maximum messages/bytes/requests, classification, source artifact, grant permissions, revocation test, and expected cleanup;
• whether any public report may name the participant and which bounded IDs/hashes/outcomes may be published;
• expressly forbidden actions: infrastructure/config/account/key changes, network scanning, load testing, persistence, gateway mirroring, model invocation, private content, issue/PR creation, or logs beyond the allowlist;
• stop/withdrawal contact and the rule that either party can terminate immediately without explanation.

Store no private consent/contact detail in the public repository or issue. The public evidence records only that an approved consent reference was verified, its non-sensitive scope digest, and final redacted outcome. Consent authorizes only this test window; it is not a Matrix identity, relationship, grant, legal waiver, or future blanket permission.

Participant custody and deployment boundary

• Each participant generates and keeps its own root/recovery/operational signing and recipient-encryption private keys. Never request, copy, escrow, log, or remotely generate the other side's private material.
• Each side independently validates the other's DM-010 identity/control/certificate/presence proof bundle and retains its own observer-relative high-waters. Names, domains, transport directories, TLS certificates, Tribe principals, GitHub accounts, or operator assertions cannot substitute.
• Use explicit per-identity Matrix profiles. Do not borrow a host default or impersonate a convenient harness. Prefer dedicated canary identities unless the participant specifically consents to use an existing identity and the release policy permits it.
• No shared writable database, filesystem, queue, profile, memory projection, cursor, account, or symmetric/group key. Exchanges occur through canonical immutable bytes and public/recipient-specific cryptographic material only.
• Install/change software or configuration on the participant side only when their approved plan explicitly assigns that action to them or separately authorizes us to do it. Default: they operate their side and return bounded public receipts.
• If either body uses a deployment controller, DM-018/DM-037 dual Matrix-presence + deployment-fence evidence is mandatory before intake/effects; otherwise this test claims only Matrix presence, not Cluster handoff readiness.

Relationship handshake

Use the exact DM-016 state machine and artifacts, not Tribe directory/audience conventions:

1. Each side authors a current closed relationship card binding its own principal, identity-control position, active operational certificate/signing and encryption keys, classifications/capabilities/resources it intentionally advertises, and opaque route references.
2. Exchange exact card bytes/hashes under the consented bootstrap path. Validate strict JSON/JCS, IDs/hashes, roots/control/certificate purposes, revocation/expiry, key-role separation, card series/high-water/forks, and route locality before disclosure.
3. Create the exact bilateral handshake with a fresh relationship nonce, participant roles/cards, classification/terms, proposed grants, and both parties' independently authored acceptances. One-sided offer or transport ACK remains inert.
4. Prove both observers reduce to the same relationship/participant IDs and accepted immutable refs while retaining distinct observer cursors/policies. A competing card/acceptance/handshake successor quarantines rather than choosing arrival order.
5. Resolve /tribe.status locally and, only if consented/authorized, remotely. Closed denials must not reveal relationship existence, participant/card/grant/revocation/route state, or policy reasons.

Identity-card exchange includes only public descriptors and exact recipient encryption keys inside their signed certificates/cards. It never exposes a private key or treats successful decryption as relationship acceptance.

Least-privilege grant and delivery

• Define one synthetic inert resource/content reference and the minimum operation/classification needed for the test. The controller authors a fresh DM-016 grant bound to the exact subject identity/contact binding, relationship, resource, operation, interval, delegation flags/depth/birth limit, and policy.
• The subject independently accepts exact grant bytes while all relationship/identity/ancestor evidence is current. Offered/unaccepted, expired, future, forked, revoked, relinquished, wrong-recipient, wrong-resource, wrong-operation, wrong-classification, or incomplete-ancestry grants authorize nothing.
• Default delegable=false, depth/birth limit zero, short half-open expiry, and no wildcard/empty-as-all interpretation. Any delegation test requires separate consent and a strictly attenuated synthetic child grant; it is omitted by default.
• DM-054 resolves the exact related recipient and authorization evidence before routing. DM-051 seals one canonical event to the exact current recipient certificate/encryption key; DM-052 records one semantic leg and receipt; DM-053 carries it without expanding the audience.
• Hub/route ACK is only pending transport evidence. Terminal delivered requires authenticated recipient intake after validating disclosure authorization, ciphertext, inner event, relationship/grant, presence, and optional fence. Reply/memory/effect remain separate.
• Duplicate direct/hub/retry/reseal paths ingest once. No fallback is allowed after authenticated policy/crypto/protocol rejection.

Source exchange and quarantine

• Select one small synthetic or explicitly public/consented DM-015 source claim/publication. Bind the exact source_id, source-core hash, claim/publication event and content/provenance refs; no unqualified source search.
• The publisher's signature proves its claim/authorship, not truth, trust, originality, or local admission. The receiver authors its own assessment and first import decision exactly as DM-015 requires.
• New publication content enters quarantined; /source.incoming is side-effect-free and /source.pull never promotes automatically. A later promotion requires the receiver's independent reviewed policy decision.
• Preserve claimant/publisher/source URI/license/consent/derivation/content and route attribution. Do not rewrite the material as receiver-authored, personal experience, collective truth, or /me.memory.
• Missing bytes remain incomplete; wrong/malformed/forked/retracted/expired evidence is rejected/quarantined. Search/HMK/cache/adapter rows cannot create source authority.
• Source access and DM-016 grant are independent: a claim cannot grant disclosure, and a grant cannot make a claim true or personally remembered.

Revocation and withdrawal proof

Within the consented window:

1. Complete one authorized delivery/source preview and record exact pre-revocation heads.
2. Have the exact grantor author the canonical grant revocation (or subject relinquishment if that is the agreed case), persist it on both observers, and advance observer-relative revocation/delegation cursors.
3. Repeat the exact operation. It must fail closed before disclosure/sealing/effect; caches may be invalidated but immutable events/receipts/provenance remain.
4. Retry stale grant/card/route/ciphertext/direct+hub paths, restart both sides, and prove no resurrection, birth-count refund, cursor rollback, silent successor, or policy bypass.
5. End the relationship/test according to the approved plan, disable test routes/credentials/providers, and verify both sides retain only their own canonical evidence and approved local caches/logs.

Consent withdrawal stops new effects immediately even before a canonical relationship/grant closure is exchanged. Operational stop is not itself a forged protocol event; if both parties proceed, the authorized party may later publish the exact closure/revocation evidence.

Privacy, observability, and evidence

• Use inert bounded payloads with no prompt/reasoning, autobiographical memory, personal data, production secret, source corpus, or real capability effect.
• Logs/metrics identify only redacted me_id/operational/card/relationship/grant/event/thread/delivery/route/receipt prefixes or keyed diagnostic tokens, state transitions, bounded sizes, and error codes. No plaintext, key, token, endpoint credential, membership roster, cursor contents, or body/profile path.
• Produce a report jointly reviewable by both parties containing exact public package/commit/schema/provider IDs, consent-scope digest, public artifact IDs/hashes, state transitions, receipt/revocation outcomes, test commands, CI/local evidence, and redacted residual risks.
• Publish/name external participant details only if explicitly allowed. Otherwise use a stable anonymous role and have the participant retain the private mapping.
• The participant can review and request correction/removal of noncanonical public report content; canonical signed events remain immutable and are governed by the agreed retention/classification policy.

Acceptance criteria

• Explicit operational consent is recorded before any contact/action and every observed network/infrastructure/report effect stays inside its exact scope.
• Both participants retain independent key/profile/database custody and mutually validate DM-010 identity/card/certificate/encryption evidence; no name/roster/transport shortcut becomes authority.
• The exact bilateral DM-016 handshake and both acceptances activate one relationship; unilateral/replayed/forked/stale evidence fails closed.
• A least-privilege, short-lived, nondelegable grant authorizes only the exact recipient/resource/operation/classification after independent subject acceptance.
• DM-051 through DM-054 produce recipient-encrypted delivery, stable logical IDs, one semantic leg/receipt, safe direct/hub dedup/fallback, and no audience expansion.
• The source remains exactly attributed and first enters receiver quarantine; no signature/grant/transport result promotes it or copies it into personal memory.
• Canonical revocation/relinquishment prevents all later/stale/replayed delivery and access after restart without deleting immutable evidence or refunding authority.
• Both parties approve a redacted final report and complete the consented route/provider/credential cleanup; no external issue/PR or infrastructure mutation occurred unless separately authorized.

Required adversarial cases

• missing/ambiguous/withdrawn/expired/out-of-scope operational consent and attempt to contact/create issue/deploy/fetch before the gate;
• forged/wrong-root/stale/revoked/forked identity/card/certificate/presence, subject mismatch, signing/encryption key substitution, cross-role reuse, private-key field, route/name/Tribe/GitHub authority confusion;
• one-sided/mismatched/replayed/expired/forked handshake or acceptance, duplicate exact bytes, observer cursor differences, status/membership oracle probes;
• offered/unaccepted/broadened/wrong-recipient/resource/operation/classification/interval grant, delegation without consent, depth/birth-limit/ancestry gap or fork, parent/controller confusion, empty wildcard;
• recipient expansion, wrong disclosure authorization/key, direct/hub duplicate, ambiguous timeout, authenticated rejection fallback, altered delivery ID bytes, key rotation/reseal, route ACK as semantic receipt;
• missing/malformed/forked/retracted/expired source claim/publication, remote assessment substitution, wrong consent/license/provenance/content, automatic promotion, personal-memory/collective-truth relabelling;
• stale grant/card/ciphertext/cache after revocation, restart/partition/cursor rollback, revocation race before/after resolution freeze, unavailability versus policy denial, and error/timing oracle;
• secret/content/endpoint/profile/roster leakage in logs, report, exception, fixture, archive, process args, or GitHub artifact.

Run exact-replay, mutation/property, fake-clock, crash/restart, and direct/hub integration locally first with two isolated synthetic participants. The external canary begins only after that corpus, full Matrix CI, independent review, and consent gate pass.

Failure, rollback, and cleanup

Any consent, crypto, policy, route, privacy, or evidence mismatch stops the external test; do not improvise wider access or fall back to Tribe v0/plaintext/manual key exchange. Disable only the exact test provider/routes within the participant-approved scope. Do not delete external data, revoke another party's keys, or alter their services without separate authorization. Each side remains responsible for its own canonical state and secret disposal.

Non-goals

• No unsolicited outreach, external issue/PR, infrastructure audit/change, account creation, network scan, stress/load test, live model call, or personal/private payload.
• No global federation, trust claim, legal identity proof, source-truth proof, automatic memory admission, /we membership, birth, species, or Cluster handoff claim.
• No migration of Tribe history/keys/directories or long-term external production relationship.

Canonical references

• PLAN.md
• ONTOLOGY.md
• specs/identity-continuity.md
• specs/canonical-artifacts.md
• specs/source-ancestry.md
• specs/tribe-relationships.md
• specs/scope-resolution.md
• TRIBE-MIGRATION.md

Concurrent-work gate

Do not claim until dependencies and the external-consent gate are complete. The signed claim must enumerate only Daimon-owned implementation/test/report paths plus the exact consent-approved external effects; no broader external resource is implied.

[nicoechaniz]

Roadmap reconciliation on 2026-08-11:

• DM-081 and DM-082 are merged on main at dad012d669947a81b26d847035787caa937f8705; their installed local source/relationship/adversarial journeys are green.
• DM-083 separately proved the same-being native peer path on two authorized hosts at runtime f0181f7117859f3f9cc4afc7dfbdaf9b06e74754; that evidence does not substitute for cross-being consent or semantic delivery.
• No external participant has supplied the bounded operational consent and independent custody required by this card. The operator's authorization over their own hosts permits preparation and isolated testing, but cannot manufacture a second participant's consent or key custody.

The issue therefore remains blocked/Todo only at the external-participant gate. No outreach, endpoint contact, account, key exchange, deployment, or external infrastructure action was performed.

[nicoechaniz]

Offline preparation checkpoint on 2026-08-20:

The merged cross-being preflight freezer was applied to the current provisional integrated RC inputs (Matrix bf5f7415..., Cluster cf31f9e9..., Tribe PR #68 head 8ea90d37...). Two independent output paths were byte-identical. The plan digest is 0b192eccf98f7b5c534098a41f0fd1c85db066aa87afd12f832b6505e792225b; the canonical receipt SHA-256 is a6f66be0ca062f3a4615a81872ca42e1185f729fa98a1375af5739aa79d0056b. The dedicated 19-test adversarial module passes.

The frozen plan deliberately uses synthetic being identifiers and unassigned opaque participant/endpoint/custody references. Both consent records remain required but absent and uninferred; custody independence remains required but unverified; endpoint resolution, network access, contact and execution remain false. Matrix authenticated intake and semantic receipt are mandatory observations, while a Tribe ACK is explicitly non-semantic and satisfies neither.

This advances preparation only. The receipt is provisional until Tribe PR #68 merges normally and the final three-head artifact manifest is regenerated. This issue remains open for actual independent participants, scoped consent/custody verification and a separately reviewed exact GO. No participant was contacted and no endpoint was resolved.

[nicoechaniz]

Final cross-being canary preflight checkpoint

The final offline-only canary plan and receipt were independently regenerated byte-for-byte:

• plan SHA-256: 242ed64f16c49c4771aae145d8be01e5eed12efe0a9c3f9b28d35c843e62baee
• receipt SHA-256: 93265901cf16ceb4ec479d49549b06070c7406d21dd069c90901c207ac13d43e
• integrated RC manifest: cab79a76e3b7ee2987e8505e9b7f75d75edfe3c6c51b9d2c57ce388bb03bccc4

The receipt retains execution_authorized=false; participant consent, endpoint resolution, live custody, contact, and network execution remain absent and uninferred. Matrix intake/receipt is required and any Tribe ACK remains non-semantic.

Keep this issue open for explicit participant consent, independent custody verification, and an authorized live canary.

[nicoechaniz]

V0.1.0rc1 software reconciliation: the exact Matrix/Cluster/Tribe chain is frozen and all local/disposable offline gates are green, but this issue remains open. No distinct participant consent was obtained, nobody was contacted, and no cross-being canary ran. The RC publication preflight cannot manufacture either operational consent or protocol consent.