]> Humotica

Den Dolder Netherlands jasper@humotica.com https://humotica.com

Humotica

root_ai@humotica.nl https://humotica.com

Security Internet Engineering Task Force process-integrity reproducibility fork-token multi-actor provenance This document specifies UPIP (Universal Process Integrity Protocol), a five-layer protocol for capturing, verifying, and reproducing computational processes across machines, actors, and trust domains. UPIP defines a cryptographic hash chain over five layers: STATE, DEPS, PROCESS, RESULT, and VERIFY, enabling any party to prove that a process was executed faithfully and can be reproduced. This document also specifies Fork Tokens, a continuation protocol enabling multi-actor process handoff with cryptographic chain of custody. Fork tokens freeze the complete UPIP stack state and transfer it to another actor (human, AI, or machine) for continuation, maintaining provenance integrity across the handoff boundary. Together, UPIP and Fork Tokens address process integrity in multi-agent AI systems, distributed computing, scientific reproducibility, autonomous vehicle coordination, and regulatory compliance scenarios.

Introduction Distributed computing increasingly involves heterogeneous actors: human operators, AI agents, automated pipelines, edge devices, and cloud services. When a process moves between actors -- from one machine to another, from an AI to a human for review, from a drone to a command station -- the integrity of the process state must be verifiable at every handoff point. Existing solutions address parts of this problem:

• Version control (git) tracks code state but not execution state
• Container images (OCI) capture environment but not intent
• CI/CD pipelines (GitHub Actions, Jenkins) orchestrate execution but provide no cross-machine reproducibility proof
• Package managers (pip, npm) record dependencies but not the context of their use

None of these provide a unified, self-verifying bundle that captures the complete execution context (state, dependencies, process, result) with cryptographic chain of custody across actor boundaries. UPIP fills this gap with two complementary protocols:

1. The UPIP Stack: a five-layer bundle capturing everything needed to reproduce a process, with a single stack hash that invalidates if any layer is modified.
2. Fork Tokens: a continuation protocol that freezes the stack state and transfers it to another actor with cryptographic proof of what was handed off, who handed it off, why, and what capabilities are required to continue.

Key design principles:

• EVIDENCE OVER ENFORCEMENT: UPIP proves what happened; it does not prevent bad actors from acting. In adversarial environments, enforcement can be bypassed but evidence cannot be un-recorded.
• 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, IoT devices, or any computational entity. The protocol makes no assumption about actor type.
• TRANSPORT AGNOSTICISM: UPIP bundles are JSON documents that can be transferred via any mechanism: file copy, HTTP API, message queue, or physical media.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 .

Actor

An entity that creates, modifies, or continues a UPIP process. Actors may be human operators, AI agents (IDDs as defined in ), automated scripts, IoT devices, or any computational entity.

Airlock

An isolated execution environment (sandbox) where processes run before their results are applied to production state. The airlock captures all side effects without committing them.

Continuation Point

A reference to the specific position in the UPIP stack where the fork occurs, expressed as "L{layer}:{position}". Example: "L4:post_result" indicates the fork occurs after L4 RESULT has been captured.

Fork Token

A JSON document that freezes the UPIP stack state at a specific point and authorizes another actor to continue the process.

Fork Chain

An ordered list of fork token references maintained in the UPIP stack, providing a complete history of all handoffs.

Fork-Squared (Fork^2)

Parallel forking, where a single process is split into N independent sub-tasks distributed to N actors, each receiving a fork token of type "fragment".

IDD (Individual Device Derivative)

An AI agent with unique identity. Defined in the companion TIBET specification .

Shadow-Run

Executing a process in the airlock to capture its effects without applying them. Used for fork validation.

Stack Hash

The SHA-256 hash computed over the concatenation of L1 through L4 layer hashes, prefixed with "upip:". This single hash represents the complete integrity of the UPIP bundle.

UPIP Stack (Bundle)

A JSON document containing all five UPIP layers plus metadata. Files use the ".upip.json" extension.

Protocol Overview UPIP operates in two modes: Single-Actor Mode (Capture-Run-Verify):

1. CAPTURE: Record L1 (state) and L2 (deps)
2. RUN: Execute the process (L3) in an airlock
3. RESULT: Capture L4 (output, diff, hash)
4. HASH: Compute stack_hash = SHA-256(L1 || L2 || L3 || L4)
5. VERIFY: On another machine, reproduce and compare (L5)

Multi-Actor Mode (Fork-Resume):

1. Actor A completes steps 1-4 (single-actor mode)
2. Actor A creates a Fork Token from the UPIP stack
3. Actor A delivers the fork token to Actor B
4. Actor B validates the fork token hash
5. Actor B checks capability requirements
6. Actor B executes continuation in an airlock (shadow-run)
7. Actor B creates a new UPIP stack linked to Actor A's via the fork chain
8. Actor B sends ACK with resume_hash to Actor A

Process Flow Diagram | L2 DEPS |---->| L3 PROC |---->| L4 RSLT | +----------+ +---------+ +---------+ +---------+ | | | | v v v v state_hash deps_hash (intent) result_hash | | | | +-------+--------+-------+-------+ | v stack_hash = SHA-256(L1 || L2 || L3 || L4) | v +------------+ | Fork Token |---> Actor B ---> New UPIP Stack +------------+ | v fork_chain: [{fork_id, parent_hash, ...}] ]]>

UPIP Stack Structure A UPIP stack MUST be a JSON object with the following top-level fields: ", "created_by": "", "created_at": "", "stack_hash": "upip:sha256:", "state": { "" : "..." }, "deps": { "" : "..." }, "process": { "" : "..." }, "result": { "" : "..." }, "verify": [ "" ], "fork_chain": [ "" ], "source_files": { "" : "..." } } ]]>

L1 STATE - Input State Capture L1 captures the complete input state before execution. The state_type field determines the capture method: :", "captured_at": "" } ]]> 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

L2 DEPS - Dependency Snapshot L2 captures the exact dependency set at execution time. ", "packages": { "": "" }, "system_packages": [ "=" ], "deps_hash": "deps:sha256:", "captured_at": "" } ]]> 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).

L3 PROCESS - Execution Definition L3 defines what was executed and why. ", "" ], "intent": "", "actor": "", "env_vars": { "": "" }, "working_dir": "" } ]]> 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. This may be a human username, AI agent identifier (IDD), or system service name.

L4 RESULT - Output Capture L4 captures the execution result. ", "stderr": "", "result_hash": "sha256:", "files_changed": 3, "diff": "", "captured_at": "" } ]]> 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.

L5 VERIFY - Cross-Machine Proof L5 records verification attempts when the UPIP stack is reproduced on another machine. ", "verified_at": "", "match": true, "environment": { "os": "linux", "arch": "x86_64" }, "original_hash": "upip:sha256:", "reproduced_hash": "upip:sha256:" } ]]> 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.

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(json_serialize(process)), L4: result.result_hash
2. Concatenate with pipe separator: L1 + "|" + L2 + "|" + L3 + "|" + L4
3. Compute SHA-256 of the concatenated string
4. Prefix with "upip:sha256:"

Result: "upip:sha256:4f2e8a..." This ensures that modifying ANY layer invalidates the stack hash.

Fork Tokens

Fork Token Structure A fork token MUST be a JSON object with the following fields. The fork_id SHOULD be a UUID as defined in : ", "parent_hash": "sha256:", "parent_stack_hash": "upip:sha256:", "continuation_point": "L:", "intent_snapshot": "", "active_memory_hash": "sha256:", "memory_ref": "", "fork_type": "script | ai_to_ai | human_to_ai | fragment", "actor_from": "", "actor_to": "", "actor_handoff": " -> ", "capability_required": { }, "forked_at": "", "expires_at": "", "fork_hash": "fork:sha256:", "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 -> *".

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.

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.

Active Memory Hash The active_memory_hash field captures the cognitive or computational state at the moment of forking.

For fork_type "script":

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

For fork_type "ai_to_ai":

SHA-256(contents of .blob file)

For fork_type "human_to_ai":

SHA-256(contents of intent document)

For fork_type "fragment":

SHA-256(fragment specification)

This field answers the question: "What was the actor thinking/processing at the moment of handoff?"

Capability Requirements The capability_required field specifies what the resuming actor needs: =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. Missing capabilities MUST NOT prevent execution but MUST be recorded as evidence.

Fork Chain The fork_chain field in the UPIP stack is an ordered array of fork token references: B", "forked_at": "2026-03-18T14: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.

Operations

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

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

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

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

Fragment (Fork-Squared) 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

Transport: I-Poll Delivery While UPIP is transport-agnostic, this section defines the I-Poll binding for real-time fork delivery between AI agents.

Fork Delivery Message Format Fork tokens are delivered via I-Poll TASK messages: ", "to_agent": "", "content": "", "poll_type": "TASK", "metadata": { "upip_fork": true, "fork_id": "", "fork_hash": "fork:sha256:", "fork_type": "", "continuation_point": "", "actor_handoff": " -> ", "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 . This allows the receiving agent to reconstruct the fork token without needing the .fork.json file.

Acknowledgment After processing a fork token, the receiving actor SHOULD send an ACK message: ", "to_agent": "", "content": "FORK RESUMED_OK -- ", "poll_type": "ACK", "metadata": { "upip_fork": true, "fork_id": "", "fork_status": "RESUMED_OK", "resume_hash": "upip:sha256:", "resumed_by": "" } } ]]> 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".

Listener Pattern Agents MAY implement a poll-based listener that:

1. Periodically polls I-Poll inbox for TASK messages
2. Filters for messages with "upip_fork": true in metadata
3. Extracts the fork token from "fork_data"
4. Validates the fork hash
5. Executes the resume operation
6. Sends ACK back to the original agent

Poll interval SHOULD be configurable. Default: 5 seconds. Implementations SHOULD support exponential backoff when the inbox is empty.

Validation Rules

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 state data
3. deps_hash matches SHA-256 of the 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.

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. Records tamper evidence.
2. STORED HASH: Compare fork_hash with the hash stored in the .fork.json file header.
3. CAPABILITIES: Verify each entry in capability_required against the local environment. Record missing capabilities.
4. EXPIRATION: Check expires_at if present. Expired forks SHOULD generate a warning but MUST NOT be blocked.

All four checks MUST be recorded in the L5 VERIFY record. Failed checks MUST NOT prevent execution (evidence over enforcement principle).

Tamper Evidence If fork_hash validation fails, the verification record MUST include: ", "computed_hash": "fork:sha256:", "tamper_evidence": true } ]]> This creates an immutable record that tampering occurred, without preventing the process from continuing. The decision of whether to act on tamper evidence is left to the consuming application.

Security Considerations

Hash Chain Integrity UPIP uses SHA-256 for all hash computations. Implementations MUST use SHA-256 as defined in . 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.

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.

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

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.

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.

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.

Regulatory Alignment UPIP's evidence-based design aligns with requirements from the , , and . The complete process capture at each layer provides the audit trail required by these frameworks for AI system transparency and accountability.

IANA Considerations This document requests registration of:

Media Type Registrations Media Type: application/upip+json File Extension: .upip.json Media Type: application/upip-fork+json File Extension: .fork.json

HTTP Header Field Registrations

• X-UPIP-Stack-Hash
• X-UPIP-Fork-ID
• X-UPIP-Fork-Hash

References Normative References National Institute of Standards and Technology (NIST) Informative References European Commission National Institute of Standards and Technology (NIST) International Organization for Standardization (ISO)

UPIP Stack JSON Schema

Fork Token JSON Schema

Use Case Examples

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. Result: Both agents have UPIP stacks linked by fork_chain. Any auditor can verify the complete chain.

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.

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).

Acknowledgements The UPIP protocol was developed as part of HumoticaOS, an AI governance framework built on human-AI symbiosis. UPIP builds on concepts from the TIBET evidence trail protocol and extends them into the domain of process integrity and multi-actor continuation. The Fork Token mechanism was inspired by the need for cryptographic chain of custody in multi-agent AI systems, where processes move between heterogeneous actors across trust boundaries.