AttestScopeFR
Menu

The format · version 0.1.1

The format

A record file is plain JSON. Any AI assistant, tool or register can write it, and any auditor can read it and recompute its fingerprint without the tool that made it.

The words of a record

project
the AI output under review
record
what this format captures, like a sealed envelope: the project, the report, the follow-up and their proof
record file
the record saved in a file, which you keep and upload to have it checked
second reader
whoever examines the project: a protocol, an agent or a person
signer
the person who decides and signs
verifier · owner
the human role who checks an assumption · answers a question
follow-up
who checked, who owns each question, the decision
outcome
what became of the decision, months later (planned)
register
where an organisation will keep its register entries (the record without the texts), on its own servers (planned)

Three parts. Each one useful on its own.

  • 01 · Structure

    What was examined

    The project, its context and the second reader’s report, word for word: triage and its criteria, findings ranked by impact, assumptions with a named human verifier, questions with their owners. A structured form for registers is planned.

    content.project · content.context
    content.report

  • 02 · Follow-up

    What the signer did with it

    Filled in by the signer, never by a model: who checked, what they checked themselves, who owns each open question, the decision and a signature, with its own fingerprint, seal and signature. It can name the final document and be completed later, without erasing the previous follow-up. Planned: one closed answer per finding, and months later the outcome.

    follow_up · decision · signature

  • 03 · Proof

    That it was not changed

    A SHA-256 fingerprint, recomputed by every verifier from the record file; the issuer’s seal on it, with its time stamp, and its signature, which anyone checks with the public key. The format provides for qualified time stamps (RFC 3161); at Riftveil, this will be an AttestScope traceability option. The fingerprint lets you confirm a text you already have, without containing it. No ledger: everyone keeps their own record files, and can delete them.

    proof.fingerprint · proof.seal

What sets it apart

  1. 01

    A scope is attested, not a blanket “yes”

    The follow-up says what the person checked themselves, the questions assigned, the decision and its conditions. A structured scope, finding by finding, is planned.

    follow_up.checked · questions · conditions

  2. 02

    Every open question has a named owner

    The report suggests an owner for each question; the signer assigns it to someone, by name.

    questions[].suggested_owner · assigned_to

  3. 03

    The follow-up is written by the person, never by a model

    No model writes, suggests or completes the ID, the fingerprint, the seal or any field of the follow-up.

    Specification §04 · MUST NOT

  4. 04

    Two seals: the assessment, then the decision

    The follow-up has its own fingerprint, which includes that of the report: a follow-up belongs to one report only, and the seal time is inside the sealed message.

    riftveil-seal-v1 · riftveil-decision-v1

  5. 05

    riftveil.ai keeps neither the texts nor a list of records

    The record file stays with the person or in their organisation. The issuer keeps no text, no list of IDs and no list of fingerprints.

    Specification §05 · privacy

  6. 06

    Anyone can verify, without signing up

    The fingerprint is recomputed in the verifier’s browser, which also checks the Ed25519 signature with riftveil.ai’s public key; only the ID, the fingerprints and the seals go to riftveil.ai, which checks the seals.

    POST /api/verify · riftveil.ai/verify

  7. 07

    Independent of the AI assistant

    Report generated on riftveil.ai, or made in another AI assistant and then registered: the origin is distinct, with one seal label per origin.

    riftveil-seal-v1 · riftveil-register-v1

  8. 08

    An open format

    Specification published on attestscope.ai and on GitHub, with a JSON Schema and test vectors: another tool can write or verify a record, under its own issuer prefix.

    0.1 · attestscope.ai

How a record is made

From a review to a proof anyone can check.

Six steps, three actors. A second reader writes the review, the signer fills the follow-up, and the issuer seals the fingerprint. To check a record, anyone recomputes the fingerprint from the record file, then asks the issuer to confirm the seal.

Second readerSignerIssuerAnyoneSECOND READERSIGNERISSUERANYONE1Reviewof the project2Recordfollow-up left empty3Follow-upowners and decision4FingerprintSHA-256, public profile5Sealissuer key6Verifyany third partyreportfollow-up filledfile + sealVerification sends fingerprints only, never the texts.Second readerSignerIssuerAnyoneSECOND READER1Reviewof the project2Recordfollow-up left emptyreportSIGNER3Follow-upowners and decisionfollow-up filledISSUER4FingerprintSHA-256, public profile5Sealissuer keyfile + sealANYONE6Verifyany third partyVerification sends fingerprints only, never thetexts.

No model fills the follow-up. A record leaves step 2 with every follow-up field empty; only the signer fills them in step 3.

The fingerprint follows a published profile. Anyone can recompute it from the record file. Canonical JSON (RFC 8785), for a hash independent of the tool that wrote it, is planned.

Technical layer · version 0.1.1

The format in three diagrams.

The target data model of the format. Version 0.1.1 implements the record file: the texts, their fingerprint, seal and signature, and the follow-up with the decision, the final document and the follow-ups it completes. The structured fields drawn here are planned for the register entry (version 0.2).

1 · Data model

THE REVIEWTHE SIGNERone per findingownerTHE PROOFrecordformat · protocol_versioncontext.stakes_levellevels_appliedindependencehighest_value_questionreaders[ ]type · model_familysessionfindings[ ]id · impact · leveltechnique_idassumptions[ ]id · who_can_verifyif_falsequestions[ ]id · ownerfollow_upanswer: treated | deferred| already_seen | no_stake | wrongowner · atoutcomeplannedanswer: held | corrected| reversed | incident | unknownproofsealedfingerprint · sha256seal · issuertimestampplannedDashed: planned beyond version 0.1.1. Field names as in the specification.THE REVIEWrecordformat · protocol_versioncontext.stakes_levellevels_appliedindependencehighest_value_questionreaders[ ]type · model_familysessionfindings[ ]id · impact · leveltechnique_idassumptions[ ]id · who_can_verifyif_falsequestions[ ]id · ownerTHE SIGNERone per findingfollow_upanswer: treated | deferred| already_seen | no_stake | wrongowner · atowneroutcomeplannedanswer: held | corrected| reversed | incident | unknownTHE PROOFproofsealedfingerprint · sha256seal · issuertimestampplannedDashed: planned beyond version 0.1.1. Field namesas in the specification.

2 · Proof chain

SEAL · ONCE, BY THE ISSUERrecord.jsontexts + follow-upfingerprint inputpublished profileSHA-2569f3c…e71aseal requestissuer · riftveil.aiseal S1-…HMAC over ID + digestVERIFY · ANYONE, WITH THE ISSUER1 recompute the digest from the file2 ask the issuer: is this seal valid?valid · alteredSEAL · ONCE, BY THE ISSUERrecord.jsontexts + follow-upfingerprint inputpublished profileSHA-2569f3c…e71aseal requestissuer · riftveil.aiseal S1-…HMAC over ID + digestVERIFY · ANYONE, WITH THE ISSUER1 recompute the digest from thefile2 ask the issuer:is this seal valid?valid · altered

What the proof establishes

The texts have not changed since the issuer sealed them, at the time given by its clock. The issuer checks the seal, from fingerprints alone; anyone checks the signature with the issuer’s public key. Qualified time stamps (RFC 3161) are planned.

3 · Chain of second readers

independence is checked link by link: never the author, never the same sessionprojectauthor: model family Asession 1second reader 1type: modelfamily B (protocol)separate sessionsecond reader 2type: agentspecialist, optionalfamily B or Csecond reader 3type: humane.g. legal counselnamed rolesignerfollow-updecisionsignatureDashed: optional readers; each will be written into readers[ ] (planned) with its type, model family and session.Second readerSignerindependence is checked link by link:never the author, never the samesessionprojectauthor: model family Asession 1second reader 1type: modelfamily B (protocol)separate sessionsecond reader 2type: agentspecialist, optionalfamily B or Csecond reader 3type: humane.g. legal counselnamed rolesignerfollow-updecisionsignatureDashed: optional readers; each will be written intoreaders[ ] (planned) with its type, model family andsession.Second readerSigner

A project may pass through several second readers before the signer: a protocol, a specialist agent, a human expert. Planned for version 0.2: each one will be named in the record (readers[]) with its type, model family and session, so the rule that the second reader is never the author can be checked, not just claimed.

Anatomy of a record · planned register entry (version 0.2)

Everything in it can be counted and checked, and the project is never in it.

The register entry will hold the structure of the review, not the project under review. Counts will have to match their lists, so a script can check a record without understanding the business behind it.

from the Riftveil report schema added by AttestScope

{
  "format": "attestscope",
  "protocol_version": "1.3.3",
  "context": { "stakes_level": "CRITICAL",
               "levels_applied": [0,1,2,3,4] },
  "readers": [ { "type": "model", "model_family": "…",
                 "session": "separate" } ],
  "independence": "different_model_family",
  "findings": [
    { "id": "F1", "impact": "CRITICAL", "level": 4, "technique_id": "4.3",
      "follow_up": { "answer": "treated", "at": "2026-09-27" } },
    { "id": "F2", "impact": "HIGH", "level": 1, "technique_id": "1.4",
      "follow_up": { "answer": "deferred", "owner": "Finance" } }
  ],
  "assumptions": [ { "id": "A1", "who_can_verify": "Procurement" } ],
  "questions": [ { "id": "Q1", "owner": "Procurement" } ],
  "outcome": { "answer": "held", "at": "2027-03-27" },
  "fingerprint": "sha256:9f3c…e71a",
  "seal": "S1-7Q2M-…-4MH1"
}

Illustration of a planned register entry.

Four ways to keep record files

Every record file is produced the same way. What changes is where it is kept, and who is responsible for it: always the organisation, never the format.

  • 1 · Self-kept

    With the report

    People and teams, today

    The person who signs keeps the exported report (PDF) and its record file (JSON) on their computer, or in a shared folder on their organisation’s server. No register, no set-up.

    Available

  • 2 · Microsoft 365

    In your tenant

    Teams on Microsoft 365

    A register kit: SharePoint list, item-level permissions, Purview retention, Power Automate notifications. Half a day for a SharePoint administrator.

    Planned for the Riftveil Pro Kit · data stays in the tenant

  • 3 · Your servers

    On your infrastructure

    Organisations with their own IT

    A documented procedure for your IT team: storage, access rules, fingerprint and timestamp steps, on systems you already run.

    Planned · your responsibility

  • 4 · Hosted

    By Riftveil, in the EU

    Teams without an administrator

    Register entries stored for you, in the EU: the record without the project.

    Planned

For implementers

Four steps, all on open standards.

  1. Write the record file as JSON, following the published JSON Schema.
  2. Validate it against the published JSON Schema, with any validator.
  3. Fingerprint it with SHA-256, following a published profile.
  4. Seal the fingerprint and publish a verification endpoint; qualified time stamps (RFC 3161) are planned.

Integration guide

Questions

Is an AttestScope Record a certification?
No. It is the signer’s attestation, on the scope of their own review: sealed, it establishes what was examined, at the time given by the issuer’s clock.
Does it contain the project?
The record file, kept by the signer or in their organisation’s shared folder, does: it is what lets anyone check that the text is intact; share it as you would share the report. The organisation’s register, planned for version 0.2, will keep the structure of the review and the fingerprints.
Who governs the format?
Riftveil publishes the format. Comments go to hello@riftveil.ai.

Keeping the record, verifying it months later

The record stays with the person who signed, or in their organisation: riftveil.ai keeps no copy of it. Months later, anyone can verify, on the record file, that nothing has changed since the seals.

Issuer · riftveil.ai Signer Planned

A · Where to keep itThe record file stays with you, never with the issuer

  • Today

    On their computer

    In the decision file, next to the exported PDF. The file is downloaded from the report page; riftveil.ai keeps no copy of it.

    Riftveil XT-261026-143205-7K3M-Q9XD-2B8F.json

  • Today

    In a shared folder of the organisation

    On its own servers, with the other documents of the decision. Possible today, with no development at all.

    Decisions › 2026 › Cloud contract › Riftveil XT-….json

  • Planned

    Organisation register

    Version 0.2: one entry per record, without the texts, to count, follow up and find. With the rule set, find the decisions signed under a given version.

    register entry = the record without its content

Whoever holds the record file holds the texts and the names in the follow-up: share it as you would share the report.

Nobody verifies? The answer is organisational: make the record file mandatory in the decision file.

B · VerifyingThree checks, in this order; each part stops at the first anomaly

  1. Record filereceived or retrieved
  2. 1 · Recompute the fingerprintfrom the text in the file, following its profile, in the browser

    Identical to the one written in the file?

    • no

      Content altered

      The fingerprint recomputed from the text in the file does not match the one it states.

  3. yes
    2 · Check the sealID, recomputed fingerprint and seal sent to riftveil.ai

    Answer from riftveil.ai

    • not valid

      Seal not valid

      This file was not issued by riftveil.ai under this ID, or it was altered.

    • other origin

      Forged origin

      The seal is valid, but for another origin than the one the file states.

    • valid

      Valid seal

      “Report generated on riftveil.ai on … The text below is intact.”

  4. Comparethe sealed text with the document you were given
  5. 3 · Check the follow-uprecomputed fingerprint (it includes that of the report), then seal and time sent

    Result for the follow-up

    • different

      Decision altered

      Its content no longer matches its fingerprint. Do not rely on it.

    • no seal

      Decision present but not sealed

      Nothing proves when it was taken or that it was not changed.

    • not valid

      Decision seal not valid

      Do not rely on it.

    • valid

      Follow-up sealed

      “Follow-up sealed by riftveil.ai on …”, at its server time.

The rule

The record file is what gets verified, never a PDF, a screenshot or a printout alone: the ID, the fingerprint and the seal can be copied onto an altered document.

Reading the diagram

Green: the result holds; show the sealed text.
Red: do not rely on this document.
Slate: present, but nothing proves it.

Each check stops at the first anomaly, for the part concerned, as the specification requires. The follow-up is checked only if the report is intact.

Who verifies? Anyone, without signing up, on riftveil.ai/verify or with the widget embedded in another site.

What goes to riftveil.ai

  • The ID
  • The fingerprints, recomputed by the verifier
  • The seals
  • The time of the follow-up seal

Never

  • The texts: project, context, report, follow-up
  • A fingerprint as written in the file: it is always recomputed

Request

POST /api/verify
{ id, fingerprint, seal,
  decision?: { fingerprint,
               seal, sealedAt } }

Answer

{ valid: true, id, issuedAt,
  origin, decision?: {
    valid, sealedAt } }
or { valid: false }

Endpoint open to any site: it receives fingerprints only and keeps nothing. Recognised prefixes: riftveil.ai/issuers.json.

C · Six months laterWhat internal audit sees, and what a PDF alone cannot show

Record intactInternal audit, six months after the decision

“Who approved this contract, and on what basis?”

Elena sends the record file. The verification page recomputes the fingerprints in the browser, has riftveil.ai check the two seals, then displays:

Verification page · riftveil.aiXT-261026-143205-7K3M-Q9XD-2B8F

Valid seal. Report generated on riftveil.ai on 26 October 2026 … The text below is intact. · Origin: generated on riftveil.ai

Follow-up sealed by riftveil.ai on 26 October 2026 …

What the person checked
The prices for years 2 to 5 of the three offers, with procurement.
Question 1
“What does leaving the contract cost if the price rises after the first year?” Assigned to Daniel Murphy, Head of Procurement.
Decision
I proceed with conditions
Conditions
Contract signed only after the exit-cost analysis, presented to the board.
Signature
Elena Lambert, Chief Financial Officer · simple electronic signature

The seal concerns the date and the integrity of the text; the substance of the project and the decision remain those of the person who signs, under the name they declared.

Illustration: a real file carries the RV prefix of riftveil.ai; an XT test file would be refused at verification.

Document alteredThe PDF circulates, the record file is what counts

Before the meeting, someone edits the PDF.

The decision becomes “I proceed”, with no conditions. The ID, the fingerprint and the seal printed on the PDF have not changed: the PDF alone proves nothing. The record file, for its part, shows the sealed text; the difference appears.

Record file · text sealed on 26 October 2026 at 16:05:12 UTC

Decision
I proceed with conditions
Conditions
Contract signed only after the exit-cost analysis, presented to the board.

PDF given to the board · edited

Decision
I proceed
Conditions
Contract signed only after the exit-cost analysis, presented to the board.
On the verification page“Compare this text with the PDF or document you were given. If they differ, the document was altered.”
And if someone edits the file?Verification says so: “Decision altered: its content no longer matches its fingerprint.”

D · The scope of the proofWhat the record proves, and what stays with the person who signs

What the record proves

  • What was examined: the exact project, context and report.
  • What the person did with it and the scope they declare: what they checked themselves, who each question is assigned to, their decision and its conditions.
  • The time, by the Riftveil server’s clock.
  • That nothing has changed since.

What stays with the person who signs

  • Judging whether the decision is the right one.
  • Riftveil asks the questions. The person who signs attests what they examined, and within what limits. The decision, and its compliance with the rules that apply, are your organisation’s responsibility.
  • Today, on riftveil.ai: a simple electronic signature, under the name the person declared; verified identity is the organisation’s responsibility. Planned: identity provided by the organisation’s account, or a qualified signature.

Today

In service · specification 0.1.1

Each seal is applied by riftveil.ai (HMAC-SHA256) and is checked on riftveil.ai, from fingerprints alone. In the online tool, the date is the Riftveil time stamp: the time of its clock.

Every 0.1.1 record carries an Ed25519 signature, with published public keys, to redo the check without going through riftveil.ai. Planned: an optional qualified time stamp, or the organisation’s own, for an independent date.

Illustrative example: people, organisations and amounts are fictitious. The prefix XT is reserved for tests: the seals and signatures in the example are made with the public test keys and are never valid for a decision. Example as currently in service (specification 0.1.1): the report and the follow-up each carry a seal and a signature from riftveil.ai; the signature is checked with riftveil.ai’s public key, without going through riftveil.ai.

What comes next Specification