UPIP: Universal Process Integrity Protocol with Task Capsules, Work Corridors, and Fork Tokens

1.1. Problem Statement

Existing solutions address parts of process integrity:¶

• Version control (git) tracks code state but not execution¶

• Container images (OCI) capture environment but not intent¶

• CI/CD pipelines orchestrate execution but provide no cross-machine reproducibility proof¶

• Package managers record dependencies but not their usage context¶

None provide a unified, self-verifying bundle that captures the complete execution context with cryptographic chain of custody across actor boundaries.¶

1.2. Design Principles

EVIDENCE OVER ENFORCEMENT: UPIP proves what happened and reports validation outcomes. It does not itself execute or admit a transition. A consuming application or target may refuse according to local policy; the evidence remains independently inspectable.¶

HASH CHAIN INTEGRITY: Every layer is independently hashed. The stack hash chains them. Fork hashes chain into the fork chain. Tampering with any component invalidates the chain.¶

ACTOR AGNOSTICISM: Actors may be human operators, AI agents, automated scripts, services, or identity-bearing endpoints for IoT peripherals. A keyless peripheral is not thereby an autonomous actor; its accountable endpoint carries identity. The protocol otherwise makes no assumption about actor type.¶

TRANSPORT AGNOSTICISM: UPIP bundles are JSON documents. They can be transferred via file copy, HTTP API, message queue, I-Poll, or physical media.¶

CONTINUITY IS NOT AUTHORITY: A process may continue, resume, fork, or be carried without being admitted for a concrete action. UPIP evidence may inform admission; it does not replace admission.¶

CEREMONY IS NOT AUTHORITY: A human-facing ceremony runner can walk an operator through a UPIP-shaped process. The ceremony runner does not decide whether the resulting transition may execute.¶

4.1. L1 STATE - Input State Capture

L1 captures the complete input state before execution. The state_type field determines the capture method:¶

{
  "state_type": "git | files | image | empty",
  "state_hash": "<type>:<hash>",
  "captured_at": "<ISO-8601 timestamp>"
}

State Types:¶

git

Hash is the git commit SHA. MUST include git_remote and git_branch. state_hash prefix: "git:"¶

files

Hash is SHA-256 of the sorted file manifest. state_hash prefix: "files:"¶

image

Hash is the container image digest. state_hash prefix: "image:"¶

empty

No input state. state_hash: "empty:0"¶

For "git" type, additional fields:¶

• git_remote: Repository URL¶
• git_branch: Branch name¶
• git_dirty: Boolean, true if uncommitted changes exist¶

For "files" type, additional fields:¶

• file_count: Number of files captured¶
• total_size: Total size in bytes¶
• manifest: Optional array of {path, hash, size} objects¶

4.2. L2 DEPS - Dependency Snapshot

L2 captures the exact dependency set at execution time.¶

{
  "python_version": "<major.minor.patch>",
  "packages": { "<name>": "<version>" },
  "system_packages": [ "<name>=<version>" ],
  "deps_hash": "deps:sha256:<hex>",
  "captured_at": "<ISO-8601 timestamp>"
}

The deps_hash MUST be computed as SHA-256 of the sorted, deterministic serialization of all package name:version pairs.¶

While this specification uses Python as the reference implementation, L2 is language-agnostic. Other implementations MAY substitute appropriate dependency metadata for their runtime environment (e.g., Cargo.lock for Rust, go.sum for Go, package-lock.json for Node.js).¶

4.3. L3 PROCESS - Execution Definition

L3 defines what was executed and why. The "intent" field maps to TIBET ERACHTER [TIBET] and the "actor" field uses JIS identifier format [JIS].¶

{
  "command": [ "<arg0>", "<arg1>" ],
  "intent": "<human-readable purpose>",
  "actor": "<actor identity (JIS format)>",
  "env_vars": { "<key>": "<value>" },
  "working_dir": "<path>"
}

The command field MUST be an array of strings, not a shell command string. This prevents injection attacks and ensures deterministic execution.¶

The intent field MUST be a human-readable string describing WHY this process is being run. This serves as the ERACHTER (intent) component for TIBET integration.¶

The actor field MUST identify the entity that initiated the process using JIS identifier format. This may be a human operator, AI agent (IDD), or system service.¶

4.4. L4 RESULT - Output Capture

L4 captures the execution result.¶

{
  "success": true,
  "exit_code": 0,
  "stdout": "<captured stdout>",
  "stderr": "<captured stderr>",
  "result_hash": "sha256:<hex>",
  "files_changed": 3,
  "diff": "<unified diff of file changes>",
  "captured_at": "<ISO-8601 timestamp>"
}

The result_hash MUST be computed as SHA-256 of the concatenation of: exit_code (as string) + stdout + stderr.¶

If execution occurs in an airlock, the diff field SHOULD contain the unified diff of all file changes detected.¶

4.5. L5 VERIFY - Cross-Machine Proof

L5 records verification attempts when the UPIP stack is reproduced on another machine.¶

{
  "machine": "<hostname or identifier>",
  "verified_at": "<ISO-8601 timestamp>",
  "match": true,
  "environment": { "os": "linux", "arch": "x86_64" },
  "original_hash": "upip:sha256:<hex>",
  "reproduced_hash": "upip:sha256:<hex>"
}

The match field MUST be true only if reproduced_hash equals original_hash.¶

L5 is an array, allowing multiple verification records from different machines. Each verification is independent.¶

4.6. Stack Hash Computation

The stack hash MUST be computed as follows:¶

1. Serialize each layer hash as a UTF-8 string: L1: state.state_hash, L2: deps.deps_hash, L3: SHA-256(canonical_json(process)), L4: result.result_hash¶
2. Concatenate with pipe separator: L1 + "|" + L2 + "|" + L3 + "|" + L4¶
3. Compute SHA-256 of the concatenated UTF-8 string¶
4. Prefix with "upip:sha256:"¶

Result: "upip:sha256:4f2e8a..."¶

The canonical_json() function is defined in Section 4.7.¶

4.7. Canonical Serialization

Before hashing, JSON objects MUST be serialized to canonical form:¶

1. All object keys sorted lexicographically by Unicode code point.¶
2. No whitespace between tokens.¶
3. Strings use only [RFC8259] escape sequences.¶
4. Numbers use shortest representation without leading zeros.¶

This ensures deterministic hashing across implementations. The same canonical serialization is used in TIBET [TIBET] Section 5.1.¶

5.1. Fork Token Structure

A fork token MUST be a [RFC8259] JSON object with the following fields. Actor fields use JIS identifier format [JIS]:¶

{
  "fork_id": "fork-<uuid>",
  "parent_hash": "sha256:<hex>",
  "parent_stack_hash": "upip:sha256:<hex>",
  "continuation_point": "L<n>:<position>",
  "intent_snapshot": "<human-readable purpose>",
  "active_memory_hash": "sha256:<hex>",
  "memory_ref": "<path or URL to memory blob>",
  "fork_type": "script|ai_to_ai|human_to_ai|fragment",
  "actor_from": "<JIS actor identifier>",
  "actor_to": "<JIS actor identifier or *>",
  "actor_handoff": "<from> -> <to>",
  "capability_required": { },
  "forked_at": "<ISO-8601 timestamp>",
  "expires_at": "<ISO-8601 timestamp or empty>",
  "fork_hash": "fork:sha256:<hex>",
  "partial_layers": { },
  "metadata": { }
}

The actor_to field MAY be empty, indicating the fork is available to any capable actor. In this case, actor_handoff MUST use "*" as the target: "ActorA -> *".¶

5.2. Fork Types

script

The UPIP bundle IS the complete state. No external memory blob is needed. Used for CLI pipelines, CI/CD, and batch processing. The active_memory_hash is computed from the L1+L2+L3+L4 layer hashes.¶

ai_to_ai

The AI actor's context window is serialized as a binary blob (.blob file). The active_memory_hash is the SHA-256 of this blob. The memory_ref field SHOULD point to the blob's location.¶

human_to_ai

A human creates an intent document (natural language instructions) and delegates to an AI actor. The active_memory_hash is the SHA-256 of the intent document.¶

fragment

A parallel fork (Fork-Squared). The parent process is split into N sub-tasks, each receiving a fork token of type "fragment" with the specific portion assigned.¶

5.3. Fork Hash Computation

The fork hash MUST be computed as follows:¶

1. Concatenate with pipe separator: fork_id + "|" + parent_hash + "|" + parent_stack_hash + "|" + continuation_point + "|" + intent_snapshot + "|" + active_memory_hash + "|" + actor_handoff + "|" + fork_type¶
2. Compute SHA-256 of the concatenated string¶
3. Prefix with "fork:sha256:"¶

Result: "fork:sha256:7d3f..."¶

This ensures that modifying ANY field invalidates the fork.¶

5.4. Active Memory Hash

The active_memory_hash captures cognitive or computational state at fork time.¶

For fork_type "script":

SHA-256(state_hash + "|" + deps_hash + "|" + process_intent + "|" + result_hash)¶

For fork_type "ai_to_ai":

SHA-256 of the serialized AI context window (.blob file).¶

For fork_type "human_to_ai":

SHA-256(contents of intent document)¶

For fork_type "fragment":

SHA-256(fragment specification)¶

This field is EVIDENCE, not a reproducibility guarantee. Exact reproduction of AI state is generally not achievable. The hash proves what the state WAS at fork time, enabling audit and comparison.¶

Implementations MUST NOT require exact memory reproduction for fork validation.¶

5.5. Capability Requirements

The capability_required field specifies what the resuming actor needs:¶

{
  "capability_required": {
    "deps": ["package>=version"],
    "gpu": true,
    "min_memory_gb": 16,
    "platform": "linux/amd64",
    "custom": { }
  }
}

On resume, the receiving actor SHOULD verify these requirements and record the result in the verification record. UPIP reports missing capabilities as evidence and does not itself execute or admit the transition. The consuming application or target MAY refuse according to local policy.¶

5.6. Fork Chain

The fork_chain field in the UPIP stack is an ordered array of fork token references:¶

{
  "fork_chain": [
    {
      "fork_id": "fork-abc123",
      "fork_hash": "fork:sha256:...",
      "actor_handoff": "A -> B",
      "forked_at": "2026-03-29T14:00:00Z"
    }
  ]
}

When a process is resumed, the new UPIP stack MUST include the fork token in its fork_chain. This creates a complete audit trail of all handoffs.¶

6.1. Capture and Run

Input: command, source_dir, intent, actor¶

Output: UPIP stack with L1-L4 populated¶

1. Capture L1 STATE from source_dir¶
2. Capture L2 DEPS from current environment¶
3. Define L3 PROCESS from command and intent¶
4. Execute command in airlock¶
5. Capture L4 RESULT¶
6. Compute stack_hash¶
7. Return UPIP stack¶

6.2. Reproduce

Input: UPIP stack (.upip.json), target machine¶

Output: L5 VERIFY record¶

1. Load UPIP stack from file¶
2. Restore L1 STATE (checkout git, extract files)¶
3. Verify L2 DEPS match (warn on mismatches)¶
4. Execute L3 PROCESS in airlock¶
5. Capture L4 RESULT on target machine¶
6. Compare result_hash with original¶
7. Create L5 VERIFY record¶
8. Return verification result¶

6.3. Fork

Input: UPIP stack, actor_from, actor_to, intent¶

Output: Fork Token¶

1. Load UPIP stack¶
2. Compute active_memory_hash from L1-L4¶
3. Snapshot partial_layers (hash + key fields per layer)¶
4. Generate fork_id¶
5. Compute fork_hash¶
6. Create Fork Token¶
7. Append to fork_chain in parent stack¶
8. Return Fork Token¶

6.4. Resume

Input: Fork Token (.fork.json), command, actor¶

Output: New UPIP stack, verification record¶

1. Load Fork Token¶
2. Recompute fork_hash and compare (tamper check)¶
3. Check capability_required against local environment¶
4. Execute command in airlock (shadow-run)¶
5. Capture new UPIP stack (L1-L4)¶
6. Copy fork_chain from parent, append this fork¶
7. Create L5 VERIFY with fork validation results¶
8. Return new stack + verification¶

6.5. Fragment (Parallel Forking)

Input: UPIP stack, N fragments, actor list¶

Output: N Fork Tokens of type "fragment"¶

1. Load UPIP stack¶
2. Define fragment specification (how to split)¶
3. For each fragment i in 1..N: Create Fork Token with fork_type="fragment", set fragment-specific metadata (index, total, range), and deliver to actor[i].¶
4. Wait for N ACKs¶
5. Verify all fragment hashes¶
6. Reconstruct combined result¶

Fragment tokens MUST include metadata fields:¶

• fragment_index: Position in sequence (0-based)¶
• fragment_total: Total number of fragments¶
• fragment_spec: Description of this fragment's portion¶

6.6. Work Corridors and Groove Markers

A work corridor is a bounded continuation window for a task, install, recovery, maintenance operation, or multi-actor process. A corridor is named by a session_ref or equivalent work_chain_ref.¶

The session_ref answers:¶

  Which walk or corridor is this?

A groove answers:¶

  Do these marks belong to the same walk?

A groove MUST be fresh per corridor and MUST be derived or advanced causally from prior corridor material. A groove MUST NOT be treated as identity, mandate, standing, admission, or authority. A valid groove proves only continuity of marks within the named corridor.¶

A corridor step MAY contain:¶

   {
     "session_ref": "mss-2026-09-18-a",
     "task_ref": "install.example.v1",
     "previous_groove": "sha256:...",
     "next_groove_commitment": "sha256:...",
     "snapshot_ref": "sha256:...",
     "actor": "jasper-admin.aint",
     "on_behalf_of": "jasper.aint",
     "receipt_refs": []
   }

Consumers SHOULD distinguish at least the following groove outcomes:¶

  groove_match:
     The expected mark was presented for this corridor.

  groove_missing:
     The next step failed to present the expected mark.

  groove_mismatch:
     A mark was presented but does not match this corridor's
     expected mark.

  groove_from_wrong_session:
     A mark appears valid in form but belongs to another
     session_ref.

  groove_expired:
     The mark was valid for an earlier window but not for the
     current corridor.

These outcomes are evidence for process continuity. They do not decide whether the target may execute the requested transition.¶

At the end of a corridor, a clock-out or equivalent close step MAY seal a portable session capsule. Such a capsule SHOULD include before/after snapshot refs, changed refs where known, task refs, session refs, groove-chain summary, actor, on_behalf_of, receipt refs, and open ends.¶

A runtime/incarnation reference is context inside the capsule, not the custody endpoint. A runtime may disappear. The evidence must not. Deployments SHOULD bind long-term custody to the accountable principal, organization, or archive lane rather than to a volatile runtime.¶

6.7. Actiond and Installation Ceremonies

A UPIP task capsule may be rendered to a human or operator by a ceremony runner such as actiond. The ceremony runner mediates intent into canonical local verbs and records the steps taken. It does not become the authority for execution.¶

A typical installation or maintenance flow is:¶

   rolodex / blueprint reference
       -> UPIP task capsule
       -> actiond ceremony
       -> presence / consent / choice where required
       -> canonical local verb
       -> admission or refusal
       -> receipt

The following boundaries MUST be preserved:¶

  Fetching a blueprint is not execution.
  Rendering a ceremony is not admission.
  Human presence is not mandate.
  Capability to carry is not permission to act.
  The UI does not certify its own consequence.

If a transition cannot consume presence evidence because it is already out of state, resolved, refused, or not in scope, the ceremony MUST NOT request presence for that transition. The result SHOULD be recorded with fields equivalent to:¶

   {
     "presence": "not_asked",
     "presence_why": "transition cannot consume presence"
   }

This prevents human evidence from being spent on a question nobody posed.¶

Where a ceremony requests presence, the lifecycle and the carrier window are separate protocol roles. The lifecycle owns the typed question and its result; a fingerprint reader, an NFC exchange, or an Ed25519 LAN channel merely carries that question and answer.¶

A conforming continuation MUST preserve these boundaries:¶

  presence.request identifies one actor, operation, target,
  lane, window, and challenge.

  presence.response records the carrier outcome for that exact
  question. A matching response is evidence; it is not a bind.

  presence.bind records that a named consumer verified and
  consumed that evidence for the same question.

  admission remains a separate target- or policy-side decision
  for the concrete transition.

Implementations MUST NOT reuse a response across a different lane, window, challenge, actor, operation, or target. A historical match MUST NOT become fresh presence for a later transition. A bind may accompany either admission or refusal and grants no reusable authority.¶

7.1. Stack Validation

A UPIP stack is valid if and only if:¶

1. All required fields are present¶
2. state_hash matches SHA-256 of the canonical state data¶
3. deps_hash matches SHA-256 of the canonical dependency data¶
4. result_hash matches SHA-256 of exit_code + stdout + stderr¶
5. stack_hash matches SHA-256(L1 || L2 || L3 || L4)¶

Validation MUST be performed when loading a .upip.json file and SHOULD be performed before reproduction.¶

7.2. Fork Validation on Resume

When resuming a fork token, the following checks MUST be performed:¶

1. FORK HASH: Recompute fork_hash from token fields and compare with stored fork_hash.¶
2. STORED HASH: Compare fork_hash with the hash in the .fork.json file header.¶
3. CAPABILITIES: Verify each entry in capability_required against the local environment.¶
4. EXPIRATION: Check expires_at if present.¶

All four checks MUST be recorded in the L5 VERIFY record.¶

7.3. Failure Behavior

This section specifies what happens when validation fails.¶

Hash mismatch (stack_hash or fork_hash): - MUST be recorded as tamper evidence - SHOULD trigger enhanced logging for subsequent actions - The UPIP layer reports evidence and does not execute or admit the transition itself - The consuming application or target decides whether to proceed and MAY refuse according to local policy¶

Capability mismatch: - MUST be recorded in L5 VERIFY - Missing GPU when GPU required: record as "degraded" - Missing dependency: record as "incomplete_deps" - Each mismatch is classified:¶

     FATAL:    Execution cannot proceed (e.g., wrong OS)
     DEGRADED: Execution possible but results may differ
     MINOR:    Cosmetic difference (e.g., locale)

FATAL mismatches SHOULD trigger a warning to the operator. UPIP records the mismatch; the operator, consuming application, or target decides whether the concrete transition is admissible.¶

Expiration: - Expired forks SHOULD generate a warning - MUST be recorded in L5 VERIFY - MUST NOT be represented as current continuation evidence - The consumer or target MAY refuse the transition¶

7.4. Tamper Evidence

If fork_hash validation fails:¶

{
  "fork_hash_match": false,
  "expected_hash": "fork:sha256:<original>",
  "computed_hash": "fork:sha256:<recomputed>",
  "tamper_evidence": true,
  "fields_checked": ["fork_id", "parent_hash", "..."]
}

This creates an evidence record that tampering occurred. The decision to act on tamper evidence is a local policy decision.¶

7.5. Process Change Ladder

UPIP consumers MUST NOT collapse deployment or runtime changes into a single "updated" state. The following are distinct:¶

  file_copied:
     Bytes were copied to a location.

  package_carried:
     A package or capsule was transported or made available.

  process_restarted:
     A running process was restarted.

  behavior_changed:
     The observed behavior changed.

  consumer_observed:
     A named consumer read or acted on the new material.

  fleet_converged:
     All intended consumers in a fleet were observed at the
     intended version or state.

Implementations SHOULD record which of these transitions was observed. File copy, package carriage, process restart, behavior change, and fleet convergence are different facts.¶

8.1. File-Based Transport

UPIP stacks use the ".upip.json" extension. Fork tokens use the ".fork.json" extension. Task capsules MAY use ".upip.json", ".task.upip.json", or a sealed carrier format such as ".tza" when carried with custody and envelope metadata.¶

Content-Type for HTTP: application/upip+json (stacks), application/upip-fork+json (fork tokens).¶

A .tza/TBZ carrier may physically carry multiple logical roles. Implementations MUST distinguish those roles:¶

  UPIP task capsule:
     Process blueprint or continuation evidence.

  Rolodex info disk:
     Vocabulary, index, or meaning hints.

  Carrier envelope:
     Custody and transport wrapper.

  Admission receipt:
     Decision or effect evidence.

The same carrier may contain several roles, but finding one role MUST NOT imply another. In particular, finding a task capsule or rolodex reference MUST NOT execute the task.¶

8.2. I-Poll Delivery

Fork tokens MAY be delivered via I-Poll TASK messages. I-Poll is OPTIONAL; UPIP does not depend on I-Poll.¶

Fork tokens are delivered via I-Poll TASK messages:¶

{
  "from_agent": "<source agent>",
  "to_agent": "<target agent>",
  "content": "<human-readable fork summary>",
  "poll_type": "TASK",
  "metadata": {
    "upip_fork": true,
    "fork_id": "<fork_id>",
    "fork_hash": "fork:sha256:<hex>",
    "fork_type": "<type>",
    "continuation_point": "<point>",
    "actor_handoff": "<from> -> <to>",
    "fork_data": { }
  }
}

The "upip_fork" metadata flag MUST be true to identify this message as a fork delivery.¶

The "fork_data" field MUST contain the complete fork token as defined in Section 5.1. This allows the receiving agent to reconstruct the fork token without needing the .fork.json file.¶

After processing a fork token, the receiving actor SHOULD send an ACK message:¶

{
  "from_agent": "<resuming agent>",
  "to_agent": "<original agent>",
  "content": "FORK RESUMED_OK -- <fork_id>",
  "poll_type": "ACK",
  "metadata": {
    "upip_fork": true,
    "fork_id": "<fork_id>",
    "fork_status": "RESUMED_OK",
    "resume_hash": "upip:sha256:<hex>",
    "resumed_by": "<agent identity>"
  }
}

The resume_hash is the stack_hash of the new UPIP stack created during resume.¶

The fork_status field MUST be one of "RESUMED_OK" or "RESUMED_FAIL".¶

8.3. Alternative Transports

UPIP stacks and fork tokens MAY be transported via:¶

• File transfer (USB, network share, S3)¶
• HTTP POST/PUT¶
• Message queues (Kafka, AMQP, NATS)¶
• gRPC streams¶
• Email attachment¶

The format and validation rules apply regardless of transport.¶

9.1. Sensitive Data in Layers

L3 PROCESS may contain sensitive command arguments. L4 RESULT may contain sensitive output. Implementations MUST support encryption at rest for stored UPIP stacks. Implementations SHOULD support per-layer encryption.¶

9.2. Memory Blob Protection

For ai_to_ai forks, the memory blob (.blob file) may contain the AI's full context window, which could include sensitive user data. Memory blobs MUST be encrypted at rest. Implementations SHOULD encrypt memory blobs in transit.¶

10.1. Hash Chain Integrity

UPIP uses SHA-256 for all hash computations. Implementations MUST use SHA-256 as defined in [FIPS180-4]. The hash prefix ("sha256:", "upip:", "fork:") provides algorithm agility for future migration. Future versions MAY support SHA-3 or other hash functions via an algorithm identifier prefix.¶

The hash chain structure ensures that modifying any component at any layer propagates to the stack hash, providing tamper evidence for the entire bundle.¶

10.2. Evidence vs. Enforcement

UPIP is deliberately designed as an evidence protocol, not an enforcement protocol. Fork validation failures do not block execution; they are recorded as evidence. This design choice reflects the reality that:¶

• In adversarial environments, enforcement can be circumvented¶
• Evidence creates accountability that enforcement cannot¶
• Downstream consumers can make their own trust decisions based on the evidence chain¶

Applications that require enforcement SHOULD implement additional policy layers on top of UPIP evidence. UPIP evidence chains are designed to satisfy audit and traceability requirements in regulatory frameworks such as the EU AI Act [EU-AI-ACT] and the NIST AI Risk Management Framework [NIST-AI-RMF].¶

10.3. Memory Hash for AI Actors

When fork_type is "ai_to_ai", the active_memory_hash represents the SHA-256 of the serialized AI context window. This raises unique considerations:¶

• Context serialization format is model-dependent¶
• The blob may contain sensitive information¶
• Exact reproduction of AI state is generally not possible¶

The active_memory_hash is evidence of state at fork time, not a reproducibility guarantee. This is explicitly informational. Implementations MUST NOT treat memory hash verification as a pass/fail gate.¶

Implementations SHOULD encrypt memory blobs at rest. Implementations MUST NOT require exact memory reproduction for fork validation. The memory hash serves as evidence of state at fork time, not as a reproducibility guarantee.¶

10.4. Capability Verification

Capability requirements in fork tokens are self-reported by the forking actor. The receiving actor SHOULD independently verify capabilities rather than trusting the requirement specification alone.¶

Package version verification SHOULD use installed package metadata. GPU availability SHOULD be verified via hardware detection, not configuration claims.¶

10.5. Replay Attacks

Fork tokens include fork_id and forked_at fields to mitigate replay attacks. Implementations SHOULD track consumed fork_ids and reject duplicate fork_ids within a configurable time window.¶

The expires_at field provides time-based expiration. Agents SHOULD set expires_at for forks that are time-sensitive.¶

10.6. Stolen Fork Tokens

Attack: An adversary obtains a fork token intended for another actor.¶

Impact: The adversary can execute the continuation, possibly with malicious modifications.¶

Mitigation: Fork tokens with actor_to set to a specific actor restrict intended recipients. The fork hash includes actor_handoff, so changing the recipient invalidates the hash. For open forks (actor_to = "*"), the first valid resume creates an evidence chain that subsequent attempts can be compared against.¶

Deployment: Use specific actor_to values for sensitive processes. Set short expires_at for time-sensitive forks. Monitor for duplicate fork_id resume attempts.¶

10.7. Unauthorized Resume

Attack: An actor resumes a fork they are not authorized for.¶

Impact: Process continues with unauthorized actor.¶

Mitigation: The resume creates a TIBET token identifying the resuming actor. The actor_to check is evidence, not enforcement. The evidence chain records who actually resumed.¶

Deployment: Implementations SHOULD alert when the resuming actor differs from actor_to.¶

10.8. Partial Capability Spoofing

Attack: An actor claims to meet capability requirements (e.g., claims GPU when none exists).¶

Impact: Process executes in degraded environment, producing potentially unreliable results.¶

Mitigation: Capability verification SHOULD use hardware detection, not configuration claims. The L5 VERIFY record captures actual environment details. Mismatches between claimed and detected capabilities are recorded as evidence.¶

Deployment: Use hardware detection APIs (e.g., CUDA device query for GPU). Do not trust self-reported capabilities.¶

10.9. Continuity and Carrier Laundering

Attack: A receiver treats continuity evidence, carrier availability, or a valid groove as proof that an action is authorized.¶

Impact: A process continuation, task capsule, or work corridor is allowed to act beyond its mandate. A copied capsule or replayed corridor mark may be mistaken for a fresh admission.¶

Mitigation: UPIP artifacts MUST be interpreted as evidence of process shape, continuation, or custody only. Admission of a concrete transition remains outside UPIP and MUST be evaluated by the target or local policy layer. Implementations SHOULD record explicit fields for "not_admitted", "not_evaluated", "not_asked", and "not_consumed" instead of collapsing them into failure.¶

Deployment: Gate high-impact transitions through fresh admission and record the receipt. Do not allow a valid task capsule, can-carry result, or groove match to bypass admission.¶

11.1. TIBET Integration

Each UPIP operation MAY produce TIBET [TIBET] tokens:¶

• Capture: token recording what was captured and why¶
• Fork: token recording the handoff with ERACHTER¶
• Resume: token recording who resumed and the validation result¶

The L3 PROCESS "intent" field maps to TIBET ERACHTER. Fork tokens reference TIBET chains in their provenance.¶

11.2. JIS Integration

Actor identifiers in UPIP use JIS format (Section 3.4 of [JIS]). Fork token actor_from and actor_to use JIS identifiers, enabling signature verification through JIS key resolution.¶

11.3. AINS Integration

AINS [AINS] provides discovery of actors for fork delivery. An actor_to value can be resolved through AINS to determine the delivery endpoint.¶

11.4. RVP Integration

RVP [RVP] may provide fresh presence or verification evidence for a UPIP-shaped transition. RVP evidence is consumed only when the concrete transition requires it. Presence evidence does not prove mandate, authority, or admission.¶

11.5. Actiond / Human Ceremony Integration

A ceremony runner such as actiond may render a UPIP task capsule to a human and route chosen intent to canonical local verbs. The runner records what was shown, chosen, refused, or completed. It does not certify its own consequence.¶

12.1. Media Type Registrations

This document requests registration of:¶

Type: application/upip+json (UPIP stack bundles)¶

Type: application/upip-fork+json (UPIP fork tokens)¶

Note: The -00 version requested X-UPIP-* HTTP header registration. This is withdrawn as not justified at this stage.¶

C.1. Multi-Agent AI Task Delegation

An AI orchestrator (Agent A) analyzes a dataset, creates a UPIP bundle, forks it to a specialist AI (Agent B) for deep analysis, and receives the result with cryptographic proof.¶

Agent A:
  capture_and_run(["python", "scan.py"], intent="Initial scan")
  fork_upip(actor_from="A", actor_to="B", intent="Deep analysis")
  deliver_fork(fork, to_agent="B")

Agent B:
  pull_forks()
  resume_upip(fork, command=["python", "deep_analyze.py"])
  ack_fork(fork, resume_hash=stack.hash, success=True)

Result: Both agents have UPIP stacks linked by fork_chain. Any auditor can verify the complete chain.¶

C.2. Drone Swarm Coordination

A command station dispatches N reconnaissance tasks to N drones. Each drone receives a fragment fork token, executes its assigned sector scan, and returns the result.¶

Command Station:
  base_stack = capture_and_run(["mission_plan.py"])
  for i in range(N):
    fork = fork_upip(base_stack,
                     actor_from="command",
                     actor_to=f"drone-{i}",
                     fork_type="fragment",
                     metadata={"sector": sectors[i]})
    deliver_fork(fork, to_agent=f"drone-{i}")

Each Drone:
  fork_msg = pull_forks()
  stack = resume_upip(fork, command=["scan_sector.py"])
  ack_fork(fork, resume_hash=stack.hash)

Command Station:
  # Verify all N results, reconstruct combined map
  for ack in collect_acks():
    verify(ack.resume_hash)

C.3. Scientific Experiment Reproduction

Lab A publishes an experiment as a UPIP bundle. Lab B reproduces it independently and gets cryptographic proof that results match (or don't).¶

Lab A:
  stack = capture_and_run(
    ["python", "train_model.py"],
    source_dir="./experiment",
    intent="Train model v3 on dataset-2026Q1"
  )
  save_upip(stack, "experiment-2026Q1.upip.json")
  # Publish to journal / data repository

Lab B:
  stack = load_upip("experiment-2026Q1.upip.json")
  verify = reproduce_upip(stack)
  # verify.match == True: exact reproduction
  # verify.match == False: divergence (investigate)

D.1. Changes from -00 to -01

1. Added RFC 8174 alongside RFC 2119.¶

2. Changed intended status from Standards Track to Informational.¶

3. Added version field "1.1" to UPIP stack.¶

4. Added canonical serialization section (4.7), consistent with TIBET [TIBET] Section 5.1.¶

5. Added failure behavior specification (Section 7.3): what happens on hash mismatch, capability mismatch, and expiration. Each failure type classified as FATAL, DEGRADED, or MINOR.¶

6. Added Security Considerations for stolen fork tokens (10.6), unauthorized resume (10.7), and partial capability spoofing (10.8).¶

7. Added Privacy Considerations section (Section 9).¶

8. Clarified active_memory_hash as evidence-only, not reproducibility guarantee (emphasized in 5.4 and 10.3).¶

9. Made I-Poll transport explicitly optional (Section 8.2). UPIP does not depend on I-Poll.¶

10. Removed X-UPIP-* HTTP header registration from IANA.¶

11. Normalized companion protocol references to [TIBET], [JIS], [RVP], [AINS].¶

12. Actor identifiers now use JIS format throughout.¶

13. Added Integration section (Section 11) describing specific touchpoints with TIBET, JIS, and AINS.¶