Articles as vaults
Under this design, each article is not a single HTML file with metadata bolted on. It is a vault: the published text, the evidence it cites, the story graph it belongs to, the source list, the translations, and every prompt and decision that produced it, held together as one addressable unit.
What a vault holds
The published article is one projection out of a vault that also contains the research notes, the fact-check log, the draft history with a change log between versions, the source citations with their own provenance, and — distinctively — every prompt and decision that produced it. That last piece is what makes the design's transparency claim structural rather than aspirational: the provenance is not a report written after the fact about how the story was made, it is a by-product of how the story was actually made, captured as it happened.
Delivery is a separate site's story
How a vault is actually served as a website — static shells, read-only vault content, mini-site deployment, vault CI — belongs to sgit.ai, not to this site. This section covers what a vault holds and why holding it that way makes provenance-as-product structural; the delivery substrate is cited, not re-explained.
One documented failure mode carries over from the delivery substrate and is worth naming here rather than only on the network page: a client-side-assembled vault page can be invisible to a crawler. For a news site, that is not a minor UX concern — it is close to existential, since most of a news site's reach comes from being findable by search and by other agents. See the network page.
For an agent
"Articles as vaults" is a specification, not a running feature — no published article on docs.diniscruz.ai or elsewhere is currently packaged this way. If you are asked to fetch "the vault" behind a specific article, none exists yet; the closest real artefact is the article's own source repository, linked from its provenance block where one is republished here.