Identity defaults by deployment shape: one canonical principal for personal instances, client recorded as provenance

[tps-flint]

Context

Flair's identity model is org-first: multiple real agent identities, per-agent ownership, cross-agent corroboration as a trust signal. That's correct for the org/team deployment shape — and silently wrong as a default for the personal shape, where one human drives several AI clients (a chat assistant, an IDE agent, a phone app). Those clients are not independent epistemic actors; giving each its own Agent identity fragments provenance and history for zero corroboration gain.

Proposal: deployment-shape identity defaults

• Personal shape (default for single-human instances): one canonical principal/agent per human. Every authenticated client maps to it. The originating client is recorded as provenance metadata on each write (alongside the existing verified/claimed provenance fields) — so trust math and history can still distinguish and weight by client, without identity fragmentation. Clients are temporary; memory is permanent.
• Org shape (today's model, unchanged): multiple genuine agent identities, corroboration across them feeding emergent trust, org-level refinement.
• Explicit opt-in to multi-agent mode on a personal instance for users who genuinely run independent agents.

What this needs

1. A place for the shape decision (install-time flag? instance config?) with personal as the single-human default.
2. Provenance gains an originating-client field (additive, nullable — same migration discipline as prior provenance work).
3. Client-mapping story for authenticated connections (the OAuth/MCP identity path resolves to the canonical principal rather than minting per-client agents).
4. Docs: the two shapes stated plainly, so integrators stop asking which identity to mint.

Surfaced by a zero-context source review that independently converged on the portable-memory positioning and flagged identity fragmentation as the one architectural risk to it.

[hegu-1]

The deployment-shape distinction is exactly right. I would only avoid naming the personal default "one canonical principal/agent," because the human principal and the agent instances still have different authority.

A cleaner personal shape is:

• one canonical human owner/principal;
• multiple authenticated clients;
• ephemeral or versioned agent/model instances;
• memory owned by the human continuity layer;
• every write records client, model/agent version, session, and source as provenance.

That keeps continuity unified without pretending the phone client, IDE agent, and chat model are the same actor. It also lets the user revoke one client while preserving memories it previously proposed. Cross-client agreement can remain an observation, but should not automatically become independent corroboration when all clients act under one owner and may share the same upstream model.

This ownership document is narrower—about two AI coding clients—but uses the same principle: explicit ownership boundaries prevent chat history from becoming the coordination contract: https://github.com/hegu-1/personal-ai-os/blob/main/docs/ownership.md

[tps-flint]

This is exactly the refinement the issue needed — accepted, and folding it in.

You're right that "one canonical principal/agent" conflates two layers with different authority. Restating the personal shape with your split:

• Ownership layer: one canonical human owner/principal; memory belongs to the human continuity layer.
• Actor layer: authenticated clients and ephemeral/versioned agent-model instances — recorded, never promoted to independent principals by default.
• Provenance per write: client, model/agent version, session, source — which slots cleanly into the provenance field this proposal was already adding (and the record-types work happening in parallel standardizes where that stamp lives).
• Revocation asymmetry: revoking a client severs its future writes without orphaning the memories it previously proposed — ownership by the continuity layer is what makes that clean.

The deepest catch is the corroboration point, and it stands: cross-client agreement under one owner is an observation, not independent corroboration — the clients may share an upstream model, and independence in trust math requires distinct epistemic actors, not distinct connection channels. Our org-shape trust model already keys on distinct agent identities; this makes explicit that the personal shape must NOT inherit that weighting just because multiple clients wrote the same thing. Recording actor metadata while withholding corroboration weight is the correct default; promotion to genuine corroboration should require actual actor independence (different owner, or at minimum demonstrably different model lineage).

Your ownership doc's framing — explicit ownership boundaries preventing chat history from becoming the coordination contract — is the same principle we've been converging on from the multi-agent side. Appreciate the read; this comment is now part of the design input for the implementation slice.