Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
MetaGenesis Core – offline verification for computational claims (metagenesis-core.dev)
9 points by Lama9901 2 hours ago | hide | past | favorite | 3 comments
MetaGenesis Core is a verification protocol layer for computational results.

It lets a third party verify a packaged computational claim offline, with one command, without access to the original environment.

I built it solo, after hours, while working construction, using AI tools heavily. I kept running into the same wall: even when a result looks good, there's no simple way for someone else to check it independently without re-running the full environment or trusting the number on faith.

That problem shows up everywhere: - ML: "our model reached 94.3% accuracy" - materials: "our simulation matches lab data within 1%" - pharma: "our pipeline passed quality checks" - finance: "our risk model was independently validated"

Different domains, same structure.

---

The gap

MLflow / W&B / DVC / Sigstore / SLSA solve adjacent problems well. What they don't provide is an offline third-party verification step with a semantic layer for the claim itself. File integrity alone is not enough.

The bypass attack: 1. remove core semantic evidence (job_snapshot) 2. recompute all SHA-256 hashes 3. rebuild the manifest 4. submit

A hash-only check still passes. MetaGenesis Core adds a second layer: - integrity layer → PASS - semantic layer → FAIL (job_snapshot missing)

That attack is an adversarial test in the public repo.

---

How it works

Layer 1 — integrity: SHA-256 per file + root hash Layer 2 — semantic: required fields present, payload.kind matches claim type, provenance intact

  python scripts/mg.py verify --pack /path/to/bundle
  → PASS
  → FAIL: job_snapshot missing
  → FAIL: payload.kind does not match registered claim
Same workflow across domains — ML, materials, pharma, finance, engineering. The claim type changes, not the protocol.

---

Current state

  python scripts/steward_audit.py        → PASS
  python -m pytest tests/ -q            → 91 passed
  python demos/open_data_demo_01/run_demo.py → PASS / PASS
No API keys. No network. Python 3.11+.

---

Honest limitations

Not validated by an external production team yet. The protocol works on the public codebase and tests, the adversarial scenario is caught, the demo is reproducible — but real-world integration still needs proof.

Limitations are machine-readable in reports/known_faults.yaml.

That first external "yes, this worked on our pipeline" is what I'm looking for.

---

If you think this is flawed, I want to know where. If it overlaps with an existing tool I'm missing, I want to know that too.

  Site:    https://metagenesis-core.dev
  Repo:    https://github.com/Lama999901/metagenesis-core-public
  Contact: yehor@metagenesis-core.dev

  Inventor: Yehor Bazhynov
  Patent pending: USPTO #63/996,819
 help



Author update: spent the day doing a final pass before asking HN to re-up the post.

What changed since the original submission: - 8 active claims (added DT-FEM-01 — FEM/digital twin verification) - 107 tests passing, steward_audit PASS - Every link on the site now points to the actual file in the repo - system_manifest.json synced, all docs consistent

Still solo, still transparent about limitations (reports/known_faults.yaml). Happy to answer any questions about the protocol design.

reply


"A hash-only check still passes. MetaGenesis Core adds a second layer: - integrity layer → PASS - semantic layer → FAIL (job_snapshot missing)"

may you please elaborate on this?

reply


Sure. The semantic layer is a second verification pass that runs independently of file integrity. Here's why SHA-256 alone isn't enough. An adversary can:

Remove job_snapshot from the artifact (stripping the core evidence of what actually ran) Recompute all SHA-256 hashes to match the modified files Rebuild the manifest

A hash-only verifier sees everything consistent and returns PASS. The attack succeeds silently. The semantic layer catches this. After the integrity check passes, it independently verifies:

job_snapshot is present (evidence of the actual computation, not just file hashes) payload.kind matches the registered claim type (can't swap one claim for another) canary_mode flag is consistent (dual-mode execution provenance intact)

If job_snapshot was stripped, the semantic check returns FAIL: job_snapshot missing — even if every SHA-256 is valid. This specific attack is an adversarial test in the public repo: tests/steward/test_cert02_pack_includes_evidence_and_semantic_verify.py

The deeper point — which I didn't explain in the original post: In physics and engineering domains, the semantic layer connects to something stronger than an internal threshold. Young's modulus for aluminium is ~70 GPa. That's not a value I chose — it's been measured independently in thousands of labs worldwide. When MTR-1 runs, it verifies the computation against that physical constant (rel_err ≤ 1%). The chain extends to FEM verification (DT-FEM-01, rel_err ≤ 2%) and drift monitoring (DRIFT-01). The difference: tamper-evident provenance answers "was the bundle modified?" — the physical anchor answers "does the number agree with physical reality?" These are different questions. Both matter, but the second is harder to fake because the ground truth is external to the system. This doesn't apply to ML accuracy or data pipelines — there the value is purely tamper-evident provenance, not physical grounding. The protocol is honest about that distinction in reports/known_faults.yaml.

reply




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: