P0 profile: Define universal familiar embodiment binding for automation and direct runs

[BunsDev]

Cross-repository program: OpenCoven/coven#854
Coven integration: OpenCoven/coven#857

Outcome

Define a universal, versioned Familiar Embodiment Binding that proves which familiar root and exact identity revision a concrete runtime session embodies. The same profile must work for scheduled automation runs, manual Coven launches, Psyche-orchestrated work, Cave sessions, and other conforming runtimes.

This profile answers: which familiar persisted into this execution, at which revision, under which principal and validity state? It does not schedule work, grant capabilities, approve protected actions, or author run lifecycle state.

Why this blocks reliable automations

An automation definition containing a human-readable familiarId cannot establish continuity or authorization by itself. Coven must be able to resolve an alias to one stable familiar root, pin an exact authorized identity revision at dispatch, reject stale/revoked/retired identity, and retain enough content-addressed evidence to explain the historical run later.

Without a canonical binding profile, each runtime/client risks inventing a different meaning for “ran as Charm,” and historical automation receipts can become unverifiable after identity evolution.

Canonical boundaries

Familiar Contract / continuity profile owns:

• stable opaque familiar root identity;
• identity revision and same-familiar/fork/succession semantics;
• normative identity digest boundary;
• revision validity, retirement, revocation, and restoration state;
• content-addressed historical identity rehydration;
• universal session embodiment binding and verification vectors.

It does not own:

• automation definitions, schedules, occurrences, attempts, leases, or retries;
• principal authentication implementation;
• protected-action authorization or approval decisions;
• runtime selection or dispatch;
• Cave/SDK projection state.

Proposed normative object

Ratify a versioned object such as familiar.embodiment_binding.v1 containing at least:

• bindingId;
• familiarRootId;
• identityRevisionId and monotonic/lineage position;
• canonical identity declaration/bundle digest;
• predecessor/root lineage evidence needed to verify same-familiar continuity;
• revision recorded time and valid-time interval;
• current status at decision time (active, retired, revoked, superseded, or ratified vocabulary);
• authenticated principal ID to which the familiar is bound;
• project/scope binding where relevant;
• session/run/attempt correlation target and target type;
• binding purpose/profile (direct, automation, psyche, etc.) without changing identity meaning;
• issued/decision timestamp;
• policy/profile/schema versions;
• resolver/verifier identity;
• content-addressed historical bundle reference;
• integrity/authentication field;
• privacy/retention classification.

The binding should carry digests and stable opaque references by default rather than copying sensitive declarations, memory, relationships, or personal data into every run.

Resolution and validity rules

• A human-readable familiar name/alias is input convenience, never the root of trust.
• Alias resolution must produce exactly one stable root or refuse ambiguity.
• The exact revision is selected at dispatch/session creation, not frozen when a routine is authored.
• The selected revision must be valid for execution under the current principal and lifecycle policy.
• Revoked, invalid, unresolved, or cryptographically unverifiable revisions fail closed.
• A later identity revision does not rewrite which revision a historical run embodied.
• Retirement/restoration/fork/succession must have explicit effects on new bindings and historical verification.
• Same-familiar continuity and new-root/fork semantics must be machine-verifiable, not inferred from names or similar content.
• Direct Coven and Psyche-delegated launches must use the same binding semantics.
• A binding does not itself grant runtime capabilities or authorize protected mutation; Coven Threads/Coven authority evidence is separate and correlated.

Atomicity and TOCTOU

Define how an implementation proves the identity snapshot used for the final validity check is the one committed into the session/run binding:

• the final validity check and binding commit use one immutable snapshot or transaction boundary where possible;
• committed binding bytes/digest are verified before launch success is returned;
• identity change after binding is represented as later state, not retroactive mutation;
• revocation during queued/awaiting-approval/dispatching/running states has an explicit policy and event trail;
• a stale resolver cache cannot silently produce an active binding.

Historical rehydration

A verifier must be able to reconstruct the exact identity declaration used by a historical automation/run through content-addressed retained material, subject to privacy policy. Define:

• required retained bundle components;
• digest/canonicalization algorithm and versioning;
• behavior when sensitive payloads are erased but minimum integrity/audit evidence remains;
• stale, degraded, unavailable, and unverifiable verification results;
• device/replica revocation and purge implications;
• recorded-time versus valid-time interpretation.

Do not overclaim historical continuity when required material is unavailable; return an explicit degraded/unverifiable result.

Privacy and language

• Use stable opaque principal/familiar identifiers in normative records.
• Keep sensitive declaration, relationship, memory, and credential data separately encrypted/authorized.
• Define minimization, retention, redaction, erasure, tombstone, and verifier-access semantics.
• Preserve meaningful product language such as familiar continuity while normative text remains explicit about principal binding.
• Do not imply human ownership of a person, model personhood, unrestricted agency, legal representation, or fiduciary duty.

Conformance vectors

Publish independent vectors for at least:

1. valid active root/revision binding;
2. alias resolves to one root;
3. ambiguous alias refusal;
4. stale cached revision refusal;
5. revoked revision refusal;
6. retired familiar behavior;
7. restored familiar with explicit lineage;
8. new revision of the same familiar;
9. fork/new-root distinction;
10. succession mapping;
11. direct Coven session binding;
12. scheduled automation run binding;
13. Psyche-delegated run binding;
14. principal mismatch;
15. tampered declaration/bundle digest;
16. missing historical bundle/degraded verification;
17. privacy-authorized and unauthorized historical reads;
18. revocation race before/after binding commit.

Vectors must be consumable by Coven, Psyche, Cave, SDK, and independent validators at immutable artifact revisions.

Acceptance criteria

• Stable familiar root, revision, same-familiar/fork/succession, and digest semantics are normative.
• familiar.embodiment_binding.v1 or ratified equivalent is published independently of implementation internals.
• Alias, validity, revocation, retirement, restoration, and historical rehydration behavior is explicit.
• Final validity check and binding commit have a defined atomicity/TOCTOU contract.
• Direct, automation, and Psyche sessions use one binding profile.
• The profile is explicitly separate from protected-action authority and scheduler/run state.
• Privacy/retention/erasure and degraded verification states are specified.
• Golden vectors are pinned and consumed by P0: Bind automation runs to principal authority, familiar revisions, capabilities, approvals, and receipts coven#857 and cross-repository conformance.

Non-goals

• Creating a separate SPAR database or duplicate identity ledger.
• Defining automation schedules or occurrence state.
• Granting capabilities or approvals.
• Copying full identity/memory payloads into every execution record.
• Claiming identity continuity when required evidence cannot be verified.

Bead packet

Create one P0 protocol-profile Bead mapped exactly to this issue. It blocks the identity portion of OpenCoven/coven#857. Evidence must include normative schema/text, canonicalization rules, vectors, direct/automation/Psyche canaries, privacy tests, and an exact artifact revision.

[BunsDev]

Implementation is published in #19 at exact head 9ffc283c268fa0e1bf9d179e8dde12bfca86fbdb.

Evidence:

• normative binding, detached identity-bundle, and append-only revocation-event schemas;
• JCS/SHA-256 digest boundaries and exact Ed25519 signature bytes;
• verifier-trusted ledger and atomic final-check/decision/commit rules;
• machine-verifiable continuation/restoration/fork/succession lineage;
• deterministic retained/redacted/tombstoned/erased/missing/denied history states;
• direct, automation-run/attempt, and Psyche target vectors;
• manifest-enforced semantic errors with 22 positive and 65 negative embodiment vectors;
• full npm test, example validation, JSON parsing, and read-only-checkout conformance passed;
• independent specification and code-quality reviews approved.

Cross-repository adoption remains tracked in OpenCoven/coven#857 and downstream certification/canary outcomes.

[BunsDev]

Merged via #19 at immutable merge commit 13d150a32a817da19bb4e5053f2205b15db0bb0a. Final conformance: 22 embodiment positives, 65 embodiment negatives, 2 CLI misuse checks, 7/38 base vectors, and 11 audit vectors; independent specification and code-quality reviews approved.