CoParent Circle

How to verify our records

Most co-parenting apps assert that their records are "tamper-proof" and stop there. This page is the specification: exactly how our records are sealed, and how a skeptical attorney, judge, or expert can check them without taking our word for anything.

What secures a record

1. An append-only hash chain

Every recorded event (message, calendar change, expense, exchange, document, deviation) writes one row to the circle's evidence chain. Each row stores the SHA-256 of its own payload plus a chain hash computed from the row before it.

chain_hash = SHA256( prev_chain_hash || payload_hash || created_at_epoch )

Because each hash includes the one before it, editing or deleting a single row invalidates every row after it. Recomputation names the exact row where the chain first diverges, and distinguishes an edited row from a removed one.

2. Daily anchors, timestamped by an outside authority

Once a day the chain head hash is written to a permanent anchor record and submitted to an independent RFC 3161 timestamp authority. The authority returns a signed token certifying that the hash existed at that moment.

TimeStampReq { version 1, messageImprint { sha256, chain_head_hash }, certReq TRUE }

The token is signed by the authority's key, not ours. It proves the record existed by that date even if you assume our servers and our clock cannot be trusted.

3. Ed25519 signatures on every export

Each finalized court report is signed with an Ed25519 key. The signature covers the report's canonical payload: record id, document SHA-256, report type, reporting period, page count, jurisdiction, and generation time.

signature = Ed25519-Sign( private_key, canonical_payload )   ·   key id = ev-<first 16 hex of SHA256(public key)>

Public keys are published at /api/public/evidence-keys as raw 32-byte base64 Ed25519 keys with their fingerprints. Private keys never leave the server and are never exported, logged, or displayed.

4. The document's own fingerprint

The SHA-256 of the exported PDF is stored with the record and printed on the report's certificate page, alongside the Bates range and page count.

SHA256( report.pdf ) == stored sha256

Anyone holding the file can recompute this in one command, or drop the file on our verify page — the hash is computed in the browser and only the fingerprint is sent.

Four checks, in the order a court would run them

  1. 1

    Check the file is the one that was filed

    shasum -a 256 report.pdf

    Compare the output to the SHA-256 printed on the report's certificate page, or drop the file at /verify.

  2. 2

    Check the record exists and was not withdrawn

    open https://thecoparentcircle.com/verify

    Enter the record id printed on the report. The page reports the reporting period, page count, jurisdiction, signer initials, and whether the record has been revoked.

  3. 3

    Check the signature against a published key

    curl https://thecoparentcircle.com/api/public/evidence-keys

    Fetch the public key matching the report's key id, then verify the Ed25519 signature over the canonical payload with any standard crypto library.

  4. 4

    Check the outside timestamp

    openssl ts -verify -in anchor.tsr -queryfile anchor.tsq -CAfile tsa-ca.pem

    The anchor token is issued and signed by an independent timestamp authority, so this step does not rely on us at all.

What we deliberately do not claim

  • No certifying body has "approved" our records. No such body exists for co-parenting apps. Anyone who says otherwise is describing marketing, not a standard.
  • Cryptography proves a record has not changed since it was written. It cannot prove that what a parent typed was true. Admissibility is always the court's decision.
  • We can show that a record existed by a certified date and has not been altered since. That is the claim, and every part of it is checkable above.
Verify a report now Admissibility and the rules of evidence