TALTangerine Lattice · v2.0-α
Trust mechanism

Audit & verification

Every analysis run produces an immutable audit record with a deterministic runHash. Anyone can re-run the same inputs against the same engine version and the result must be bit-identical. That's what makes TAL different from probabilistic analytics — it's reproducible.

Audit record anatomy

runIdDeterministic identifier — hash of (engineVersion, configHash, datasetFingerprint, treeFingerprints).
tenantIdScoping anchor. Every record in every TAL table belongs to one tenant.
engineVersionSemver. Engines with different versions can produce different hashes only by documented changes.
configHashsha256 of the full RunConfig (thresholds + feature flags).
datasetFingerprintsha256 over canonical record sequence — independent of upload order.
treeFingerprintssha256 of each hierarchy tree used in the run.
runHashFinal hash combining inputs + structured outputs. The verification anchor.
startedAt / completedAtISO timestamps. Metadata only — excluded from runHash so wall-clock drift never breaks determinism.
durationMsPerformance signal. Not part of the hash.
findingCountQuick health check. Real consumers count findings via the findings endpoint.

How verification works

# Verify any past run produces the same output
$ tal verify run-7c1a3e2f8b4d9001

  re-running engine 2.0.0-alpha.1
    dataset fingerprint    OK     4a8f3c91d7b2e60a3f...
    tree fingerprints      OK     1
    config hash            OK     9d2b81e6c4af3072e8...
    finding count          OK     38
    runHash match          OK     ✓

verification passed

The same machinery powers POST /api/v2/runs/:id/verify. Use it before publishing any result that will be acted on.

Beyond the hash — full traceback

runHash proves the result hasn't been tampered with. Traceback proves the result is justified. Every finding has a provenance DAG: which records fed which aggregates, which aggregates fed which finding, which thresholds were applied. Click any finding in the runs page to see it.