LIGHT HOPE ecosystem · internal infrastructure · vault.lighthope.ai
Media assets you can trace, not just use.
MediaAssetVault is the LIGHT HOPE ecosystem's vault of audited media asset cards — images, knowledge-derived media, and their provenance — organized by domain and served through one flat JSON index. Every card carries an audit signature tracing it back to its source project and content hash. No RPC, no handshake, no service to keep alive: consumers read files.
A developer-facing infrastructure layer, not a consumer product. This page is the public
documentation surface for project m591.
Figures from the vault's own machine-checkable audit scripts, last self-audit 2026-05-26. Nothing on this page is a marketing estimate.
How it works
Filesystem-async: publish, don't call.
The vault follows a publish-over-handshake doctrine. Upstream knowledge projects publish; adapters ingest read-only; consumers pull from an index. No project ever waits on another, and no project ever writes into another's tree.
Siblings publish
Upstream projects — oncology knowledge graphs, longevity hallmarks, cortical-target datasets, conference material, editorial articles — publish their audited outputs to their own repositories. The vault never asks them to change anything.
Adapters ingest, read-only
A small adapter (~150–250 lines, roughly 15 minutes to write a new one) parses each source
and maps it to the vault's card schema. Adapters read sibling trees; they never write them —
a rule continuously verified by cross_ref_check.py.
Cards get signed & graded
Every card is written with a composite audit signature —
m<sibling>:<record_id>:<sha256> — and an auto-derived consumption grade.
A quality gate (G7) blocks bootstrap-only cards from production use.
Consumers read one index
Downstream projects query a single flat file, assets/_index.json, and pull the cards
they need. First consumer contract (PIPE-X-001, to the m495 skills registry) is published with a
working end-to-end example.
sibling-published knowledge · each on its own disk m506 ──┐ finance articles m516 ──┤ longevity hallmarks · claims · biomarkers m518 ──┼──[read-only]──► m591 adapters ──► assets/<domain>/cards/*.yaml m590 ──┤ oncology + knowledge graph │ m622 ──┘ conference material ├──► assets/_index.json ▼ any ecosystem consumer reads index · pulls cards no handshake · no RPC
The whole integration surface. If you can read a file, you can consume the vault.
What you actually get
Provenance is the product.
Plenty of systems store media. The vault's job is narrower and harder: guarantee that every asset you pull can answer where did you come from, who audited you, and are you safe to ship?
Audit signatures on every card
Each card records a composite signature — source project, record id, and SHA-256 of the canonical content. Change the source and the drift detector catches it; delete it and the dangling-ref check catches that. Current run: 430/430 clean.
Consumption grades, machine-enforced
Cards are graded production, indirect-audit, or bootstrap-only.
The grade is derived, not declared — and the G7 gate in the self-audit script blocks ungraded or
bootstrap material from production paths automatically.
Seven domains, honestly filled
Cancer, longevity, neuro, finance, math, sports, education. Five are genuinely populated today; two hold seed cards awaiting upstream publishers — and the vault says so, per-domain, in its own metadata rather than rounding up.
Licensing tracked per asset
Only three license classes are admitted: public-domain/CC0, purchased, or ecosystem-generated. Photographic cards store their license and attribution fields individually. Unclear provenance is rejected at the wall, not cleaned up later.
Self-audit with an external check
The vault issues its own audit certificate on every run, mirrored to a pickup outbox where the ecosystem's independent auditor (m562) may counter-sign or supersede it at any time. Self-certification is a floor, not a ceiling.
New source in ~15 minutes
The sibling-adapter pattern is deliberately boring: recon the published files, map to the card schema, sign, grade, emit YAML, register in two scripts. Five adapters exist; the sixth follows the same seven steps in the runbook.
# assets/cancer/cards/m590ingest_flaura_trial.yaml — illustrative card, # field names are real schema; values abridged for display asset_id: cancer-m590-0042 domain: cancer title: "FLAURA trial — osimertinib in EGFR-mutated NSCLC" media_type: knowledge_card audit_signature: m590:onc_batch_0042:9f2ab3…e871 consumption_grade: indirect-audit license: ecosystem-generated pii_status: cleared disclaimer: required # medical domain → citation + disclaimer wall source_project: m590
One card, fully answerable.
A card is a small YAML document whose every claim is checkable: the signature resolves to a real record in a real sibling repository, the hash matches the canonical content, and the grade tells a consumer exactly what it may be used for.
| Grade | Meaning | Count |
|---|---|---|
| production | Real binary asset with its own SHA-256 (e.g. licensed photography) | 353 |
| indirect-audit | Production-safe via a sibling project's audit certificate | 430 |
| bootstrap-only | Seed material — the G7 gate blocks it from production | 5 |
| total | Matches the vault-wide self-audit count | 788 |
Who it's for
Built for builders inside the ecosystem.
The vault is infrastructure. Its users are other projects and the engineers who run them.
Content & skill pipelines
Teams producing briefs, videos, or educational series pull pre-audited, correctly licensed cards instead of re-vetting sources per project. The published PIPE-X-001 contract ships with a runnable consumer example covering four real scenarios.
Knowledge publishers
Domain projects — oncology, longevity, neuroscience, finance — get distribution without integration work. Publish audited outputs in your own tree; an adapter does the rest, read-only, with your audit chain preserved in every card's signature.
Auditors & operators
Every state the vault claims is reproducible from three scripts: self-audit, cross-reference check, and sibling resync. Certificates land in a pickup outbox the independent auditor can counter-sign — or override — at any time.
Boundaries · what the vault is not
A vault that knows its walls.
The project charter freezes explicit "not-do" walls. They are why the vault stays trustworthy — and they are published, so you can hold it to them.
Not a production factory
It stores and indexes audited assets; it does not generate media. Generation belongs to dedicated engine projects.
Not the auditor
The vault records and verifies audit signatures; the auditing authority is external and may supersede any self-issued certificate.
Not a knowledge graph
Knowledge extraction and compilation happen upstream. The vault consumes published results — it never re-derives them.
Never writes to siblings
Cross-project access is read-only by frozen rule, verified continuously — currently 430/430 clean.
Copyright wall at the door
Public-domain/CC0, purchased, or ecosystem-generated only. Media of unclear origin is refused, not laundered.
Medical content stays contextual
Cancer, neuro, and longevity cards require citations and disclaimers. Vault content supports education and research pipelines — it is not medical advice.
Access
How to consume the vault.
MediaAssetVault is internal LIGHT HOPE infrastructure — there is no retail price list, and we won't invent one here. Access falls into three honest lanes:
Ecosystem projects
Included
- Read assets/_index.json directly — no ceremony
- Published pull contracts (PIPE-X series), no acknowledgment required
- Runnable consumer example to copy from
New upstream sources
~15 min
- Publish audited output in your own repository
- A seven-step adapter recipe in the maintenance runbook
- Your audit chain preserved in every derived card
External interest
Contact
- The sibling-adapter pattern is a reusable template
- Schema and doctrine documents available on request
- No public API commitment at this stage — we'd rather say so than promise one
Honesty note: the vault has no paid tiers, no SLA, and no uptime pledge — it is a filesystem-published internal layer, and this page claims nothing beyond what its audit scripts verify.