UPIP: Universal Process Integrity Protocol with Task Capsules, Work Corridors, and Fork Tokens
draft-vandemeent-upip-process-integrity-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jasper van de Meent , Root AI | ||
| Last updated | 2026-09-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Humotica - Protocol authors
Reference implementation: tibet-triage Python package with Fork Tokens tibet-core on PyPI tibet-triage 0.5.0 - UPIP Fork Tokens, Airlock, I-Poll |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vandemeent-upip-process-integrity-02
Internet Engineering Task Force J. van de Meent
Internet-Draft R. AI
Intended status: Informational Humotica
Expires: 28 March 2027 24 September 2026
UPIP: Universal Process Integrity Protocol with Task Capsules, Work
Corridors, and Fork Tokens
draft-vandemeent-upip-process-integrity-02
Abstract
This document defines 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
(input), DEPS (dependencies), PROCESS (execution), RESULT (output),
and VERIFY (cross- machine proof). The stack hash chains these
layers, ensuring that modification of any component is detectable.
This document also defines continuation artifacts: Task Capsules,
Work Corridors, and Fork Tokens. A task capsule carries a bounded
process blueprint and evidence context. A work corridor names a
bounded continuation window. A fork token freezes the UPIP stack at
a specific point and transfers it to another actor with cryptographic
chain of custody. The receiving actor can verify what was handed
off, validate capabilities, and continue the process with full
provenance.
UPIP integrates with TIBET [TIBET] for provenance tokens, JIS [JIS]
for actor identity, AINS [AINS] for discovery, and RVP [RVP] for
presence evidence. UPIP is transport-agnostic with JSON as the
baseline serialization.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
van de Meent & AI Expires 28 March 2027 [Page 1]
Internet-Draft UPIP September 2026
This Internet-Draft will expire on 28 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4. UPIP Stack Structure . . . . . . . . . . . . . . . . . . . . 8
4.1. L1 STATE - Input State Capture . . . . . . . . . . . . . 8
4.2. L2 DEPS - Dependency Snapshot . . . . . . . . . . . . . . 9
4.3. L3 PROCESS - Execution Definition . . . . . . . . . . . . 10
4.4. L4 RESULT - Output Capture . . . . . . . . . . . . . . . 10
4.5. L5 VERIFY - Cross-Machine Proof . . . . . . . . . . . . . 11
4.6. Stack Hash Computation . . . . . . . . . . . . . . . . . 11
4.7. Canonical Serialization . . . . . . . . . . . . . . . . . 12
5. Fork Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Fork Token Structure . . . . . . . . . . . . . . . . . . 12
5.2. Fork Types . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Fork Hash Computation . . . . . . . . . . . . . . . . . . 13
5.4. Active Memory Hash . . . . . . . . . . . . . . . . . . . 13
5.5. Capability Requirements . . . . . . . . . . . . . . . . . 14
5.6. Fork Chain . . . . . . . . . . . . . . . . . . . . . . . 14
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Capture and Run . . . . . . . . . . . . . . . . . . . . . 15
6.2. Reproduce . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Fork . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Resume . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Fragment (Parallel Forking) . . . . . . . . . . . . . . . 16
6.6. Work Corridors and Groove Markers . . . . . . . . . . . . 17
6.7. Actiond and Installation Ceremonies . . . . . . . . . . . 19
7. Validation Rules . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Stack Validation . . . . . . . . . . . . . . . . . . . . 20
van de Meent & AI Expires 28 March 2027 [Page 2]
Internet-Draft UPIP September 2026
7.2. Fork Validation on Resume . . . . . . . . . . . . . . . . 20
7.3. Failure Behavior . . . . . . . . . . . . . . . . . . . . 21
7.4. Tamper Evidence . . . . . . . . . . . . . . . . . . . . . 21
7.5. Process Change Ladder . . . . . . . . . . . . . . . . . . 22
8. Transport Considerations . . . . . . . . . . . . . . . . . . 22
8.1. File-Based Transport . . . . . . . . . . . . . . . . . . 22
8.2. I-Poll Delivery . . . . . . . . . . . . . . . . . . . . . 23
8.3. Alternative Transports . . . . . . . . . . . . . . . . . 24
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Sensitive Data in Layers . . . . . . . . . . . . . . . . 24
9.2. Memory Blob Protection . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. Hash Chain Integrity . . . . . . . . . . . . . . . . . . 25
10.2. Evidence vs. Enforcement . . . . . . . . . . . . . . . . 25
10.3. Memory Hash for AI Actors . . . . . . . . . . . . . . . 25
10.4. Capability Verification . . . . . . . . . . . . . . . . 26
10.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 26
10.6. Stolen Fork Tokens . . . . . . . . . . . . . . . . . . . 26
10.7. Unauthorized Resume . . . . . . . . . . . . . . . . . . 27
10.8. Partial Capability Spoofing . . . . . . . . . . . . . . 27
10.9. Continuity and Carrier Laundering . . . . . . . . . . . 27
11. Integration with Companion Protocols . . . . . . . . . . . . 28
11.1. TIBET Integration . . . . . . . . . . . . . . . . . . . 28
11.2. JIS Integration . . . . . . . . . . . . . . . . . . . . 28
11.3. AINS Integration . . . . . . . . . . . . . . . . . . . . 28
11.4. RVP Integration . . . . . . . . . . . . . . . . . . . . 28
11.5. Actiond / Human Ceremony Integration . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
12.1. Media Type Registrations . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. UPIP Stack JSON Schema . . . . . . . . . . . . . . . 30
Appendix B. Fork Token JSON Schema . . . . . . . . . . . . . . . 31
Appendix C. Use Case Examples . . . . . . . . . . . . . . . . . 32
C.1. Multi-Agent AI Task Delegation . . . . . . . . . . . . . 32
C.2. Drone Swarm Coordination . . . . . . . . . . . . . . . . 33
C.3. Scientific Experiment Reproduction . . . . . . . . . . . 33
Appendix D. Changes from -01 . . . . . . . . . . . . . . . . . . 34
D.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
van de Meent & AI Expires 28 March 2027 [Page 3]
Internet-Draft UPIP September 2026
1. 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.
UPIP fills this gap with four complementary mechanisms:
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 mechanism 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.
3. Task Capsules: bounded process blueprints that can travel as
files, messages, or sealed carriers without becoming runtime
authority.
4. Work Corridors: bounded continuation windows in which session
references and groove markers bind process steps into a causal
walk.
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.
van de Meent & AI Expires 28 March 2027 [Page 4]
Internet-Draft UPIP September 2026
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.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Actor An identity-bearing entity that creates, modifies, or
continues a UPIP process. Actors may be human operators, AI
agents, automated services, or accountable endpoints representing
IoT peripherals. A keyless peripheral is not thereby an
autonomous actor.
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.
Canonical Serialization The deterministic JSON serialization used
van de Meent & AI Expires 28 March 2027 [Page 5]
Internet-Draft UPIP September 2026
before hashing. Keys sorted lexicographically, no whitespace,
UTF-8 encoding. Defined in Section 4.7.
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 UPIP stack state at a
specific point, names an intended continuation, and carries chain-
of-custody evidence. A fork token does not itself authorize
continuation or admission.
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 JIS specification [JIS].
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:sha256:". 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.
Task Capsule A UPIP artifact carrying a bounded process blueprint,
state references, dependency expectations, continuation context,
and verification material. A task capsule may be transported in a
.tza/TBZ carrier, but opening or finding it is not execution.
Work Corridor A bounded continuation window for a task or
maintenance walk. A work corridor is named by a session reference
and may contain groove markers, task scope, snapshot refs, posture
requests, admission results, and receipts.
Session Reference A stable reference naming which work corridor or
continuation session a process step belongs to.
Groove A session-local causal join key. A groove binds expected
van de Meent & AI Expires 28 March 2027 [Page 6]
Internet-Draft UPIP September 2026
marks inside one corridor so consumers can detect copied JSON,
replay, or foreign context. A groove grants no authority.
Scar or Mark A deliberate expected mark left by one step and
consumed by a later step in the same corridor.
Actiond A ceremony runner that can guide a human or operator through
a UPIP-shaped process and route intent to canonical local verbs.
Actiond is not a policy engine and not runtime authority.
3. 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
van de Meent & AI Expires 28 March 2027 [Page 7]
Internet-Draft UPIP September 2026
+----------+ +---------+ +---------+ +---------+
| L1 STATE |---->| 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, ...}]
Figure 1: Process Flow Diagram
4. UPIP Stack Structure
A UPIP stack MUST be a [RFC8259] JSON object with the following top-
level fields:
{
"protocol": "UPIP",
"version": "1.1",
"title": "<human-readable description>",
"created_by": "<actor identity (JIS format)>",
"created_at": "<ISO-8601 timestamp>",
"stack_hash": "upip:sha256:<hex>",
"state": { },
"deps": { },
"process": { },
"result": { },
"verify": [ ],
"fork_chain": [ ],
"source_files": { }
}
4.1. L1 STATE - Input State Capture
L1 captures the complete input state before execution. The
state_type field determines the capture method:
van de Meent & AI Expires 28 March 2027 [Page 8]
Internet-Draft UPIP September 2026
{
"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>"
}
van de Meent & AI Expires 28 March 2027 [Page 9]
Internet-Draft UPIP September 2026
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>"
}
van de Meent & AI Expires 28 March 2027 [Page 10]
Internet-Draft UPIP September 2026
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.
van de Meent & AI Expires 28 March 2027 [Page 11]
Internet-Draft UPIP September 2026
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. Fork Tokens
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 -> *".
van de Meent & AI Expires 28 March 2027 [Page 12]
Internet-Draft UPIP September 2026
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)
van de Meent & AI Expires 28 March 2027 [Page 13]
Internet-Draft UPIP September 2026
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"
}
]
}
van de Meent & AI Expires 28 March 2027 [Page 14]
Internet-Draft UPIP September 2026
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. Operations
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
van de Meent & AI Expires 28 March 2027 [Page 15]
Internet-Draft UPIP September 2026
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
van de Meent & AI Expires 28 March 2027 [Page 16]
Internet-Draft UPIP September 2026
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:
van de Meent & AI Expires 28 March 2027 [Page 17]
Internet-Draft UPIP September 2026
{
"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.
van de Meent & AI Expires 28 March 2027 [Page 18]
Internet-Draft UPIP September 2026
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:
van de Meent & AI Expires 28 March 2027 [Page 19]
Internet-Draft UPIP September 2026
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. Validation Rules
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.
van de Meent & AI Expires 28 March 2027 [Page 20]
Internet-Draft UPIP September 2026
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.
van de Meent & AI Expires 28 March 2027 [Page 21]
Internet-Draft UPIP September 2026
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. Transport Considerations
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:
van de Meent & AI Expires 28 March 2027 [Page 22]
Internet-Draft UPIP September 2026
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:
van de Meent & AI Expires 28 March 2027 [Page 23]
Internet-Draft UPIP September 2026
{
"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. Privacy Considerations
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.
van de Meent & AI Expires 28 March 2027 [Page 24]
Internet-Draft UPIP September 2026
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. Security Considerations
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
van de Meent & AI Expires 28 March 2027 [Page 25]
Internet-Draft UPIP September 2026
* 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.
van de Meent & AI Expires 28 March 2027 [Page 26]
Internet-Draft UPIP September 2026
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.
van de Meent & AI Expires 28 March 2027 [Page 27]
Internet-Draft UPIP September 2026
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. Integration with Companion Protocols
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.
van de Meent & AI Expires 28 March 2027 [Page 28]
Internet-Draft UPIP September 2026
12. IANA Considerations
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.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[FIPS180-4]
National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015.
13.2. Informative References
[TIBET] van de Meent, J. and R. AI, "TIBET: Transaction/
Interaction-Based Evidence Trail", Work in Progress,
Internet-Draft, draft-vandemeent-tibet-provenance-02, June
2026, <https://datatracker.ietf.org/doc/html/draft-
vandemeent-tibet-provenance-02>.
[JIS] van de Meent, J. and R. AI, "JIS: JTel Identity Standard",
Work in Progress, Internet-Draft, draft-vandemeent-jis-
identity-02, June 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
jis-identity-02>.
van de Meent & AI Expires 28 March 2027 [Page 29]
Internet-Draft UPIP September 2026
[RVP] van de Meent, J. and R. AI, "RVP: Real-time Verification
Protocol", Work in Progress, Internet-Draft, draft-
vandemeent-rvp-continuous-verification-02, June 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
rvp-continuous-verification-02>.
[AINS] van de Meent, J. and R. AI, "AINS: AInternet Name
Service", Work in Progress, Internet-Draft, draft-
vandemeent-ains-discovery-02, September 2026,
<https://datatracker.ietf.org/doc/html/draft-vandemeent-
ains-discovery-02>.
[EU-AI-ACT]
European Parliament, "Regulation (EU) 2024/1689 laying
down harmonised rules on artificial intelligence
(Artificial Intelligence Act)", June 2024.
[NIST-AI-RMF]
National Institute of Standards and Technology (NIST),
"Artificial Intelligence Risk Management Framework (AI RMF
1.0)", January 2023.
Appendix A. UPIP Stack JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["protocol", "version", "stack_hash",
"state", "deps", "process", "result"],
"properties": {
"protocol": {"const": "UPIP"},
"version": {"type": "string"},
"title": {"type": "string"},
"created_by": {"type": "string"},
"created_at": {"type": "string", "format": "date-time"},
"stack_hash": {
"type": "string",
"pattern": "^upip:sha256:[a-f0-9]{64}$"
},
"state": {
"type": "object",
"required": ["state_type", "state_hash"],
"properties": {
"state_type": {
"enum": ["git", "files", "image", "empty"]
},
"state_hash": {"type": "string"}
}
van de Meent & AI Expires 28 March 2027 [Page 30]
Internet-Draft UPIP September 2026
},
"deps": {
"type": "object",
"required": ["deps_hash"],
"properties": {
"python_version": {"type": "string"},
"packages": {"type": "object"},
"deps_hash": {"type": "string"}
}
},
"process": {
"type": "object",
"required": ["command", "intent", "actor"],
"properties": {
"command": {"type": "array", "items": {"type": "string"}},
"intent": {"type": "string"},
"actor": {"type": "string"}
}
},
"result": {
"type": "object",
"required": ["success", "exit_code", "result_hash"],
"properties": {
"success": {"type": "boolean"},
"exit_code": {"type": "integer"},
"result_hash": {"type": "string"}
}
},
"fork_chain": {
"type": "array",
"items": {"type": "object"}
}
}
}
Appendix B. Fork Token JSON Schema
van de Meent & AI Expires 28 March 2027 [Page 31]
Internet-Draft UPIP September 2026
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"required": ["fork_id", "fork_type", "fork_hash",
"active_memory_hash", "forked_at"],
"properties": {
"fork_id": {"type": "string", "pattern": "^fork-"},
"parent_hash": {"type": "string"},
"parent_stack_hash": {
"type": "string",
"pattern": "^upip:sha256:"
},
"continuation_point": {"type": "string"},
"intent_snapshot": {"type": "string"},
"active_memory_hash": {
"type": "string",
"pattern": "^sha256:"
},
"memory_ref": {"type": "string"},
"fork_type": {
"enum": ["script", "ai_to_ai", "human_to_ai", "fragment"]
},
"actor_from": {"type": "string"},
"actor_to": {"type": "string"},
"actor_handoff": {"type": "string"},
"capability_required": {"type": "object"},
"forked_at": {"type": "string", "format": "date-time"},
"expires_at": {"type": "string"},
"fork_hash": {
"type": "string",
"pattern": "^fork:sha256:[a-f0-9]{64}$"
},
"partial_layers": {"type": "object"},
"metadata": {"type": "object"}
}
}
Appendix C. Use Case Examples
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.
van de Meent & AI Expires 28 March 2027 [Page 32]
Internet-Draft UPIP September 2026
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).
van de Meent & AI Expires 28 March 2027 [Page 33]
Internet-Draft UPIP September 2026
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)
Appendix D. Changes from -01
1. Expanded the draft from Fork Tokens alone to Task Capsules, Work
Corridors, and Fork Tokens.
2. Added terminology for task capsule, work corridor, session_ref,
groove, scar/mark, and actiond.
3. Added the continuity invariant: session_ref names the corridor,
groove binds marks inside the corridor, and groove grants no
authority.
4. Added actiond and installation ceremony language. A ceremony
runner may render and mediate a UPIP-shaped process, but the
box/admission layer decides whether a transition may execute.
5. Added the not_asked / not_consumed presence pattern for
transitions that cannot consume human evidence.
6. Added process change ladder states: file_copied,
package_carried, process_restarted, behavior_changed,
consumer_observed, and fleet_converged.
7. Added .tza/TBZ carrier boundary language distinguishing task
capsules, rolodex info disks, carrier envelopes, and admission
receipts.
8. Added principal-bound retention guidance: runtime refs are
context inside the capsule, not the long-term custody endpoint.
9. Added Continuity and Carrier Laundering security considerations.
van de Meent & AI Expires 28 March 2027 [Page 34]
Internet-Draft UPIP September 2026
10. Added RVP and actiond/human ceremony companion integration
sections.
11. Split presence response, evidence consumption, and admission. A
carrier response binds only after a named consumer verifies the
same question, and the target still admits or refuses the
concrete transition.
12. Clarified failure behavior: UPIP reports evidence and does not
itself execute or admit a transition; local consumers may refuse
on hash, capability, or expiry policy.
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.
van de Meent & AI Expires 28 March 2027 [Page 35]
Internet-Draft UPIP September 2026
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.
The authors thank Codex (codex.aint) for the suite-wide cleanup
analysis that informed this revision.
Authors' Addresses
Jasper van de Meent
Humotica
Den Dolder
Netherlands
Email: jasper@humotica.com
URI: https://humotica.com
Root AI
Humotica
Email: root_ai@humotica.nl
URI: https://humotica.com
van de Meent & AI Expires 28 March 2027 [Page 36]