AEGIS

Not legal advice. AEGIS is a documentation tool. It proves that evidence exists, is current, was approved and is consistent. It doesn't decide whether an obligation applies, or whether evidence is legally enough.

Build an evidence pack from the DITA source

Pick a reader. AEGIS reads the Gemma evidence set in dita-corpus: requirement topics, the relationship table that links each one to its evidence, each topic's prolog dates and keys, and the pull request that approved each file. Four plain checks decide whether the pack can be released. Then act in a private sandbox: propose a link with Gemini, record a decision, plant a leak, and download the pack with its manifest and SHA-256 hashes. Nothing you do here changes the source; your sandbox is deleted after 7 days.

1 Pick a reader

loading

2 Requirements and evidence

Each requirement with the topics that answer it: topic, coverage value from the trace, revised date, the commit that last changed it, and the code owner who approved that commit's pull request. A requirement with no evidence is a named gap. For a gap, ask Gemini to propose a link (titles and short descriptions only), then approve or reject it as the information architect.

RequirementEvidence in this pack

3 Findings and decisions

Every finding the four checks raised. As the compliance lead you can record a decision with a reason for a gap, a stale topic, a missing approval or a conflicting statement: the pack then ships with that record. A leak can't take a decision. It has to be fixed in the source.

4 Try the checks

Leak test

Put an authority-only key reference into an evidence topic, in your sandbox only. Then pick the public or downstream reader and watch check_consistency block the release.

Model update

Move the Gemma 4 version date, as a new release would. check_currency flags topics revised before it that state values as text; a topic that holds only key references stays current if its keys changed in an approved commit.

5 Build and download

The zip holds the DITA-OT 4.4 output (HTML5 and PDF) built in CI with this reader's DITAVAL profile, manifest.json, report.html, coverage.csv and SHA256SUMS. A sandbox pack is hashed but never sealed.

6 The real flow

  1. RequestAn issue names the reader, opened in the AEGIS repository.
  2. Checks and buildA workflow runs the four checks and builds the pack with DITA-OT.
  3. ReportThe report is posted on the issue for review.
  4. ReleaseThe compliance lead (here, Siddharth) comments /release.
  5. SealThe pack is hashed, stored in Cloud Storage with a retention policy, and registered.