TwinCert.

AI evidence preparation, not AI rubber-stamping.

TwinCert uses AI to extract, normalize, and cross-check evidence before a certificate is signed. The customer root still signs the final record; AI suggestions are reviewable artifacts in the audit trail.

What a TwinCert record contains.

A TwinCert record is the signed evidence package for one part. It binds together everything the customer chooses to make verifiable: composition, conformance claims, custody, telemetry references. The customer decides what to include; the schema dictates how it is structured so a regulator's tooling can ingest it.

Open schema, no surprises.

The TwinCert schema is JSON-LD, CC0-licensed. You can use it in your own tooling without paying us a penny and without crediting us. We publish the schema, the validation suite, the migration guides between schema versions, and the test corpus.

• twincert-attestation-v2.schema.json — the current schema is delivered in signed customer packages when the file is available; the public API page documents the field model.
• v1 to v2 migration guide — published; backwards-compatible parsing for v1 records is committed to in the schema's stability statement.
• Test corpus — approximately 200 anonymised real-world TwinCert records covering aerospace, medical, automotive, spare-parts, and research use cases.
• Validation suite — reference validator in Python, Go, Rust; same code our SDK uses, same code the verifier-CLI uses.

Regulatory mapping.

The reason TwinCert exists is to make regulator-facing evidence cheap to produce. We carry first-class mappings for the regulatory frameworks our customers face.

The mappings are published documents, not opaque tooling. Your auditor can read them and decide whether to accept them; they have, in our experience so far.

Example record.

Anonymised TwinCert for a flight-qualified aerospace bracket. Extract.

{
  "@context":           "https://3dcipher.com/schemas/twincert-v2",
  "id":                 "twc-2026-05-19-aa70",
  "customer_id":        "cust-warwick-aero-2024",
  "identity": {
    "part_class":        "WA-BRK-001",
    "serial":            "WA-BRK-001-041873",
    "manufactured_at":    "2026-05-19T08:42:09Z",
    "site":              "warwick-bay-a",
    "printer":           "BAY-A4-PRINTER-07"
  },
  "composition": {
    "material":          "Ti-6Al-4V (Grade 23)",
    "feedstock_lot":     "LPW-T64-2026-031",
    "feedstock_coc":     "sha256:9d3a...ff60"
  },
  "as_built": {
    "bundle_ref":        "bd-2026-05-19T08:42:09Z-7a3f",
    "bundle_sha256":     "4b9c7a3f81e2 ... d871a07"
  },
  "conformance": [
    {
      "type":             "dimensional",
      "spec":             "WA-BRK-001-DIM-r3",
      "inspection_ref":   "insp-2026-05-19-114",
      "result":           "pass"
    },
    {
      "type":             "mechanical",
      "spec":             "WA-BRK-001-MECH-r2",
      "inspection_ref":   "insp-2026-05-19-115",
      "result":           "pass"
    }
  ],
  "provenance": {
    "cad_revision":      "WA-BRK-001-r12",
    "meshguard_payload": "mg-warwick-aero-WA-BRK-001-r12"
  },
  "regulatory": {
    "framework":         "AS9100D + EU CRA",
    "profile":           "flight-qualified-am-2026"
  },
  "retention": {
    "policy":            "25y-aerospace",
    "earliest_destroy":  "2051-05-19"
  },
  "signed_at":          "2026-05-19T08:43:14.022Z",
  "signature":          "...customer-root-Ed25519..."
}

Custody chain.

TwinCert records support countersigned custody transfer events. Each transfer is a signed event referencing the TwinCert; both parties sign. The chain is verifiable end-to-end against the customer root.

A typical custody chain for an aerospace part:

twc-2026-05-19-aa70  // the TwinCert record (signed at manufacture)
  ⇒ xfer-2026-05-21-001 (manufacture site -> OEM warehouse) // 2 signatures
  ⇒ xfer-2026-05-24-088 (OEM warehouse -> tier-1 assembly) // 2 signatures
  ⇒ xfer-2026-06-03-027 (tier-1 assembly -> final assembly) // 2 signatures
  ⇒ xfer-2026-06-10-104 (final assembly -> flight-qual archive) // 2 signatures

Each event signs the previous event's identifier, producing a chain that cannot be reordered without invalidating signatures.

Audit-package generation.

Auditors do not want to query an API; they want a bundle of documents and a verifier that does not require an internet connection. The audit-package generator (RB-44) produces exactly that.

For a sampled set of part serials, the generator emits:

• The TwinCert record for each sampled part.
• The Vault3D as-built bundle referenced by each TwinCert.
• Inspection records referenced by the TwinCert's conformance section.
• The customer manifest at the time of manufacture, with Merkle proofs that the bundles are committed.
• The ceremony root certificate chain and the verifier-CLI binary.
• A regulatory mapping document for the audit's regulatory framework.
• A human-readable cover summary.

The package is a signed tarball, approximately 8–40 MB depending on sample size. Auditors verify it by running 3dc verify audit-package <tarball>; the verifier-CLI is single-binary and offline.

Integration shape.

TwinCert records are typically issued shortly after manufacture, by the customer's quality system. The integration point is small.

# pseudo-code, Python SDK

from threedc.twincert import Builder
from threedc.vault3d import bundle_by_id

bundle = bundle_by_id("bd-2026-05-19T08:42:09Z-7a3f")

twc = (Builder(customer="cust-warwick-aero-2024")
    .identity(part_class="WA-BRK-001", serial="041873", site="warwick-bay-a")
    .composition(material="Ti-6Al-4V", feedstock_lot="LPW-T64-2026-031")
    .as_built(bundle)
    .conformance_from(inspection_records=["insp-2026-05-19-114", "insp-2026-05-19-115"])
    .provenance(meshguard_payload="mg-warwick-aero-WA-BRK-001-r12")
    .regulatory("AS9100D + EU CRA", profile="flight-qualified-am-2026")
    .retention("25y-aerospace")
    .sign())

twc.publish_to_manifest()

What TwinCert does not do.

TwinCert is the evidence layer. It is not the inspection system, not the metrology lab, not the quality management system. It references those; it does not replace them.

• It does not verify that the part actually conforms. It records the customer's signed claim that it does, and references the inspection record.
• It does not anonymise sensitive supplier information. The customer chooses what to include; redaction profiles are available but are a customer choice.
• It does not enforce retention. The retention field is metadata; the customer's archive system enforces it.
• It does not negotiate with regulators on your behalf. We provide mappings; the regulator-facing conversation is yours.