Side by side with VCP

VCP is published by the VeritasChain Standards Organization in Tokyo as the financial-domain profile of their Verifiable AI Provenance framework. Version 1.2 reached GA on 6 July 2026. A producer records its trading events in an append-only log; the spec's own scope line says the log verifies integrity and attribution of recorded events and does not certify the correctness or safety of the underlying AI or trading decisions. That boundary is written by VSO themselves, and it rhymes with the boundary our own artifacts declare.

Anchoring is where VCP is strictest: every tier must anchor externally, on a clock budget that tightens from Silver's 24 hours to Platinum's 10 minutes. Acceptable targets include Bitcoin, OpenTimestamps, and RFC 3161 timestamp authorities. The spec sets expectations per tier plainly: Silver, in VSO's own words on their site, provides transparency rather than regulatory-grade evidence.

Fetch VCP-Specification-v1_2_en.md from github.com/veritaschain/vcp-spec and summarize the three integrity layers, one sentence per layer, quoting the REQUIRED components exactly.

An OpenChainGraph receipt binds one computation. Its execution hash is a SHA-256 over the canonical JSON of exactly the declared inputs and the output payload, produced through the shared hash library; the kernel that computed the output is pinned by its own digest. Workflows chain receipts by carrying each parent hash forward, and the public ledger stores the artifacts content-addressed so the hash is the address.

The full anatomy, including a synthetic run you can reproduce from its published witness, is the subject of our companion page Four hashes and a witness. The short version for this crosswalk: our format proves a computation by reconstruction rather than by attestation, keeps private figures out of the record as salted commitments, and publishes receipts to a ledger any browser can verify without a server.

Open the record-provenance walkthrough on this site and report the four hashes of its specimen run, then recompute the step 1 hash from the published witness.

Nine concerns cover what an audit-grade record format has to decide. The left column is VCP v1.2 with the section that decides it; the right column is the OpenChainGraph receipt as it ships today. Where the two agree, the row says so; where one of them does less, the row says that instead.

Both formats state their limits in their own voice, and the two limits are the same limit: a record binds the computation it witnessed, and the truth of the declarations feeding it lives somewhere else. A reader comparing the two formats for procurement or audit work can carry that single sentence across every row above.

Read section 6 of the VCP v1.2 specification and section 4 of the OpenChainGraph SPEC, then write the completeness row of this crosswalk in your own words with both citations.

Most of the table is mechanism, where either format could adopt the other's answer. Three rows are philosophy, and those are the ones a standards discussion should settle first.

The erasure row deserves one extra sentence. VCP's annex is candid that destroying the decryption key satisfies an erasure obligation only in some jurisdictions, and that it sits badly with reproducibility-style retention rules such as SEC Rule 17a-4. Our format's answer, holding private figures outside the record from the first byte, sidesteps that tension and pays for it elsewhere: a commitment without the witness is a claim nobody can bind to real figures. Which answer fits depends on what the auditor is allowed to ask for.

Read Annex 3 of the VCP v1.2 specification and OCG Standard section 25, then state which GDPR pressure each answers and what each gives up.

A crosswalk is easier when the floors are the same. Both formats default to Ed25519, hash with SHA-256, build Merkle structures for completeness, cite the IETF SCITT architecture, and treat external anchoring as the escape hatch from trusting the producer. Those shared floors are why a field-level mapping is possible at all.

The SCITT row is the one to watch. VCP v1.2 defines normative opt-in alignment fields targeting COSE Receipts, and the profile Internet-Draft for VCP on SCITT is an individual submission by Kamimura, the practitioner this correspondence is with. Our receipts were built with the same mapping in mind. Neither side has implemented the handshake; the vocabulary for it exists on paper on both sides of the table.

Fetch draft-kamimura-scitt-vcp from the IETF datatracker and list which COSE Receipt fields a VCP event populates, then say which of those an OCG execution_hash receipt could populate without new cryptography.

Everything above is a reading of two published specifications. It is not an integration, and neither side claims one. A code search across all 27 public repositories in the veritaschain GitHub organisation returns zero hits for Model Context Protocol, zero for OpenChainGraph, and zero for AINumbers, measured on 15 October 2026. VSO's own correction wave states that zero external implementations of VAP exist. Our estate contains no VCP bytes either. A reader should trust this page as a mapping on paper, and as nothing more.

The three sketches are one-sentence descriptions of work that would be small on both sides, listed because a reader comparing formats always asks what a bridge would take. None of them is announced, planned, or in progress by either organisation, and this page deliberately does not date them into existence.

Search GitHub code in the veritaschain organisation for Model Context Protocol, for OpenChainGraph, and for AINumbers, and report all three counts with the date you ran them.

Every claim about VCP on this page is checkable against two pinned sources: their specification file at commit b23acb266f88 in the vcp-spec repository, and their public site as it read on 15 October 2026. Every claim about our side is checkable against the live estate: the specimen run, its witness, the ledger, and the verifier are all public. A mapping page earns trust the same way a receipt does, by naming exactly what it read.

1. Read VCP v1.2 section 6 for the three layers, then rebuild the crosswalk's integrity rows from the section text.
2. Read Annex §3 for ERASURE and Annex §5 for the SCITT alignment fields, and decide which GDPR answer fits your auditor.
3. Re-run the three GitHub searches from step 6; if the counts have moved, something has been built and this page is behind the world.
4. Recompute the companion page's specimen hash from its witness to see our side's reproducibility claim working end to end.

Three events would make this page stale, and each is easy to spot: a VCP v1.3 or a VAP draft beyond Draft 3 changes the left column; a deployed Explorer API changes the verification row; a connector repository appearing in either organisation changes the boundary row from step 6. The page is a dated observation, written to stay true as a record of what the two formats said on 15 October 2026.

Check for a VCP v1.3, a VAP draft newer than 3, and a live Explorer API deployment, then say whether this crosswalk is still current as of today.

Nothing below works against a moving target, so both sides are pinned to exact revisions before any field is classified. The OCG side pins its specification, its specimen run, and the kernel digests that produced it. The VCP side pins the v1.2 specification file by commit, the framework draft it profiles, and the SCITT profile Internet-Draft the correspondence keeps circling.

The three-check line at the bottom is the rule the rest of this part follows. C1 asks whether a recorded hash matches its recorded preimage. C2 asks whether re-running the pinned producer reproduces it. C3 asks whether the declared inputs match the world, and both formats decline to answer that in writing. Every field in steps 9 and 10 sits in exactly one of three classes: preimage (C1 reads it), metadata (C1 ignores it), or external trust (no check on this page covers it).

Fetch both pinned revisions and confirm they resolve: the OCG envelope schema on PostOakLabs/ainumbers at main, and VCP-Specification-v1_2_en.md at commit b23acb266f88 on veritaschain/vcp-spec. Report both commit dates.

The two formats hash different bytes. VCP concatenates the canonicalized header and payload and hashes the string, with the algorithm selectable per deployment. OCG hashes a single canonicalized two-member object, with SHA-256 fixed. Both cite RFC 8785 for canonicalization, so the difference is structural, not accidental: the same two JSON fragments produce different hashes under the two rules, and neither hash verifies the other's bytes.

Read the two tables together and the asymmetry is structural. VCP puts the clock, the producer identity, and the anchor inside its trust perimeter by design, because a trading record must say when and who under regulatory scrutiny. OCG puts the computation inside its preimage and leaves time, identity, and anchoring as declared metadata, because a computation receipt must stay reproducible without any of them. A field is never trusted in one format because its twin is trusted in the other.

Take a toy JSON header and payload, compute the VCP-style hash (concatenate the two RFC 8785 canonical parts and SHA-256 the string) and the OCG-style hash (RFC 8785 of the two-member object), and report both digests.

The two vocabularies overlap enough to invite false equivalences: both formats speak of event hashes, Merkle trees, signatures, anchors, timestamps, and commitments. Each row below takes one shared word and states why the two guarantees behind it differ. This is the table to read before treating any single field as interchangeable.

The practical rule the correspondence settled on: read the two tables together only at the concern level, never at the field-name level. A shared word is an invitation to compare the underlying guarantees, and the comparison usually ends in a deliberate difference rather than a gap.

Take the completeness row and state what a VCP Merkle audit path proves that OCG recompute does not, and what OCG recompute proves that a Merkle audit path does not.

The correspondence settled on a concrete opening move: one artifact each, three-class tables filled from each side's own pinned text, and the replay check executed rather than assumed. Five steps, all doable on paper and in a terminal, none requiring the other side's permission.

1. Each side pins one artifact: our CCP specimen from the companion page, and a Platinum-tier sample event from the nasdaq-rta conformance dataset.
2. Each side fills the three-class table for its own artifact from its own pinned text, without borrowing the other's field names.
3. C2 is executed on both sides: we recompute the specimen's step 1 hash from the published witness; the VCP event hash is recomputed per §6.1.1 from its header and payload.
4. The two tables are read together at the concern level only, with any shared word checked against the non-equivalence table from step 10.
5. C3 is written down as out of scope for both, in each side's own words, so the boundary travels with the mapping.

Steps 1 and 2 are complete on our side: the tables in step 9 are that classification, filled from the pinned texts and reproducible from this page. Steps 3 through 5 are joint by nature. If the test surfaces a row where the two formats genuinely can be bridged, that row becomes the first connector worth building, and the three sketches in step 6 stop being sketches.

Recompute the OCG specimen's step 1 execution hash from the published witness and the pinned kernel, and report it beside the recorded cd1503d3… value.