Atlas, built on R-Series, is a private evidence explorer in development. It is designed to check signed R-Series receipts, keep each tenant’s records apart, lay them out on a timeline and export an offline bundle that checks without Atlas.
Atlas does not create evidence. R-Series signs the receipts; Atlas is designed to keep them, check them and show what they establish, in five views.
Every route that reads evidence asks for your tenant’s token, and another tenant’s record looks absent.
In development
Request, approval, action, provider response, receipt and incident, rebuilt from indexed receipts only. Nothing is re-run, and a gap is shown as missing.
In development
Related receipts and records become one case. The policy digest signed into each receipt shows which policy applied, version by version.
In development
Original receipt bytes, trust material, key history and the steps to check them, in one package that a separate verifier checks without Atlas or a DCS account.
In development
Scan findings, the approved change and the re-scan, side by side, from the receipts of each scan run.
In development
Atlas is a capability of R-Series, not a separate product. Like every capability, it has no cryptography of its own.
It reaches R-Series evidence through one interface, the R-Series evidence contract: issue, verify, read the key registry and report status. It never holds its own receipt core, key source or verdict logic.
Atlas issues no receipts. Its checks run only through the R-Series SDK, against a trust bundle and pins set by the operator.
Six stations, one rule at each. Receipts enter, are checked and are kept per tenant; the timeline, the case and the export follow.
Atlas keeps the original text byte for byte, under the sha256 of those bytes. A re-serialised copy is never stored as the original.
Each receipt is checked only through the R-Series SDK, with keys from a trust bundle and pins in the operator’s configuration. A key carried inside a receipt is never used, and a receipt with one signature is never valid.
Atlas takes the tenant from the authenticated token, never from the request, and compares it with the tenant signed into the receipt. A header that claims an identity is refused, and another tenant’s receipt is invalid in your workspace.
Index fields come only from the signed body of a receipt that checked valid, each marked observed or asserted. The timeline is designed to be rebuilt from them, never by re-running anything, with gaps shown as missing.
Each receipt carries the digest of the policy it was signed under. The investigation view is designed to group related receipts into a case and show policy versions and their differences; a later interpretation stays a separate record.
A case is designed to export as one offline bundle. A separate verifier opens it with pins it holds itself and checks it without Atlas and without a DCS account.
In development Intake and checks come first; the timeline, the case view and the export follow.
Standard profile: Ed25519 + ML-DSA-65, both signatures required. A higher profile with ML-DSA-87 is in development.
Atlas adds no rule of its own: the verdict is the R-Series engine’s, reported field by field.
| Case | Designed response |
|---|---|
| A receipt with one signature missing or empty | INVALID · MISSING_LEG, and evidence presence INSUFFICIENT |
| A key carried inside the receipt, even the correct one | INVALID · MALFORMED; the carried key is never used |
| Signed bytes edited after signing | INVALID · BAD_SIGNATURE; the carried hash is recomputed, never trusted |
| A receipt signed for another tenant or environment | INVALID · WRONG_TENANT_OR_ENVIRONMENT |
| The same receipt id with different bytes, in one tenant | Refused when it is deposited |
| No pinned trust configured | INVALID for every receipt, never a pass |
| A receipt the old Atlas issued | Kept and labelled; never VALID |
A workspace belongs to one tenant. Nothing in it is public unless an operator turns public routes on.
Tenants sign in with a bearer token. Atlas keeps only its sha256 and compares it in constant time.
The tenant comes from the token. A request that claims an identity in a header is refused.
A tenant cannot read, list or fetch the original of another tenant’s record. The same bytes deposited by two tenants are two separate records.
Public explorer routes are off by default. If an operator turns them on, they show only what a tenant chose to publish.
Cross-site browser access is closed by default and never carries credentials.
Each tenant has its own limits on records, bytes and work, shared across stores and processes.
Durable intake keeps the same rule. The tenant is derived from authentication and storage authorisation, never from a caller-supplied id; restart recovery and an index rebuilt from the originals come with it.
In development
The timeline view is designed to rebuild one run from its receipts: what was asked, who approved it, what ran and what came back. Each step says how it is known.
Each receipt binds the full digest of its policy. Versions and their differences are shown; a later interpretation is a separate record, never merged into the signed one.
A case gathers related receipts and records, and exports as one bundle.
In development
A bundle carries the receipt exactly as issued, the trust material needed to check it and the steps to follow. The person checking holds the pins separately: pins are never bundle content.
In development
No bundle is demonstrated on this page. A demonstration follows only once the bundle work and its checks are accepted, and the bundle format has had its independent cryptographic review.
When a referenced approval, policy or receipt is absent, Atlas is designed to report it as missing or unknown.
In development
A receipt carrying one signature is reported as insufficient evidence and is never valid.
Receipts the old Atlas issued keep their original bytes and carry the label “classical-only, issued before the move, issuer unverified”. They are never shown as valid.
Fields that sat outside the old signature, such as its timestamp and score, are named, and their values are not displayed.
When a chain check reports a gap, the result is incomplete, never complete.
One receipt’s time is the issuer’s stated time, so it is reported as provisional. Atlas claims current verification only, not long-term validity.
Atlas reports the evidence contract’s status fields on every read, recomputed from the original bytes. Nothing combines them into a single verdict.
| Field | Values |
|---|---|
| Verification outcome | VALID or INVALID |
| Reason codes | None when valid; one or more when invalid |
| Lifecycle | CURRENT, HISTORICAL or RETIRED-SUITE |
| Completeness and time | COMPLETE, INCOMPLETE, INDETERMINATE or PROVISIONAL |
| Execution outcome | PLANNED, EXECUTED, DENIED, FAILED or UNKNOWN |
| Custody | HSM_BACKED, DRY_RUN or SOFTWARE_OBSERVATION |
| Evidence presence | PRESENT, UNSIGNED, MISSING, UNKNOWN or INSUFFICIENT |
Atlas used to be a separate product with its own signing key, trust scores and public routes. That authority is retired, not hidden behind a setting.
Atlas is a private workspace: its evidence routes need a tenant token.
Trust scores are removed. Atlas reports the R-Series verdict and computes no score of its own.
Federation and cross-product claim ingestion are retired from Atlas.
Atlas’s public-chain anchoring paths, and its mock anchoring, are retired.
Atlas generates no key and signs nothing; receipts come from R-Series.
This is not a certification. Verification checks that the signed bytes match a key. Trusting the issuer also needs an authenticated key binding and policy checks; a valid signature does not by itself prove that the action happened or was authorised.
The bounded change pilot is a separate offer from the assessment: one approved change through Connector OS, with its receipts and an Atlas before/after bundle.
A person approves one bounded change, tied to the plan, the assets and an expiry.
Connector OS runs the change; denial, failure and rollback are evidenced as well.
R-Series signs receipts for the intent, the approval, the outcome and any rollback.
Atlas shows the state before and after the change, side by side.
An offline bundle is checked by a second process with only the public verifier.
In development For Atlas, customer acceptance means a customer accepting the pilot’s before/after bundle.
Status as of 31 October 2026: In development. Atlas is built on the R-Series engine and is in independent review; ingestion is in development. Receipt V2 revision 7 was issued on 30 October 2026. Evidence Contract v1 was signed with conditions by the programme’s cryptography lead on 30 October 2026. Every statement on this page is drawn from the claim register of that date.
Own cryptography removed, checks through the R-Series SDK, private by default, legacy evidence labelled. In development.
Durable, private intake: tenant from authentication, restart recovery, missing evidence shown, an index rebuilt from the originals.
Timeline, policy history, the offline bundle and the assessment view. The gate: a customer checks the bundle without Atlas.
The bundle format goes through an independent cryptographic review.
The Atlas work as a whole is independently reviewed.
A customer accepts the before/after bundle of a change pilot.
In development No date is set for any gate: the plan fixes the order, not a calendar.
No. Atlas is a capability of R-Series: Atlas, built on R-Series. Its status is in development.
No. Atlas has no cryptography of its own. Receipts come from R-Series, and Atlas checks them only through the R-Series SDK.
No. By design, every evidence route needs your token, the tenant comes from that token, and another tenant’s record looks absent.
They are kept unchanged and labelled “classical-only, issued before the move, issuer unverified”. They are never shown as valid and never re-signed.
That is the design: a separate verifier opens the bundle with pins it holds itself, with no Atlas and no DCS account. The bundle format still needs its independent cryptographic review, so no bundle is demonstrated yet.
No. It means the receipt is authentic, unchanged, and from an issuer the verifier trusts. Whether the action was authorised is answered by the intent and governance receipts it links to.
Atlas claims current verification only. Preservation over long periods is separate work, and until it closes the bundle’s preservation records are empty.
Not yet: Atlas is in development. You can sign and check a sample receipt in your browser on Verify a receipt, and we brief teams on Atlas in a private technical briefing.
Atlas is in development on R-Series. Bring us the evidence your systems produce today, and we will walk through what a private workspace and an offline bundle would need to show.