V3RUM v0.1 preview specification.

1. Purpose and threat model

A verum is a portable, cryptographically-verifiable artifact that binds a moment to a person, a place, a time, and a content hash, witnessed by a constellation of independent sources.

The threat model is fabrication. The protection is correlation. Any individual witness in a verum can be spoofed, replayed, or compromised. Forging the agreement between independent witnesses requires compromising multiple unrelated systems simultaneously and synthesizing physically-consistent state across all of them. A verifier's confidence in a verum SHOULD scale with the diversity and independence of its witness constellation, not with any single witness's strength.

2. The verum artifact

A verum MUST be a JSON document with the following top-level fields:

{
  "spec": "v3rum",
  "specVersion": "0.1.0-preview" | "1.0.0" | ...,
  "issuedAt": "<ISO 8601 UTC timestamp>",
  "cargo": {
    "algorithm": "SHA-256",
    "hash": "<hex-encoded hash>",
    "length": <cargo length in bytes>
  },
  "witnesses": [ <witness object>, ... ],
  "identityClaim": <string | null>,
  "score": <integer>,
  "tier": "sketch" | "brief" | "record" | "archive",
  "verumHash": "<hex-encoded SHA-256 of the canonicalized verum>"
}

Each witness MUST contain:

{
  "kind": "<witness type identifier>",
  "category": "<category from §3>",
  "weight": <integer>,
  "role": "structural" | "substitutable" | "decorative",
  ... <kind-specific fields>
}

Verums SHOULD be canonicalized (RFC 8785 JSON Canonicalization Scheme) before hashing. The verumHash field MUST be omitted from the input to its own computation.

3. Witness categories

The v0.1 preview defines the following categories. v1.0 will expand and formalize this list.

4. Weighting and scoring

The v0.1 preview uses these illustrative weights. v1.0 will calibrate these against real-world fabrication costs.

• WebAuthn assertion (hardware-backed): 15 pts
• Apple Watch / Wear OS hardware attestation: 10 pts
• Phone Face ID / Touch ID with platform attestation: 10 pts
• Hardware security key (FIDO2): 12 pts
• OpenTimestamps Bitcoin anchor: 12 pts
• RFC 3161 TSA token (per independent TSA): 8 pts
• Ethereum block hash inclusion: 6 pts
• Bitcoin block hash (without OTS): 6 pts
• drand / NIST beacon round: 5 pts each
• Watch GPS independent fix: 5 pts
• UWB ranging (Apple U1/U2): 5 pts
• WiFi BSSID environmental fingerprint: 4 pts
• BLE proximity between owned devices: 4 pts
• Major-exchange stock prices, multi-stock: 4 pts
• FX spot rates, multi-pair: 3 pts
• Phone GPS: 3 pts
• HRV pattern: 3 pts
• News headline hashes: 2 pts each, capped at 8
• Cell tower triangulation: 2 pts
• Barometric altitude: 2 pts
• Heart rate during signing: 2 pts
• Wrist motion micro-trace: 2 pts
• Phone accelerometer hold signature: 2 pts
• AI-acknowledgment QR challenge completed: 6 pts
• Per-page initial chain (proof-of-attention): 4 pts per page
• Multi-AI-envoy attestation: 3 pts each, capped at 9
• LinkedIn challenge-response link: 3 pts
• DNS-verified domain ownership: 3 pts
• Verified email challenge: 1 pt

Diminishing returns

Within a category, witnesses MUST follow a diminishing-returns rule: the first witness in a category contributes its full weight, the second contributes 60%, the third 30%, and additional witnesses in the same category contribute zero. This prevents score-inflation by stacking trivially-similar witnesses.

Independence requirements

Witnesses claimed as independent within a category MUST be from distinct providers. Two stock prices from the same exchange count as one witness. Two TSA tokens from the same authority count as one witness. The verifier MAY reject witness sets that fail independence checks.

5. Tiers

Tiers are advisory labels for human readers. The score is the underlying truth.

• sub-threshold: < 20 pts. Insufficient for any meaningful claim.
• sketch: 20–49 pts. Casual replies, low-stakes attribution.
• brief: 50–99 pts. Standard substantive disclosures.
• record: 100–249 pts. Foundational disclosures, defensive prior art.
• archive: 250+ pts. Maximum-rigor seal.

Verifiers MAY require a minimum tier for a given use case. The seal carries its own tier; the verifier sees the score breakdown and decides if it suffices.

6. Substitutability

The spec is designed to outlive its components. The witness category registry (maintained at /.well-known/v3rum.json) lists currently-qualifying witnesses for each category. Witnesses join and leave the registry as the world changes.

A verum MUST be verifiable as long as some qualifying witness exists for each of its categories at verification time. When a witness source becomes unreachable, the verum's verifiable-now score MAY be lower than its at-signing score. The verifier reports both.

Spec versions MUST be backward-compatible for verification. A verifier implementing v2.0 MUST verify v1.0 verums correctly. Forward compatibility is not required.

7. Verification

To verify a verum, a verifier MUST:

1. Confirm the spec version is supported.
2. Recompute the cargo hash from the original cargo (if available) and confirm it matches.
3. For each witness, fetch the public witness value from its original source (or a successor in the same category) and confirm the recorded value matches.
4. Verify all cryptographic signatures using the public keys recorded in the witness objects.
5. Recompute the score using current weights, applying diminishing-returns and independence rules.
6. Recompute the verum hash and confirm it matches the recorded value.

A verifier MAY accept a verum where some witnesses are unreachable, recording the reduced verifiable-now score. A verifier MUST NOT accept a verum where the cargo hash, the verum hash, or any cryptographic signature fails verification.

8. Decorative witnesses

Decorative witnesses contribute nothing to fabrication-resistance. They contribute to the seal's character.

A high heart rate during signing is not evidence; it is testimony. Include them if they mean something to you. Strangers will read them later and form opinions about who you were when you wrote this. That's the point.

Decorative witnesses MUST be marked "role": "decorative" and SHOULD contribute zero or one point each. Verifiers MUST display structural and decorative score contributions separately. A 200-point seal that's 180 decorative reads as performative; a 200-point seal that's 180 structural reads as fortified. The verifier sees the difference at a glance.

Examples: altitude tag, notable-location tag, concurrent-event tag (eclipse, sports event, launch), heart-rate-elevated flag, signed-during-thunderstorm flag, border-crossing flag, signed-at-3:33-AM flag.

9. Revocation and disputes

A verum cannot be revoked — once issued and witnessed, the artifact exists and can be verified by anyone. What CAN happen is the issuer publishing a subsequent verum that disclaims the prior one. The disclaimer is itself a verum, with its own witnesses and timestamp.

Disputes about the meaning of a verum (did the signer intend this content? is the cargo what was actually agreed?) are out of scope for the spec. Those are questions for whatever framework consumes the verum (a contract, a TSL8 cargo, a court proceeding).

10. Soft spots

What's honestly not solved yet:

• WebAuthn portability. Passkeys aren't fully portable across ecosystems. A verum signed with an Apple passkey verifies fine, but the signer can't easily move that key to Android.
• Score inflation via low-quality witnesses. Mitigated by diminishing-returns and independence rules; not eliminated.
• Decorative-tier status games. Mitigated by separate display of structural vs. decorative score; not eliminated.
• Health-data commitment risk. Even hashing health data on a public artifact creates a permanent target if the underlying data leaks elsewhere. Regulatory status uncertain.
• Witness source mortality. Substitutability handles this in principle. In practice, simultaneous failure of all qualifying witnesses in a category degrades that category until the registry is updated.
• Legal status of a verum. Untested in court. Probably stronger than current notarization. Probably weaker than a fully-litigated patent. Empirical, not theoretical.
• Time-zone and clock-skew handling. Specifics for cross-time-zone verification edge cases are deferred to v1.0.
• Privacy of identity claims. Identity claims are currently public string fields. v1.0 may introduce ZK-proof identity bindings.