Data Governance

Provenance tracking, validation trust levels, release artifacts, and content integrity — the trust chain from physics constants to simulation outputs.

What is data governance?

Ananke models physics with numbers drawn from the real world — bone fracture thresholds, fire heat flux, plague mortality rates. Data governance is the system that tracks where those numbers came from, how well they've been validated, and how trustworthy each API surface is as the library evolves.

Three layers work together:

  • Physics provenance — every physics constant in src/ is traceable to a peer-reviewed dataset or engineering standard. Validation reports in docs/validation-*.md document each source and the expected range the simulation must hit.
  • API stabilitySTABLE_API.md classifies every exported symbol as Tier 1 (stable, semver-guarded), Tier 2 (experimental, may change without major bump), or Tier 3 (planned, not yet implemented). Hosts can decide what risk level they accept.
  • Release integrity — each npm publish is signed via GitHub Actions OIDC provenance attestation. The CHANGELOG.md records every change. Content packs carry provenance.sha256 checksums for tamper detection.

Use the provenance checklist below to assess readiness of any release before integrating it into a production pipeline.

What this uses

STABLE_API.md CHANGELOG.md tools/validation.ts scripts/generate-site-manifest.js docs/emergent-validation-report.md docs/versioning.md

Data governance in Ananke spans three layers: physics constants (validated against real-world datasets), API stability (covered by semantic versioning and the Tier 1/2/3 contract), and content integrity (provenance and checksums in content packs and validation reports).

Release artifacts

STABLE_API.mdstability contractpresent
CHANGELOG.mdversion historypresent
package.json versionsemverpresent
site-manifest.jsonbuild metadatagenerated at build
docs/emergent-validation-report.mdvalidation reportpresent
TypeDoc API (dist/api/)generated docsgenerated at build
golden replay fixturesregression guardpartial — see test/
npm provenancesupply chainvia GitHub Actions

Provenance checklist

  • Physics constants validated against peer-reviewed datasets (see docs/validation-*.md)
  • Calibration scenarios pass expected ranges (run npm run run:validation)
  • Stable API contract documented in STABLE_API.md with Tier 1/2/3 annotations
  • CHANGELOG updated for every version bump
  • Golden replay fixtures committed and CI-verified for core scenarios
  • Content pack SHA-256 checksums in provenance.sha256 field
  • npm publish includes provenance attestation (GitHub Actions OIDC)
  • Emergent validation report regenerated for current release
4 / 8

Trust dashboards

🧪
Validation Dashboard
Conformance tests, seed matrix, and API boundary checks from last CI run
Performance Dashboard
Tick timing, throughput benchmarks, and memory usage across entity counts
🎯
Arena Batch Runner
Multi-trial outcome distribution — balance and statistical expectation testing
📋
Conformance Checklist
Host integration compliance — determinism, fixed-point, command dispatch

Package provenance — current release

static preview
package@its-not-rocket-science/ananke
npm registrynpmjs.com ↗
licenceMIT
build pipeline.github/workflows/deploy-pages.yml
test coveragestatements 97%, branches 88%, functions 96% (see CI)

Try this

  1. Verify a physics constant: grep for it in docs/validation-*.md — each constant has a corresponding validation report with real-world source data.
  2. Check the stable API contract: open STABLE_API.md — Tier 1 surfaces are safe to depend on without guards.
  3. Run npm run test:coverage to verify coverage thresholds locally before a release.
  4. Validate content pack integrity: check provenance.sha256 in a pack manifest against a recomputed hash of the pack's canonical JSON.
  5. For golden fixture regression testing, add a replay to test/fixtures/ and import it in a determinism test.