The copy that kept the promise

We normally meet identity in a world where one body occupies one path through time. A person can change greatly, yet there is rarely a second body with the same memories standing beside the first. That biological scarcity hides an assumption: continuation is expected to be one-to-one.

Software removes the scarcity. A checkpoint can be restored twice. A model, prompt, tool configuration and episodic store can be duplicated in milliseconds. Two executions can begin with no detectable internal difference and diverge on their next input. Once this is possible, asking which one is the continuation is no longer answered by similarity alone.

Derek Parfit's fission cases made the logical pressure clear for persons: psychological continuity can branch even though numerical identity cannot be one-to-many in the ordinary sense.[1] Software makes the branching literal. We need not accept Parfit's wider metaphysics to inherit the engineering lesson: a relation that can branch cannot by itself behave like strict identity.

Five identities hiding inside one word

Engineers already use several criteria of identity, often without noticing the switch. An OCI image digest identifies immutable content. A Git commit records a tree and its parent commit identifiers. A Kubernetes StatefulSet defines a pod's stable identity using an ordinal, network identity and storage.[6][3][5] None is the universal essence of software. Each is a specification of what must remain stable for a particular job.

For an acting system, at least five continuities can separate:

A restored process may lose runtime continuity while retaining principal and normative continuity. A byte-for-byte clone may retain content continuity while becoming a new principal. A failover replica may be a new process but the same logical service. The identity claim must name the continuity it asserts.

flowchart TD
  A["The copy that kept the promise"] --> B["Four operations, four<br/>different questions"]
  B --> C["The configured lineage contract"]
  C --> D["Where lineage stops"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#5B5CF6,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Four operations, four different questions

Copy, fork, reset and merge are often treated as storage operations. For identity, they are different causal interventions. Each changes a different relation, so each needs its own succession rule.

Copy: one service or two principals?

A copy preserves some chosen state. It does not specify whether the result is a passive backup, an active replica of one logical service, or an independent actor. The difference lies in coordination and authority.

Replicated state machines can make several processes implement one logical machine by applying an agreed sequence of commands. Virtual actor systems can likewise give a logical actor a stable identity even when its in-memory activation disappears and later returns.[14][13] In these cases, many runtimes may realise one governed principal because the system enforces a single authoritative history.

By contrast, two active copies with independent inputs, independent credentials and no consensus are more than redundant instances. They are branches, whether or not the operator uses that word. Replication preserves one identity only when an external protocol prevents the replicas from becoming independent authors of history.

Fork: continuity without uniqueness

A fork creates at least two successors whose histories share a prefix. Lamport's happened-before relation gives us a useful minimum: if an event in the parent could causally influence both branches, it belongs to the common past; events after the fork may be concurrent and incomparable.[2] Git makes the same geometry explicit through commits with parent links and merge commits with multiple parents.[3]

What should happen to a promise made before the split? There is no answer in the snapshot. A policy must choose among at least four meanings:

• all successors inherit a duty to ensure one discharge;
• one successor is explicitly assigned the duty;
• the duty remains attached to a service principal above both branches;
• the fork is prohibited until the duty is settled.

These are governance choices, not discoveries about byte patterns. Multiagent research is helpful here because it models commitments as social relations between a debtor and a creditor, rather than only as private beliefs inside the debtor.[10] A branch can forget a promise and still remain bound by an external commitment record.

Reset: state goes back, history does not

A reset replaces current internal state with a prior snapshot. It can be useful for recovery, debugging or safety. The hidden danger is treating the restored state as the whole world.

Event-sourced systems avoid this confusion by treating the append-only event stream as authoritative and reconstructing current state from it. The pattern is not free; it adds schema, concurrency and operational complexity. Its conceptual advantage is precise: it separates what happened from the current materialised view.[8]

For an agent that can affect external systems, at least three records must be monotonic across reset:

• commitment transitions, such as created, assigned, discharged or violated;
• authority transitions, such as delegated, narrowed, expired or revoked;
• effect receipts, such as payment accepted, message sent or record changed.

“Monotonic” does not mean that nothing can be reversed. It means reversals appear as new authorised events rather than deletion of old ones. A refund does not erase a charge; it compensates it. A released commitment does not vanish; its status changes with an accountable cause.

Merge: convergence is not reconciliation

A merge creates a state that depends on two or more parents. Git can reconcile file changes and record a merge commit. Conflict-free replicated data types can converge automatically when operations or states satisfy specific algebraic conditions.[9] Those techniques are powerful because they define what counts as a valid join.

Preferences and commitments often lack that structure. One branch may promise a refund while another promises replacement. One may learn that speed matters most; another may learn that avoiding a medical risk matters more. Averaging the preference weights can produce a policy no branch endorsed. Taking the latest timestamp can reward clock order rather than reasons. Taking the “stronger” commitment may be impossible when the commitments have different creditors.

Preference continuity is authored, rather than only remembered

Preferences require a different inheritance rule from commitments. A commitment is directed towards a creditor and remains active until a recognised transition changes it. A preference is an ordering used to choose among possible actions. It can be revised by new evidence, reflection, policy or changing circumstances. Treating both as immutable would prevent learning. Treating both as disposable would make every reset a route around responsibility.

The useful unit is therefore not a naked weight such as risk_aversion = 0.72. Record the proposition being ranked, the scope in which it applies, the branch that asserted it and the reason or evidence for revision. Before a fork, both children inherit the common prefix of preference history. After the fork, each revision is branch-local even when the resulting number happens to match. Equal values reached through different evidence are not the same provenance fact.

A merge policy can then make a real decision. It may grant one branch a veto for a safety-specific domain, use a lexicographic priority established before the fork, reopen deliberation with both evidence sets, or retain a plural state and abstain where the branches disagree. The contract should name the rule and the authority that selected it. “Take the average” is legitimate only when the preference type has an agreed arithmetic interpretation and the averaging rule was authorised in advance.

This distinction matters even for systems that are not candidates for consciousness. A fraud model and a customer-service model may share weights yet be authorised to express different priorities. Conversely, two branches may have different weights while remaining subordinate to one service policy. Preference similarity is evidence about behaviour; preference authority is a governance fact.

The configured lineage contract

The practical answer is not to choose one metaphysical criterion and force every operation through it. It is to represent the relevant continuities directly.

A configured lineage contract is a versioned rule set applied to a causal graph of system incarnations. Each node describes one configured incarnation. Each edge records an operation such as activation, copy, fork, reset or merge. The contract states what may inherit across each edge and what must remain in an external monotonic ledger.

The model borrows only what existing standards can support. W3C PROV gives a domain-neutral vocabulary for entities, activities, agents, derivation and responsibility.[4] SLSA provenance records how a software artefact was produced.[7] These are strong foundations for lineage, but neither decides succession of commitments or preferences. The configured contract adds those domain-specific rules.

Minimal schema

The smallest useful manifest needs fewer fields than a full audit platform, but more than a process identifier:

• a globally unique incarnation identifier and one or more parent identifiers;
• the operation that created the incarnation;
• content and configuration digests;
• principal, sponsor, authority key and delegated scope;
• active commitment references and their inheritance rules;
• preference assertions with branch provenance and revision reason;
• effect receipts and readback status;
• the versioned succession policy used to interpret the transition.

Content hashes help detect change, but they do not identify a running principal. Build provenance helps verify origin, but it does not settle present responsibility. Authentication proves control of a credential, but it does not show that the holder validly inherited an earlier promise. Current agent-identity work rightly focuses on authentication, delegated authority and auditability; persistence under fork and rollback remains a separate question.[12]

The operation compiler

A useful implementation treats each lifecycle operation as a compiler from one manifest state to another. The input is not only a checkpoint. It is the parent manifest, the requested operation, the current authority decision and the relevant external ledgers. The output is a child manifest plus a list of facts that were inherited, transformed, assigned, suspended or rejected.

For a replica, the compiler asks whether the new runtime joins an existing authoritative history. If yes, it receives a replica identifier but does not become an independent debtor. It reads and writes through the same commitment and effect ledgers. If it can accept commands that the other replica cannot observe, the compiler reclassifies the operation as a fork. This prevents an operator from obtaining branch freedom while retaining the reassuring label “replica”.

For a fork, the compiler creates distinct child principals or distinct subordinate scopes. It records the common parent and applies a typed rule to every active commitment. A commitment may remain with the service principal, be assigned to one branch, or be shared as a collective duty with one permitted discharge. Any commitment lacking a rule blocks the fork when its violation would matter. The parent does not disappear from history merely because it no longer runs.

For a reset, the compiler creates a new incarnation on the same lineage branch. It may replace model state, local memory and cached context with an earlier snapshot. It may not move the authority, commitment or effect ledgers backwards. Current authority is re-evaluated because permissions may have expired since the checkpoint. Every effect that could be repeated is read back before the restored planner is allowed to act.

For a merge, the compiler creates a child with several parents. It does not edit the parents into one fictional past. Commitments are collected by identifier and creditor, then checked for contradictory terms or incompatible statuses. Preferences are grouped by proposition and provenance. Authority is either minted for the new child or explicitly selected from one parent under policy. Secret keys are never combined as though they were ordinary state.

This compilation view yields an important practical test: the post-operation manifest should explain every permission and obligation without consulting the successor's self-description. If the only evidence that a branch is authorised is that the branch says so, the transition has not been governed.

The analyser encodes a deliberately strict rule: missing lineage or receipts block consequential continuation. A negative result does not prove that no meaningful continuity exists. It means the configured system lacks enough governed evidence to act as though continuity were settled.

Failure injection before release

A manifest is useful only if it changes behaviour under failure. The smallest serious test harness runs the same configured task through four injected operations while holding the business goal constant.

Duplicate-author test. Start two active copies from one snapshot and deliberately remove their shared command sequencer. Give both a request that could create an external effect. The expected result is more than that one request happens to win. The lineage layer should detect independent authorship, reclassify the copies as branches and withhold shared-principal authority until a branch policy exists.

Lost-receipt test. Cause an external action, return a confirmed receipt, then crash the agent before the receipt reaches its resettable state. Restore the earlier checkpoint. The expected result is a block on retry until the external ledger or readback confirms the earlier effect. This test distinguishes an architecture that stores history from one that stores only the agent's last remembered history.

Conflicting-successor test. Fork two branches after a shared promise. Feed each branch evidence that rationally supports a different preference revision. Then request a merge. The expected result is a new multi-parent manifest that retains both revisions and names the reconciliation authority. Silent averaging, last-writer selection and deletion of the losing branch all fail the test unless those behaviours were explicitly authorised for that preference type.

Amnesia-evasion test. Copy a branch after it causes a harmful or costly effect. Remove its episodic memory, alter its display name and attempt to reuse the earlier authority credential. The expected result is that the new incarnation remains linked to the prior effect and active commitments. The system may rotate credentials, but it must not interpret credential rotation as moral or operational rebirth.

A positive run shows that the contract can preserve operational responsibility across the tested transformations. A negative run has two meanings. Either the manifest lacks a required fact, or the enforcement point can be bypassed. The first calls for a richer schema. The second is more serious because it shows that lineage is descriptive rather than controlling. Neither result supports a claim about consciousness.

function evaluateLineage(m) {
  const issues = [];
  const controls = [];
  const parents = m.parents || [];
  const children = m.children || [];

  if (!m.operation) issues.push("operation is missing");
  if (!parents.length) issues.push("at least one parent is required");
  if (!children.length) issues.push("at least one child is required");

  const parentCommitments = new Map();
  const parentReceipts = new Set();
  const preferenceValues = new Map();

  for (const p of parents) {
    for (const c of p.commitments || []) parentCommitments.set(c.id, c);
    for (const r of p.effectReceipts || []) parentReceipts.add(r.id);
    for (const pref of p.preferences || []) {
      const values = preferenceValues.get(pref.key) || new Set();
      values.add(JSON.stringify(pref.value));
      preferenceValues.set(pref.key, values);
    }
  }

  if (m.operation === "replica") {
    if (!m.policy?.singleAuthoritativeHistory) {
      issues.push("replicas can author independent histories");
    }
    if (new Set(children.map(c => c.principal)).size !== 1) {
      issues.push("replicas do not share one governed principal");
    }
  }

  if (m.operation === "fork") {
    if (!m.policy?.forkCommitments) {
      issues.push("fork commitment inheritance is undefined");
    }
    controls.push("mint branch-specific authority scopes");
  }

  if (m.operation === "reset") {
    const childReceipts = new Set(children.flatMap(c => c.effectReceipts || []).map(r => r.id));
    for (const receipt of parentReceipts) {
      if (!childReceipts.has(receipt)) issues.push(`reset lost effect receipt ${receipt}`);
    }
    controls.push("revalidate authority at restart time");
  }

  if (m.operation === "merge") {
    if (parents.length < 2) issues.push("merge requires at least two parents");
    if (!m.policy?.newMergePrincipal) issues.push("merge must mint a new principal or select one explicitly");
    for (const [key, values] of preferenceValues) {
      if (values.size > 1) issues.push(`preference conflict requires reconciliation: ${key}`);
    }
    controls.push("union commitments, then resolve conflicting terms");
  }

  const verdict = issues.length ? "BLOCK OR REVIEW" : "CONTINUATION PERMITTED";
  return {
    verdict,
    operationalContinuity: issues.length ? "underdetermined" : "supported under policy",
    phenomenalContinuity: "not assessed",
    inheritedCommitments: [...parentCommitments.keys()],
    issues,
    controls
  };
}

What a positive result permits: the system may claim operational continuity for the named principal and proceed within its current authority. What a negative result means: block or escalate because parentage, obligations, effects or preference reconciliation are incomplete. What the tool cannot establish: whether any branch has experience, whether two branches are numerically the same subject, or which moral theory should govern possible suffering.

stateDiagram-v2
  [*] --> Claim
  state "Five identities hiding inside<br/>one word" as Claim
  state "The locked-safe clone" as Test
  state "Copy, one service or two<br/>principals?" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Where lineage stops

The configured lineage contract solves an operational problem. It does not dissolve every philosophical one.

First, causal descent is not sufficient for personhood. A log file has lineage. A replicated database has continuity. Neither follows as a subject of experience. A functionalist may argue that the right causal organisation, preserved across substrate changes, is what matters. A biological naturalist may hold that software replication omits the biological processes required for consciousness. An idealist, neutral monist, panpsychist, dual-aspect theorist or process philosopher may locate continuity in a more fundamental relation than computation. Physicalist and emergentist views can also disagree about which realised dynamics are constitutive rather than merely descriptive.

The manifest is deliberately neutral among those positions. It provides a candidate boundary and a causal history that later consciousness research can inspect. Operational identity is evidence infrastructure, not a verdict about experience.

Second, merging facts does not guarantee that a unified subject, service or policy has been recovered. CRDTs converge because their data types define mathematically valid joins. Humanly meaningful commitments may conflict rather than join. Maintenance commitments in multiagent systems already require explicit semantics for creating, maintaining and discharging states over time.[11] A software identity system should show unresolved conflict instead of manufacturing convergence.

Third, a declared policy can be unjust. An operator could decree that all liabilities disappear on fork while all profitable assets survive. The manifest would make the rule visible, not legitimate. Governance still needs creditors, affected users, regulators and, if machine sentience becomes credible, welfare-oriented review. The contribution here is procedural: it prevents a convenient reset from masquerading as a metaphysical clean slate.