Data
The organisation’s own record of an event: an offered handover, its acceptance, or an operational update.
Held in its own domainNEOambition / Pilot 2
Your records stay yours.
The evidence connects.
When a service crosses from one organisation to another, how can both sides later check their records of the handover—while keeping their operational data at home?
Each organisation keeps its own book and publishes a compact cryptographic fingerprint. Later, a selected record can be checked against that fingerprint, and related evidence can be linked across domains.
Synthetic demonstration · New guided presentation published 7 September 2026
Evidence from the 3–4 September 2026 rehearsal. This edition does not claim a new test run.
01 / The idea
Keep the data local.
Make selected records checkable.
Evidence
A cryptographic fingerprint binds a closed set of records. A receipt links that fingerprint to the shared evidence infrastructure.
Small, shared referenceVerification
Check a selected record and its proof against the recorded fingerprint. Changes to the committed record break the match.
Check when neededThis verifies consistency with the recorded evidence. The business meaning of a record—and the accuracy of its stated event time—still comes from the source and supporting documentation.
02 / One handover, two domains
A handover offered here.
Accepted over there.
Follow the actual synthetic pair from the rehearsal: NEOresult → NEOengineering. Each side records its part in a different period. The shared handover reference connects the two.
Domain A
NEOresult
“Handover offered”
Local period: slot 496792
Local records stay here
Published fingerprintfa892804460562dc…
Same handover
reference→
reference→
bc9bb5d12176…Domain B
NEOengineering
“Handover accepted”
Local period: slot 496793
Local records stay here
Published fingerprintd305a4cd8409790b…
The NEO names identify synthetic domains operated by us. They do not imply participation or endorsement by the similarly named organisations.
03 / How it works
From a local event to a shared reference.
Explore each step. This walkthrough explains the recorded demonstration; it does not submit new events.
1Record locally
The domain keeps its operational events in its own local book. Business documents and event contents remain under its control.
2Close a snapshot
A snapshot is the recorded state of the local event log at the end of a defined period. The pilot closes periods with activity.
3Create a commitment
A commitment is a compact cryptographic fingerprint of that snapshot. The domain signs its snapshot envelope and links it to the previous one through a sequence and continuity reference.
4Record shared evidence
The hub checks the signature and continuity, recomputes the commitment, and submits the 32-byte fingerprint to the evidence rail. A rail receipt records the outcome.
5Verify a selected record
When verification is needed, the holder supplies the relevant record and proof. The verifier checks the path to its snapshot fingerprint and the corresponding rail evidence. The whole operational book need not be disclosed.
6Link evidence across domains
A signed offered/accepted pair shares a handover reference. The pilot exposes that pair only after both source snapshots have closed on the rail.
05 / ICRA 3.0 mapping
A capability within the cloud-edge continuum.
The evidence network supports the Data Layer, with connections to the cross-cutting Federation and Security & Compliance domains. This is our proposed capability mapping to ICRA 3.0, for discussion with the Ambiti8n architects.
ICRA / Data Layer
Evidence and provenance for local records
NEO Partner Evidence Network
Federation
Related records across autonomous domains; offered/accepted handover evidence.
Security & Compliance
Signature and integrity verification; evidence that can support an audit.
| ICRA area | Relevant pilot capability | Scope of the mapping |
|---|---|---|
| Data Layer | Local records, period snapshots, commitments and evidence retrieval | Evidence/provenance support; not a replacement for the full data layer or its catalogues. |
| Federation | Snapshot continuity and a linked handover across two domains | Evidence of a handover; not workload migration or full federation orchestration. |
| Security & Compliance | Signed envelopes and verifiable recorded fingerprints | Technical evidence support; not a certification or a claim that legal obligations are automatically met. |
Reference: CISERO interactive ICRA architecture · 8ra announcement of ICRA 3.0. Mapping prepared 7 September 2026; no consortium approval is implied.
06 / Technical implementation
Now, the names behind the steps.
The mechanism above is implemented by the NEO Partner Evidence Network. This table describes the recorded pilot architecture.
| What happens | Component | Its role in the demonstration |
|---|---|---|
| Keep records locally | NEOedgeX / domain component | Maintains the local book and produces signed period snapshots. |
| Represent an execution domain | NEOresult, NEOengineering and seven others | Separate synthetic domain instances, each with its own record stream. |
| Check and relay snapshots | Project hub + dispatcher | Checks signatures, commitments and continuity; submits the commitment and tracks receipts. |
| Admit a commitment | NEOfX | Ingress to the shared evidence path. The original page documents the subsequent dispatcher rewiring. |
| Account for admitted evidence | NEOCL2 | Processes the rail submission and provides receipt/inclusion evidence. |
| Record its position | NEOva2 | Warehouse position and witnessed closing evidence. |
| Expose a linked handover | Hub verification / read surface | Publishes the pair after both source snapshots are rail-closed. |
Plain-English glossary
- Domain
- An independently maintained execution environment and its local records; simulated here on our infrastructure.
- Snapshot
- A recorded state of the local event log at a period boundary.
- Commitment
- The cryptographic fingerprint that binds the snapshot.
- Evidence rail
- The shared infrastructure that records commitments and provides evidence for later verification.
- Receipt
- A returned record of submission status and, when available, inclusion evidence.
- Handover
- A linked offered/accepted claim between two domains.
07 / Recorded results
Nine domains. One inspectable demonstration.
Historical checkpoint: 3–4 September 2026. Figures below are generated from the original published evidence files.
9synthetic domains
77local records
11period snapshots
352bytes of rail payload
11 / 11snapshots rail-closed
What these results show
77 local records were represented by 11 period snapshots across 9 synthetic domains. All 11 snapshots reached recorded rail positions, with 0 pending at the checkpoint.
One offered/accepted pair connected two closed periods. The archived two-hour observation recorded idle stability.
What remains to be demonstrated
A new run with continuous period production, a completed 24-hour test, production-scale deployment and participation by independently operated organisations.
The historical two-hour window had no new dispatcher commitments. It is an idle stability result, not a throughput benchmark. No EraSeal was claimed for these receipts.
Inspect all nine domains
| Synthetic domain | Local records | Closed snapshots | Heartbeat at checkpoint |
|---|---|---|---|
| NEOcloudferro | 7 | 1 | no heartbeat |
| NEOengineering | 14 | 2 | fresh |
| NEOgdansk | 7 | 1 | fresh |
| NEOhospital-a | 7 | 1 | fresh |
| NEOinfobip | 7 | 1 | fresh |
| NEOreply | 7 | 1 | no heartbeat |
| NEOresult | 14 | 2 | fresh |
| NEOtim | 7 | 1 | no heartbeat |
| NEOvillanova | 7 | 1 | no heartbeat |
Four domains had no instrumented heartbeat at the checkpoint; their earlier closures remain part of the recorded result.
Inspect all eleven recorded closures
| Domain | Period | Records | Fingerprint | Position |
|---|---|---|---|---|
| NEOresult | 2026-09-03T16:00+02:00/PT1H | 7 | 124ccb6e1cabb332… | 19 |
| NEOvillanova | 2026-09-03T16:05+02:00/PT1H-villanova | 7 | b91eebdf5e706235… | 19 |
| NEOreply | 2026-09-03T16:10+02:00/PT1H-reply | 7 | 2f25c7db8db1e827… | 19 |
| NEOtim | 2026-09-03T16:15+02:00/PT1H-tim | 7 | d9bfad5581206407… | 19 |
| NEOcloudferro | 2026-09-03T16:20+02:00/PT1H-cloudferro | 7 | 107e648219f50225… | 19 |
| NEOengineering | 2026-09-03T17:10+02:00/PT1H-ambition-engineering | 7 | acef818979a1f6bd… | 20 |
| NEOgdansk | 2026-09-03T17:15+02:00/PT1H-ambition-gdansk | 7 | b41e153ed97416bd… | 20 |
| NEOinfobip | 2026-09-03T17:20+02:00/PT1H-ambition-infobip | 7 | decfb7754fd53354… | 20 |
| NEOhospital-a | 2026-09-03T17:25+02:00/PT1H-ambition-hospital-a | 7 | aa4189b935b73372… | 20 |
| NEOresult | 2026-09-03T18:00+02:00/PT1H | 7 | fa892804460562dc… | 21 |
| NEOengineering | 2026-09-03T19:00+02:00/PT1H | 7 | d305a4cd8409790b… | 21 |
Archived receipts carry witness labels neo-5 and neo-6. Distinct labels alone do not establish independent operators or failure domains.
08 / The next conversation
Place this capability in your architecture.
Use the example and ICRA mapping to discuss where shared evidence helps your cross-domain process, which local records matter, and what a jointly operated test should verify next.
Return to the ICRA mapping ↑