AEGIS v0.1 · documentation evidence for AI governance · 2026

AEGIS: Build regulator-ready evidence from the DITA source
and prove each item is covered, current and approved

Design document · Siddharth Rao · October 2026 Client: Google AI model and Cloud TPU documentation

Working version. Try the evidence sandbox on the Gemma 4 source, or ask the evidence corpus. The simulator in §6 is the scripted design demo.

Disclaimer. This is a portfolio design document. Google has not engaged, sponsored or endorsed this work. The sample content is adapted from the Gemma and Cloud TPU documentation, which Google publishes under the Creative Commons Attribution 4.0 licence¹. The adapted versions are modified from the originals. Topics marked for the authority audience are written for this design and are not Google documentation. Sample runs, hours and costs are modelled, not measured. This document describes a documentation tool. It is not legal advice. Stakeholders are job roles, not real people. The two readers in §3 are fictional.

readers the AI Act names
for model information

of turnover: top fine for
incomplete information

10 yrs

minimum retention of
each documentation version

Abstract

Documentation has had three main readers: developers, architects and support engineers. The EU AI Act adds readers who use documentation as evidence. A provider of a general-purpose AI model must keep its technical documentation current, give it to the AI Office and national authorities on request, and give downstream providers the information they need⁶. Inside the company, a compliance lead must show the same evidence before anyone asks. These readers don't ask how to use a model. They ask for proof: for this version, from this source, approved by this person.

The technical writing team already holds that proof. A DITA source in Git has one source of truth, a version history, named reviewers and audience profiling. AEGIS (AI Evidence and Governance Integrity System) is an agent that turns that source into an evidence pack. Each requirement is a DITA topic. A relationship table links each requirement to the topics that answer it. Four deterministic checks prove that each link is covered, current, approved and consistent. Gemini proposes a link only where a requirement has none. A compliance lead releases the pack, and AEGIS seals it in a Cloud Storage bucket with a locked retention policy.

The first AEGIS design was a governance platform for a fictional asset manager, with five agents and an EU AI Act risk classifier³¹. This version keeps its evidence bundle and its human escalation. It drops risk classification, because deciding whether an obligation applies is a legal decision, not a documentation decision.

evidence packEU AI ActAnnex XINIST AI RMFDITAreltableDITAVALaudience profilingprovenanceGeminiAgent Development KitBucket Lock

§1 Client Brief

The client is Google's AI model documentation, together with the Cloud TPU documentation that describes the hardware the models train on. Google signed the EU general-purpose AI Code of Practice in July 2025¹²¹⁴. The sample content is the public Gemma 4 model card², the Gemma 3 model card³ and the Gemma overview page⁴.

It is a good test for four reasons. A model card is the public document closest to what the regulation asks for, so its sections map to most items in Annex XI. It has real gaps and drift to find (§2.1). It is published under CC BY 4.0, so it can be adapted¹. And it raises a real applicability question: Gemma 4 is released under Apache 2.0², and Article 53(2) exempts some open-source models from parts of the documentation duty⁶. AEGIS doesn't answer that question. It records who answered it, and when.

Term	Meaning in this document
Evidence pack	The files AEGIS builds for one request: the profiled documentation, a manifest and a coverage report.
Requirement topic	A DITA reference topic that states one requirement in plain words, with its legal source and a key, for example `aia.xi-2d`.
Evidence topic	A normal documentation topic, such as a model card section, that answers a requirement.
Relationship table	The DITA `<reltable>`. Each row links topics in its cells¹⁷. Here, a requirement topic and its evidence topics.
DITAVAL profile	A file that keeps or removes content by attribute value at build time¹⁸. AEGIS uses `@audience` with three values: public, downstream and authority.
Prolog	The metadata block at the top of a DITA topic: author, critical dates and other metadata.
Model Documentation Form	The form in the Transparency chapter of the Code of Practice for the information that Article 53 needs¹²¹³.
Downstream provider	A company that builds its own AI system on top of the model.
Retention lock	A Cloud Storage retention policy that, once locked, can't be removed or shortened²⁰.

Figure 1

System context: as-is state

existing sourcegap

The one place that holds versions, dates and reviewers, the DITA source in Git, is not part of the evidence path. The evidence is rebuilt by copying, so it starts to drift the day it is sent.

1.1 Documentation has new readers

The usual readers use documentation to do a job. The new readers use it to check a claim. They read the same content, but they need three things a reader doing a job rarely asks for: the version, the source and the person who approved it.

Figure 2

One source, two kinds of reader

reads to do a jobreads to check a claimthe source both read

The content is the same on both sides. The right side also needs the metadata that a DITA source and Git already keep.

Reader	Asks	Needs from the documentation	Time limit
Developer, architect	How do I use it?	Accurate task and reference topics	None
Support engineer	Why did it fail?	One answer for each value	None
Compliance lead at Google	Can we prove it?	Evidence for each requirement, with version and approver	Before release
AI Office, national authority	Send the latest documentation	Annex XI technical documentation⁷	On request, in the time set¹³
Downstream provider	Can I meet my own obligations?	Annex XII information⁸	14 days in the Code of Practice¹³
Public	What was it trained on?	Public summary of training content, Article 53(1)(d)⁶	At release

The writing team is the right owner for these readers because evidence needs the same things good documentation needs: one source, a known version, a named reviewer and the right content for each audience. A structured DITA source already has all of them. The table shows where each governance need is already met.

Governance need	What the writing team already has	DITA or Git feature
One source for every answer	Single-sourced topics in Git	Maps, topics, `conref`
Trace each requirement to its evidence	Links that writers maintain	`<reltable>`¹⁷
Give each reader only their part	Audience profiling	`@audience` and DITAVAL¹⁸
Version and date of every statement	Review dates and history	`<critdates>`, commits
A named, accountable reviewer	Pull request approval	Protected branches, code owners²⁸³⁰
One value everywhere	Keys, as in AlignR³³	`<keydef>`, `keyref`
A controlled vocabulary	Allowed attribute values	Subject scheme map

1.2 Regulation in brief

Two frameworks set the scope. The EU AI Act (Regulation (EU) 2024/1689) is binding law⁵. The Digital Omnibus on AI, Regulation (EU) 2026/1744, moved the high-risk dates later¹⁰. The obligations for general-purpose AI models did not move. They have applied since 2 August 2025, and the AI Office can enforce them with fines from 2 August 2026¹¹. The NIST AI Risk Management Framework is voluntary. NIST is revising it, and has not given a release date for the new version¹⁵.

Figure 3

EU AI Act dates after the Digital Omnibus

general-purpose AI model duties: in scope for AEGIShigh-risk systems: outside this MVPgeneral

Dates from the Digital Omnibus text and its summary¹⁰¹¹. Code of Practice date from the Commission¹². The purple duties already apply. The high-risk dates are the ones the omnibus moved.

Article	What it asks for	Applies from	Documentation job
53(1)(a) and Annex XI	Technical documentation, kept current, for the AI Office and national authorities on request⁶⁷	2 Aug 2025. Older models: 2 Aug 2027¹¹	Authority pack
53(1)(b) and Annex XII	Information for providers who build the model into their own systems⁸	2 Aug 2025	Downstream pack
53(1)(d)	A public summary of the training content, on the AI Office template⁶	2 Aug 2025	Public page
50	Tell people when they deal with an AI system or generated content	2 Aug 2026¹¹	Disclosure text
11 and Annex IV	Technical documentation for high-risk AI systems	2 Dec 2027 for Annex III¹⁰	Not in this MVP
101	Fines up to 3% of worldwide turnover or €15 million, including for incorrect, incomplete or misleading information⁹	2 Aug 2026¹¹	Accuracy of what is sent

The NIST framework has four functions. GOVERN is cross-cutting. MAP sets the context for risks, MEASURE assesses them and MANAGE acts on them¹⁶. It doesn't set a document format, but several subcategories ask for something to be documented. Figure 4 shows the ones that AEGIS can produce evidence for (§5.9).

Figure 4

NIST AI RMF functions and the subcategories that ask for documentation

AEGIS produces evidencenot covered

Subcategory text paraphrased from NIST AI 100-1¹⁶. NIST also publishes a Generative AI Profile, NIST AI 600-1 (July 2024)¹⁵. AEGIS treats NIST subcategories as one more requirement set in the same map.

Scope

AEGIS proves that evidence exists, is current, was approved and is consistent. It doesn't decide whether an obligation applies, and it doesn't judge whether the evidence is legally enough. Those are decisions for the compliance lead and legal counsel. AEGIS records each decision with a name and a date, like any other item.

§2 Problem Statement

When the AI Office or a downstream provider asks for model documentation, someone has to put a pack together. Today that pack is built by hand from published pages, spreadsheets and email. It is slow, and it can't show which version of each statement was sent or who approved it. Article 101 allows fines for information that is incorrect, incomplete or misleading⁹, so a pack that can't prove its own accuracy is a cost, not only an effort.

2.1 The content exists, but not as evidence

Figure 5 checks the public Gemma pages against the Annex XI items that apply to every general-purpose AI model provider⁷. It is the check a compliance lead can do without asking anyone, and the starting point for every pack built by hand.

Figure 5

Annex XI, Section 1, against the public Gemma model cards

Annex XI item	Gemma 4 model card	Gemma 3 model card
1(a) Intended tasks	StatedIntended usage section	StatedIntended usage section
1(b) Acceptable use	LinkedGemma Terms of Use⁴	LinkedGemma Terms of Use
1(c) Release date, distribution	Not statedOnly a "last updated" date	Not statedOnly a "last updated" date
1(d) Architecture, parameters	StatedDense and MoE; 30.7B; 25.2B with 3.8B active	PartlySize names, no parameter counts
1(e) Input and output	Two statementsVideo in the introduction, not in the modality table	StatedText and images in, text out
1(f) Licence	Two statementsApache 2.0 on the card; overview also links the Gemma Terms⁴	StatedGemma Terms of Use
2(a) Integration means	PartlyBest practices section	PartlySoftware section
2(b) Design and training method	PartlyArchitecture, no rationale	PartlyArchitecture, no rationale
2(c) Training data	StatedData types, languages, preprocessing	StatedTokens per size, preprocessing
2(d) Training compute	Not statedNo hardware or compute	PartlyHardware: TPUv4p, TPUv5p, TPUv5e
2(e) Energy use	Not statedNo energy figure	Not statedOne sentence on sustainability

stated or linkedpartly, or stated twice in different waysnot stated

Pages as published: Gemma 4, last updated 30 July 2026²; Gemma 3, last updated 14 August 2025³. This does not show that Google lacks the information. Annex XI documentation goes to the AI Office on request and isn't public. It shows how much of a pack built from public pages must still be chased by hand: 7 of 11 items for Gemma 4.

A real example

The Gemma 4 model card describes language support twice. The introduction says the model supports over 140 languages. The capabilities section says "Out-of-the-box support for 35+ languages, pre-trained on 140+ languages"². Both can be true, because they measure different things. A pack built by copying must pick one sentence, from one page, on one date, and it records none of those choices. The same page also carries a notice that the documentation is deprecated and has moved to gemma.ai. In a DITA source the two numbers are two keys with two labels, and the move is a commit with a date.

The cost is mostly people's time. Figure 6 models one authority pack for one model, built by hand and built by AEGIS. Most of the manual time goes to chasing owners and confirming approvals, which is exactly what Git already records.

Figure 6

People hours for one Annex XI pack (modelled)

finding and copyingchasing and confirmingAEGIS machine timehuman review and release

Modelled for this design, not measured. Assumes 11 Annex XI items, 14 evidence topics and 4 owners, with the coverage of Figure 5. Each new model version and each request repeats the manual bar. With AEGIS the review time falls as the relationship table fills in.

2.2 Why the current options fail

There are four common ways to answer an evidence request. Each one moves the evidence away from the source, or loses the link to the version and the approver.

Option	What it does	What it misses	Result
Copy into the form and track in a sheet	The compliance lead pastes published text into the Model Documentation Form.	No link to the source version. No proof of approval. Out of date at the next release.	Manual
Governance, risk and compliance platform	Stores policies, controls and attestations.	Holds a second copy of the content, with its own licence. Writers don't work in it, so it drifts.	Second copy
A chat assistant fills the form	Drafts answers from the model card.	Answers have no source, no version and no approver. Nothing can be shown as evidence.	Unverifiable
Wiki page approval (first AEGIS)	Records sign-off as a page approval³¹.	The approval sits on a page, apart from the source that the published docs are built from.	Partial
AEGIS v0.1	Builds the pack from the DITA source. Links each item to a commit, a date and an approver. Checks decide.	Can't decide if an obligation applies. Can't write a missing fact.	Evidence from source

Figure 7

Options by distance from the source and strength of evidence

A qualitative placement, not a measurement. Evidence gets weaker each time the content is copied away from the place where versions and approvals are kept.

Problem statement

Regulators, downstream providers and compliance leads now read model documentation as evidence. They need each statement with its version, its source and its approver. Today the evidence is rebuilt by hand from published pages, so it is slow to build, starts to drift when it is sent, and can't prove its own accuracy. The DITA source in Git already holds the versions, dates and reviews, but nothing turns it into evidence.

§3 User Profiles

Five roles at Google decide whether AEGIS is useful. Two readers outside the writing team use what it produces.

Documentation lead, GemmaSponsor

GoalAnswer evidence requests without taking writers off launches.

Measured byPeople hours per pack. Packs answered in time.

TodayEach request becomes a small manual project.

ConcernA compliance tool that the writing team must run forever.

SuccessA pack in one working day, with no text copied by hand.

Technical writer, Gemma model docsMain user

GoalWrite each fact once and know where it is used as evidence.

Measured byGap notes per release. Hours spent on each pack.

TodayAnswers compliance questions by email and finds old text in forms.

ConcernBecoming a copy service for the compliance team.

SuccessEvidence links live in the map, next to the content she maintains.

Information architectStructure owner

GoalKeep requirement topics, links and audience values under control.

Measured byRequirements with no link. Profile errors at build time.

TodayRequirements are not modelled in the source at all.

ConcernAn agent that adds links nobody reviewed.

SuccessEvery link change is a pull request that she approves.

Research engineer, Gemma trainingContributor

GoalGive each training fact once, to one place.

Measured byQuestions per pack.

TodaySeveral teams ask him the same compute and energy questions.

ConcernConfidential numbers reaching public output.

SuccessFacts live in authority-only topics, and the public build never contains them.

AI governance and compliance leadNew consumer

GoalAnswer the AI Office or a downstream provider with evidence she can defend.

Measured byRequests answered in time. Items with a named approver.

TodayFills in the Model Documentation Form by hand from published pages.

ConcernSending incomplete or incorrect information, which Article 101 can fine⁹.

SuccessEach item traced to a commit, a date and a person, in a pack that she releases herself.

Readers

Lena BrandtReader

RoleTechnical assessor at the European AI Office (fictional).

GoalCheck that the latest documentation covers Annex XI.

TodayReceives documents with no version or date on each statement.

SuccessEvery item names its source, its model version and its approver.

Priya NairReader

RoleML platform lead at a European company that builds a support assistant on Gemma 4 (fictional).

GoalMeet her own obligations as a downstream provider.

TodayReads the public card and guesses which statement is current.

SuccessAn Annex XII pack within the 14 days that the Code of Practice sets¹³.

Evidence needs clear ownership, so the roles map to a RACI matrix. Each activity has one role that approves it (A). AEGIS appears in no column: it does work, but it never approves.

Activity	Docs lead	Writer	IA	Engineer	Compliance
Write requirement topics	I	C	R	I	A
Write evidence topics	A	R	C	C	I
Supply training facts	I	C	I	A	I
Approve requirement links	I	C	A	I	C
Decide if an obligation applies	I	I	I	I	A
Release a pack	C	I	I	I	A

A: approvesR: does the workC: consultedI: informed

§4 User Stories

Each story has acceptance criteria that a tool or check in §5 tests.

US-1 · Documentation lead

As the documentation lead, I want each pack built from the source with its hours and model cost logged, so that I can show the time it saves.

Accepted when: seal_pack writes one register row per pack with build time, model calls and cost; review time comes from pull request timestamps.

US-2 · Technical writer

As the Gemma writer, I want each requirement linked to my topics in the map, so that I answer compliance questions by keeping the source current.

Accepted when: check_coverage reads only the relationship table; a topic older than the current model version shows as stale in check_currency.

US-3 · Information architect

As the information architect, I want every new requirement link to arrive as a pull request, so that no link reaches a pack without my review.

Accepted when: propose_mapping writes only to a branch; the evidence map has her as code owner; the agent's account can't approve.

US-4 · Research engineer

As the research engineer, I want confidential training facts to reach only the authority pack, so that they never appear in public output.

Accepted when: topics with audience="authority" are absent from the public and downstream builds; check_consistency fails the build if an authority-only key resolves in either.

US-5 · Compliance lead

As the compliance lead, I want each item in a pack traced to a commit, a date and an approver, so that what I send is complete and correct.

Accepted when: check_approval passes for every item; the manifest lists commit, revised date and approver for each requirement; seal_pack refuses a pack she hasn't released.

US-6 · Lena, reader

As an assessor, I want the pack to show the model version and date of each statement, so that I can check it against the model on the market.

Accepted when: each manifest item carries model-version and a revised date, and check_currency passes.

US-7 · Priya, reader

As a downstream provider, I want one pack with only the Annex XII items, so that I can meet my own obligations quickly.

Accepted when: the downstream build passes check_coverage for all 11 Annex XII requirements, and the pack is ready within one working day.

Figure 8

Stories mapped to the agent tools

deterministic toolcheck that decides pass or failmodel call

The model appears in two stories, and in both a person reviews its output. No acceptance test depends on the model.

§5 Proposed Design

AEGIS v0.1 is an agent built with Agent Development Kit (ADK), Google's open-source agent framework²². Plain Python tools, called through function calling²⁴, read the source, run the checks and build the pack. Gemini 3.8 Flash (gemini-3.8-flash)²³ has one job. When a requirement has no evidence linked to it, Gemini proposes a link by filling a JSON Schema with structured output²⁵. The checks decide pass or fail. The agent can't approve a link, release a pack or change a topic.

5.1 How it works

A compliance lead opens an issue for a request: who asked, which requirement set and which audience. AEGIS reads three inputs that already exist: the requirement map, the DITA source and the Git history. It runs four checks, asks Gemini only about requirements with no evidence, builds the pack with DITA-OT and opens a review. When the compliance lead releases the pack, AEGIS seals it. Figure 9 is the same context as Figure 1, with AEGIS added.

Figure 9

System context: AEGIS added

existing source or storedeterministic tool or outputcheck that decidesmodel, and its proposalsgap path

The DITA source is now on the evidence path. The model sits beside the checks, not in front of them. Its only output is a proposed link, and a person approves it before it counts. When the link pull request merges, AEGIS runs again.

5.2 Governance in DITA

AEGIS adds no new format. It uses four DITA 1.3 features that the team already knows. DITA 1.3 is the current OASIS standard, and DITA-OT 4.4 only previews DITA 2.0¹⁹, so the design targets 1.3. Requirements become topics, links become a relationship table, evidence topics carry their dates in the prolog, and DITAVAL profiles decide which reader gets which topics.

Figure 10

Four DITA layers between a requirement and a pack

requirementtraceevidenceaudience profile

The evidence map is a separate DITA map that only AEGIS builds, so the relationship table never adds links to the published model card. Topic dates are sample values.

Figure 11

The four layers in source

1 · Requirement topic, owned by the information architect

<reference id="aia-xi-2d">
  <title>Annex XI 2(d): computational resources used for training</title>
  <shortdesc>Describe the compute used to train the model, such as floating point operations and training time.</shortdesc>
  <prolog><metadata>
    <othermeta name="legal-source" content="Regulation (EU) 2024/1689, Annex XI, Section 1, point 2(d)"/>
    <othermeta name="required-for" content="authority"/>
  </metadata></prolog>
</reference>

2 · Relationship table in the evidence map

<reltable title="Gemma 4 · Annex XI">
  <relheader><relcolspec type="reference"/><relcolspec type="reference"/></relheader>  <!-- requirement | evidence -->
  <relrow>
    <relcell><topicref keyref="aia.xi-1d"/></relcell>
    <relcell><topicref href="gemma4/models-overview.dita"/></relcell>
  </relrow>
  <relrow>
    <relcell><topicref keyref="aia.xi-2d"/></relcell>
    <relcell><topicref href="gemma4/training-infrastructure.dita"/></relcell>  <!-- added by PR #457 -->
  </relrow>
</reltable>

3 · Evidence topic: audience and dates in the prolog

<reference id="gemma4-training-infrastructure" audience="authority">
  <title>Gemma 4 training infrastructure</title>
  <prolog>
    <author type="contributor">Gemma research engineering</author>
    <critdates><created date="2026-04-02"/><revised modified="2026-07-30"/></critdates>
    <metadata><othermeta name="model-version" content="gemma-4"/></metadata>
  </prolog>
  <refbody><properties>
    <property><proptype>Training hardware</proptype><propvalue><ph keyref="gemma4-train-hardware"/></propvalue></property>
    <!-- more rows: training time, compute estimate -->
  </properties></refbody>
</reference>

4 · DITAVAL profile for the downstream pack

<val>
  <prop att="audience" val="public"     action="include"/>
  <prop att="audience" val="downstream" action="include"/>
  <prop att="audience" val="authority"  action="exclude"/>
</val>

KeysRequirement keys and value keys work the same way. A value changes in one place, and every pack picks it up.

AudienceThe authority topic exists once. The downstream and public profiles exclude it at build time.

ApprovalThe prolog names who should own a topic. Git records who approved it. AEGIS trusts Git for approval.

Sample source written for this design. The training infrastructure topic and its key are placeholders, because Annex XI documentation isn't public. Element and attribute names follow DITA 1.3¹⁷¹⁸.

DITA or Git feature	Governance job	Checked by
`<reltable>` in the evidence map	Trace each requirement to its evidence	`check_coverage`
`<critdates>`, `model-version`	Show which version and which date each statement belongs to	`check_currency`
Pull request reviews, code owners	Show who approved each statement	`check_approval`
Keys and `keyref`	One value in every pack	`check_consistency`
`@audience` and DITAVAL	Give each reader only their part	`check_consistency` (leak test)
Subject scheme map	Allow only known audience values and requirement keys	The DITA-OT build fails on an unknown value

5.3 Four checks

The checks are plain code. They give the same answer every time, and they decide whether a pack can be released. Each writes its result into the manifest, so the result becomes part of the evidence.

Check	Passes when	Fails when	Writes
`check_coverage`	Every requirement in the set has at least one evidence topic that survives the pack's profile	A row is empty, or its only evidence is removed by the profile	Coverage table
`check_currency`	Each evidence topic was revised on or after the model version date, or holds only key references whose keys changed in an approved commit after that date	A topic is older than the model version and contains literal values	Stale list
`check_approval`	The last change to each topic merged through a pull request approved by a code owner who is not the author or the agent²⁸³⁰	A direct push, a self-approval, or no approval	Approver for each item
`check_consistency`	Each specification value resolves from a key, keys resolve the same in every pack, and no authority-only key appears in the public or downstream build	A literal value conflicts with a key, or authority content leaks	Conflict and leak list

5.4 Agent tools

The agent has ten tools. One calls the model. The pattern comes from the earlier projects in this series: plain tools give the same result every time, checks decide, and a person approves³²³³.

1. Load the requirement set `load_requirements`

Reads the requirement map for this request: Annex XI, Annex XII, or a set of NIST AI RMF subcategories. Each requirement is a topic with a key and the audience it is required for.

output: requirement keys, legal sources and required audiences

2. Read the evidence map `read_evidence_map`

Reads the relationship table, each evidence topic's prolog and keys, and the Git log and pull request reviews for each topic file.

output: requirement-to-topic links with dates, model version, commit and reviewers

3. Check coverage `check_coverage` check

Every requirement has evidence that survives the pack's DITAVAL profile.

output: covered requirements out of all requirements, with each empty row

4. Check currency `check_currency` check

Compares each topic's revised date and model version with the current model version date. A topic that holds only key references passes when its keys were updated in an approved commit.

output: current topics out of all topics, with each stale topic

5. Check approval `check_approval` check

Reads the pull request reviews from the GitHub API. The approver must be a code owner, must not be the author, and must not be the agent's account.

output: approver, role and date for each topic

6. Check consistency `check_consistency` check

Every value comes from a key. A key gives the same value in every pack. Authority-only keys never resolve in the public or downstream build.

output: conflicts and leaks, each with file and line

7. Propose a link `propose_mapping` model

Runs only for requirements with no evidence. Gemini reads the requirement topic and the titles and short descriptions of candidate topics, never their bodies. It returns a candidate topic ID from a list of real IDs, a reason and a confidence, or "none".

output: a relationship table change on a branch, or a gap note for the owner

8. Build the pack `build_pack`

Runs DITA-OT 4.4 on the map with the request's DITAVAL profile. Writes the PDF and HTML, the manifest (§5.8) and the coverage report.

output: pack files, manifest.json, report.html

9. Open the review `open_review`

Opens a pull request with the pack and the report. Assigns link proposals to the information architect and gaps to their owners. Asks the compliance lead to release. The agent can't approve.

output: review pull request and issues for each gap

10. Seal the pack `seal_pack`

Runs only after the compliance lead approves the release. Hashes each file with SHA-256, uploads the pack to a Cloud Storage bucket with a locked 10-year retention policy²⁰, and writes one row to the BigQuery register.

output: object paths, manifest hash, register row

5.5 Agent loop

Checks run first. Gemini is called only for coverage gaps. Currency, approval and consistency failures go to people as gap notes, because only the owner can fix a stale topic or approve a change.

Figure 12

Agent loop for one request

A gap is never hidden. It is fixed in the source and the loop runs again, or it ships in the report with the compliance lead's decision and reason. Gemini never sees currency, approval or consistency failures.

The schema for propose_mapping is built fresh for each run, so the candidate list holds only topic IDs that exist in the map. Gemini can't link to a topic that isn't there. A proposal with a confidence under 0.6 becomes a gap note, not a pull request.

// propose_mapping schema (excerpt) · run 0457 · requirement aia.xi-2d
{
  "type": "object", "additionalProperties": false,
  "required": ["requirement", "candidate", "reason", "confidence"],
  "properties": {
    "requirement": { "enum": ["aia.xi-2d"] },
    "candidate":   { "enum": ["gemma4-training-infrastructure", "gemma4-models-overview", …, "none"] },
    "reason":      { "type": "string", "maxLength": 300 },
    "confidence":  { "type": "number", "minimum": 0, "maximum": 1 },
    "gap_note":    { "type": "string", "maxLength": 400 }
  }
}

5.6 One request, end to end

Figure 13 follows the AI Office request in the third simulator scenario (§6). Two requirements have no evidence. Gemini finds a topic for one of them. The other is a real gap.

Figure 13

Sequence: Annex XI pack for Gemma 4

One model call for the whole pack. The information architect reviews one link and the compliance lead makes one decision about one gap: the energy figure for Annex XI point 2(e).

5.7 One source, three packs

The same source builds three packs, one for each reader that the regulation names. The authority topics exist once and are never copied.

Figure 14

Three DITAVAL profiles over one source

audience="public"audience="downstream"audience="authority"

Topic counts are for the sample source. Each profile only adds audiences. A reader never gets a topic marked for a narrower audience.

Pack	Profile	Requirement set	Sent to	Time limit
Public model card	`public.ditaval`	Model card sections	Anyone	At release
Downstream pack	`downstream.ditaval`	Annex XII, 11 items⁸	Downstream providers	14 days¹³
Authority pack	`authority.ditaval`	Annex XI, Section 1, 11 items⁷	AI Office, national authorities⁶	On request

5.8 The manifest

The manifest is the part of the pack that turns documentation into evidence. It records, for each requirement, which topic answered it, from which commit, on which date and with whose approval. It also records every gap and the decision about it.

Figure 15

manifest.json for the Annex XI pack (excerpt)

{
  "pack_id":  "gemma4-aia-xi-2026-10-20-01",
  "request":  { "from": "AI Office", "basis": "Article 53(1)(a)", "issue": 456 },
  "source":   { "commit": "9c41e7a", "profile": "authority.ditaval", "model_version": "gemma-4" },
  "items": [
    { "req": "aia.xi-1d", "topics": ["gemma4-models-overview"], "revised": "2026-07-30",
      "approved_by": "technical-writer", "pr": 418, "checks": "pass" },
    { "req": "aia.xi-2d", "topics": ["gemma4-training-infrastructure"], "revised": "2026-07-30",
      "approved_by": "training-lead", "link": { "proposed_by": "propose_mapping", "confidence": 0.86, "approved_by": "information-architect", "pr": 457 } },
    { "req": "aia.xi-2e", "topics": [], "checks": "gap",
      "decision": { "by": "compliance-lead", "date": "2026-10-20", "note": "energy estimate due with next release; issue 458" } }
  ],
  "files":    [{ "path": "gemma4-annex-xi.pdf", "sha256": "3b7f…a91c" }],
  "released": { "by": "compliance-lead", "pr": 459 },
  "sealed":   { "bucket": "aegis-evidence", "retention": "315360000s, locked" }
}

ProvenanceCommit, date and approver for each requirement. Roles here, named people in a real pack.

Model's partThe link Gemini proposed is labelled as proposed, with the person who approved it.

Recorded gapThe missing item is in the pack, with a decision, a name and a date.

Sample values. 315,360,000 seconds is 10 years, the minimum retention in the Code of Practice¹³. Cloud Storage allows up to 100 years²⁰.

5.9 NIST AI RMF evidence

The NIST subcategories go into the requirement map as one more set of topics. The same checks then produce evidence for them, with no extra tool.

Subcategory	What it asks, paraphrased¹⁶	AEGIS evidence
GOVERN 1.6	Mechanisms to inventory AI systems	The BigQuery register lists every model, version and pack
MAP 2.2	Information on the system's knowledge limits and human oversight	Limitations topics are required evidence; `check_coverage` fails without them
MEASURE 2.8	Transparency and accountability risks examined and documented	The manifest names the approver of each statement
MEASURE 2.9	The model is explained, validated and documented	Coverage of model overview, benchmark and evaluation topics

5.10 Where it runs

Figure 16

Deployment on Google Cloud

No server runs between requests. The bucket and the register are the only state that lasts, and the bucket can't be changed once a pack is sealed.

Part	Technology	Free tier or licence
Agent framework	Agent Development Kit²²	Apache 2.0
Model	Gemini 3.8 Flash (`gemini-3.8-flash`), structured output	Gemini API free tier for the POC²⁶
Pack build	DITA-OT 4.4 with DITAVAL¹⁹	Apache 2.0
Trigger and approval record	GitHub Actions, protected branches, code owners²⁸³⁰	Actions free for public repositories²⁹
Agent runtime	Cloud Run job, one run per request	Cloud Run free tier²¹²⁷
Sealed packs	Cloud Storage, retention policy locked with Bucket Lock²⁰	5 GB-months of Standard storage²¹
Pack register	BigQuery	1 TB of queries a month²¹
Secrets	Secret Manager	6 secret versions a month²¹

Data handling. The sample content is public, so the Gemini API free tier is acceptable for the POC. Content sent on the free tier is used to improve Google products, so a real deployment needs the paid tier²⁶. AEGIS also limits what the model sees: propose_mapping sends only requirement text and the titles and short descriptions of candidate topics, never the body of an authority topic.

Known limits. AEGIS proves that evidence exists, is current, was approved and is consistent. It doesn't prove that the evidence is true. A locked retention policy can't be removed or shortened²⁰, so the POC tests with a short unlocked policy first. Free-tier limits change over time²¹.

§6 Evidence Simulator

Three requests for Gemma 4. The first passes cleanly. In the second, a model update raises two flags and code clears both. In the third, Gemini finds one missing link and the compliance lead gets one real gap.

aegis · evidence simulator

idle

Sample request

// choose a sample request and run it

Scripted demo. No live model call. Issue numbers, timings, token counts and costs are illustrative.

§7 Success Metrics

The MVP is measured on the Gemma 4 sample source, with one authority pack and one downstream pack. Each metric comes from a check result, the manifest or the register, not from a judgement.

Metric	How it is measured	MVP target
Requirements in a released pack that are covered, current and approved	Check results in the manifest	100%, or a recorded decision for each gap
Items with a named human approver from Git	`check_approval`	100%
Values in packs that resolve from a key	`check_consistency`	100%
Authority content found in public or downstream output	Leak test in `check_consistency`	0
Time from request to a pack ready for release	Issue opened to review pull request	Under 1 working day
People hours per pack	Pull request review timestamps	Under 4, against a modelled 32 by hand (Figure 6)
Model calls per pack	Register	Only for unmapped requirements, falling as the map fills
Packs sealed with a locked policy and a manifest hash	Register and bucket metadata	100%

Figure 17

Sample report on the review pull request

Review PR #459 · issue #456 · Gemma 4 · Annex XI · authorityready · 1 recorded gap

10/11requirements covered

14/14topics current

14/14topics approved

1model call

Built from

Commit 9c41e7a · profile authority.ditaval · model version gemma-4
Requirement set: Annex XI, Section 1 (11 items), maintained by the information architect

Checks

Coverage: 10 of 11. Point 2(e), energy use, has no evidence topic.
Currency: 14 of 14 topics revised on or after the gemma-4 version date
Approval: 14 of 14 through approved pull requests, 3 roles, no self-approval
Consistency: 23 keys, 0 conflicts, 0 authority keys in other builds

Model proposals

Point 2(d) → gemma4-training-infrastructure, confidence 0.86. Approved by the information architect in PR #457.

Decision needed

Point 2(e): release with the gap recorded, or hold until issue #458 is closed. Owner: research engineering.

Cost

Build 3 min 40 s · 1 model call · 6,420 tokens in · 380 tokens out · under $0.01

The report tells the compliance lead where to look: one proposal, already reviewed, and one decision. Everything else has passed every check.

Figure 18

Requirements that needed a model call, per pack (modelled)

Annex XI and XII packsafter a new requirement set

Modelled, not measured. Each approved link stays in the relationship table, so the model is needed less with each pack. A new requirement set starts the curve again, at a lower point.

Sources

Checked on 20 October 2026.

Google Developers, "Site Policies." developers.google.com/site-policies
Google AI for Developers, "Gemma 4 model card," last updated 30 July 2026. ai.google.dev/gemma/docs/core/model_card_4
Google AI for Developers, "Gemma 3 model card," last updated 14 August 2025. ai.google.dev/gemma/docs/core/model_card_3
Google AI for Developers, "Gemma models overview," last updated 8 July 2026. ai.google.dev/gemma/docs/core
Regulation (EU) 2024/1689 (Artificial Intelligence Act), EUR-Lex. eur-lex.europa.eu/eli/reg/2024/1689/oj
EU AI Act, Article 53: obligations for providers of general-purpose AI models. artificialintelligenceact.eu/article/53
EU AI Act, Annex XI: technical documentation for providers of general-purpose AI models. artificialintelligenceact.eu/annex/11
EU AI Act, Annex XII: transparency information for downstream providers. artificialintelligenceact.eu/annex/12
EU AI Act, Article 101: fines for providers of general-purpose AI models. artificialintelligenceact.eu/article/101
"Digital Omnibus on AI," Regulation (EU) 2026/1744, AI Act Explorer. artificialintelligenceact.eu/ai-act-explorer/digital-omnibus
ActuIA, "AI Act: obligations in force and delays under omnibus 2026/1744." actuia.com/en/news/ai-act-obligations-in-force-and-delays-under-omnibus-2026-1744
European Commission, "The General-Purpose AI Code of Practice," last updated 7 October 2026. digital-strategy.ec.europa.eu/en/policies/gpai-code-practice
AI Act Explorer, "Overview of the Code of Practice." artificialintelligenceact.eu/code-of-practice-overview
TechCrunch, "Google says it will sign EU's AI code of practice," 30 July 2025. techcrunch.com/2025/07/30/google-says-it-will-sign-eus-ai-code-of-practice
NIST, "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework
NIST AI 100-1, "Artificial Intelligence Risk Management Framework (AI RMF 1.0)," January 2023. nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
OASIS DITA 1.3, "reltable." docs.oasis-open.org/dita/dita/v1.3/os/part1-base/langRef/base/reltable.html
DITA 1.3 specification, "Conditional processing (profiling)." dita-lang.org/1.3/dita/archspec/base/condproc
DITA Open Toolkit 4.4, "DITA 2.0 preview support." dita-ot.org/4.4/reference/dita-v2-0-support
Google Cloud, "Bucket Lock." docs.cloud.google.com/storage/docs/bucket-lock
Google Cloud, "Free Google Cloud features." cloud.google.com/free
Google, Agent Development Kit documentation. github.com/google/adk-docs
Google AI for Developers, "Gemini 3.8 Flash." ai.google.dev/gemini-api/docs/models/gemini-3.8-flash
Google AI for Developers, "Function calling with the Gemini API." ai.google.dev/gemini-api/docs/function-calling
Google AI for Developers, "Structured outputs." ai.google.dev/gemini-api/docs/structured-output
Google AI for Developers, "Gemini Developer API pricing." ai.google.dev/gemini-api/docs/pricing
Google Cloud, "Cloud Run pricing." cloud.google.com/run/pricing
GitHub Docs, "About protected branches." docs.github.com/.../about-protected-branches
GitHub Docs, "How use of GitHub Actions is measured." docs.github.com/en/billing/concepts/product-billing/github-actions
GitHub Docs, "About code owners." docs.github.com/.../about-code-owners
Siddharth Rao, "AEGIS: AI Evidence and Governance Integrity System," first design. github.com/raosiddharthp/The-Autonomous-Compliance-Officer
Siddharth Rao, "MANIFEST," design document. siddharthraop.github.io/Manifest
Siddharth Rao, "AlignR," design document v0.1. siddharthraop.github.io/AlignR