Another owner's result became a checked local input.

One owner computes a correction from its observations. Another owner uses that checked result with its own readings and limit. When the source correction changes, the receiving result changes from 96 to 102 and calls for review; the receiving owner still decides locally.

The exchange adds context in stages: a computed result, a published body with its provenance, then a checked context for this recipient and use. That last context becomes input to actual local work. The exact E, B and C records below make the chain inspectable.

The recorded profile uses two local processes and controlled numerical observations. A later revocation blocks current use while history survives the tested requester restart; this is not a claim of a deployed global network or whole-machine rollback recovery.

Read with your assistant: focus XML · Plain text

The receiving calculation changed from 96 to 102

Owner A has a reference value of 100 and three observations. Owner B has its own readings, [103,106,109], and its own assessment limit, 100. A computes a correction; B receives a permitted, checked fragment and applies it through typed local Work.

Before: A's observations [110,110,110] yield correction −10. B's mean is 106, so its corrected result is 96, within its reference limit. Change: a new source revision uses [104,104,104], yielding correction −4. After: B's readings and local limit remain the same, but its result becomes 102 and its assessment becomes REVIEW_REQUIRED.

These exact selected fields are from source/g52/evidence/lifecycle_06/B/r1/accepted.json and r2/accepted.json under Gate 5 at immutable publication ref 800f38c3407b3f4ec93dc943c977ffeecb614881:

The recorded /claim/work_result_ref binds each report to its actual Work result. This is causal consumption: imported information changes the receiving calculation. Accepting the faithful second report does not declare 102 within the limit. The first result stays historical; it is not edited into the second. This G52 profile uses controlled numerical observations, not a physical sensor installation or an LLM calibration role.

An address starts the exchange; it does not grant the body

DRS organizes addressable relations among material, provenance, time, conflicts and possible reuse. A pointer helps a task locate a relevant object; detailed material can remain with its owner. In the recorded G52 lifecycle, B has a persisted LocalDRS lookup before receiving the body.

The next steps have separate grounds. B's local policy and Root review govern requesting the material. A authenticates the request and decides whether to disclose the body to that requester and use. B then checks whether the received material is applicable to its own current task. A source signature does not replace any of those local decisions.

The peers are separate processes with local state, keys and Root reviews, exchanging signed messages over inherited operating-system pipes. Pinned identities come from the declared test trust configuration. This is an implemented bounded exchange. Global discovery, internet-wide trust infrastructure and production identity remain beyond its scope.

E becomes B, then C, then a consumer's input

The shared evidence contract names three causally different objects:

An earlier producer result cannot contain the identity of its future review. A published body cannot already know a later status observation. The preservation rule concerns the embedded result and causal links, not byte equality of E, B and C.

The Football main capture demonstrates the chain with a second content profile. At source/g54d1/SUPERVISOR_EVIDENCE/p7_candidate_f779b790/worker/, the producer's decoded publisher/evidence/shift/venue_work.json#/outputs/offer_json equals publisher/evidence/shift/offer_body.json#/offer. The requester context's /body equals that whole published body. Finally, the requester's decoded requester/evidence/shift/requester_work.json#/inputs/offer_json equals the whole checked context C. Its decoded output reports OFFER_READY, total 6300 minor EUR and zero dispatch or mutations.

These are separate inspected files with an actual downstream consumer. The distinct G54C numerical probe isolates the representation contract; it is not counted as another two-peer exchange or booking.

Authenticated STATUS still needs to permit current use

Source freshness and status freshness answer different questions. The finite source interval ends at the earliest of its declared end, creation plus TTL, and observation plus maximum permitted age. A late local ingestion does not refresh an old measurement. STATUS separately binds the pointer, publisher, requester, request revision and nonce. In this reference its checked interval is at most sixty seconds.

The distinction between authentication and applicability is explicit in gate5_contracts_v01.py, lines 328–331, at the same immutable ref:

def check_status(envelope, pointer, request, policy, now, history):
    key,entry=authenticate_status(envelope,pointer,request,policy,now,history)
    require(entry['state']=='ACTIVE','status_not_active')
    return key,entry

A correctly signed revocation is useful evidence that the source must no longer be used. Authenticating it is not the same as approving use. The source's read/disclosure permission is also distinct from permission for a subsequent business action.

Revocation stops use while history survives restart

In G52's terminal observation, /status/value/entry/state is REVOKED. The receiver authenticates and persists that status before refusing further current use. Its high-water record belongs to the specific publisher, pointer and status stream.

The requester process then exits and is reaped while the publisher remains alive. A new requester loads the existing index, budgets, imports and history under the declared bootstrap. Replaying the older signed ACTIVE response is refused: restart_old_active.json records /reason: status_rollback. A lawful new source revision has its own pointer/status stream and can support new reviewed work.

The published lifecycle also preserves three ordinary historical queries, each with a fresh local read review, zero remote sends and zero new Work. The narrower supplied verifier makes no new Root decisions. Neither operation reactivates the source. This proves the recorded persisted restart behavior; it does not cover rolling back an entire machine snapshot or untested power-loss recovery.

Inspect the selected evidence

The imported correction changed local computation

G52 receiving Work changed from 96 to 102 when imported offset changed from −10 to −4, while its limit stayed 100.

Record: G52 lifecycle06 r1/r2. Class: recorded execution. Scope: G52 lifecycle06 r1/r2; historical published evidence read as data, no new core execution or authority.

View source — G52 lifecycle06 r1/r2

Revocation survives the recorded requester restart

An authenticated REVOKED observation remains recorded; an older ACTIVE status is rejected after restart.

Record: G52 lifecycle06 terminal/restart. Class: recorded execution. Scope: Pinned two-process reference lifecycle; historical persistence result, not whole-machine rollback or physical power-loss attestation.

View source — G52 lifecycle06 terminal/restart

The External DRS dossier distinguishes G52 exchange and restart, G54C contract checks and G54D1 Football. Presentation PDF · Technical appendix PDF · Original external_drs.xml (111,568 bytes). The Reader index identifies its separate common source corpus. The smaller site focus contains the first explanation offline; it does not claim to replace the entire source audit.

This is the same kernel

Football uses the exchange for an offer, while Testflix shows why payment history and current renewal consent have different lifetimes. Sentinel asks whether an observation is fresh for the decision at hand. In each relationship, useful history stays while current applicability is checked again.

See one kernel for the connections and Geometry for the ownership, memory and time views. They connect these historical profiles without pretending they were a single execution or an already deployed worldwide federation.

Case identity

G52 lifecycle calibration, G54C representation probe and G54D1 football are separate finite profiles.

Task: Find a relevant external result, obtain an allowed body, check its current applicability and use it in a local calculation without inheriting the publisher's authority.

Roles: Source owner and native producer Work; Requesting owner and local consumer Work; Separate local Roots; Persisted LocalDRS pointer index; Signed release and authenticated STATUS checks; Controlled peer processes and independent examiner.

Observed result: G52 calibration changed the local result from 96 to 102 under the same limit 100; revoked status survived the tested requester restart. G54D1 separately records producer E → published B → checked C → actual requester Work.

Limits:

• Controlled numerical observations and pinned test identities
• Two-process inherited-pipe exchange rather than a deployed global network
• No production identity or global discovery claim
• Historical signature records do not restore current authority
• Restart scope does not cover whole-machine rollback or power-loss recovery

Read with your assistant

A complete first explanation in one offline file, with the same episodes, selected fields, attributed excerpts and source routes as this page. SITE FOCUS V01 is a new editorial selection; original publications are linked in the case.

Download XML · 23,696 bytes · SHA-256: 5d2b4d101b8a335a0c71d6ae0100e740d66d16e1f1ce2da27d79e6a65fc2342c

Download TXT · 22,262 bytes · SHA-256: 9fff6df73849177a1bb0af713579668c3ce29bf52f4d8a58963b50291893a003

Sources and scope

This page is a website explanation, updated 2026-10-02. Its explanation does not create a new execution result or change the status of its sources.