Help improve the engineering model
The engineering model on this site is a set of requirements, patterns, framework mappings and evidence formats. It only improves when someone tests it against a real system and records where it holds and where it does not.
Ways to contribute
Nine of these paths open a GitHub issue form that asks for the fields needed to act on the report; the tenth is a pull request. Each needs a GitHub account; this site sends nothing.
Open for review now: the draft control specifications in the open control profiles, the draft research notes and the incident cases they draw on, all built on what AI governance means in engineering terms.
- Review a control profile Test one control against an environment you know: does it hold as written, and what evidence could you produce?
- Propose a failure mode A way an AI system or agent breaks that a control should catch, backed by a public record.
- Contribute an implementation example A configuration, pipeline step, test, runtime policy or evidence export that implements a control, with the record it leaves.
- Map a control to a framework clause Link a control to a clause of a law, standard or framework, with the official URL and how strong the mapping is.
- Correct a technical error A wrong requirement, evidence statement, mapping, threat id, version or date, with the source that shows it.
- Review a research note Check a draft note, one section of it or a single claim against its sources.
- Propose an incident case A documented incident, the failure behind it and the control that would have caught it.
- Propose an obligation row An obligation missing from the register, with its instrument, its date and its status.
- Suggest a source A stronger primary source for a claim, or a claim that still needs one.
- Open a pull request For a change you can make yourself: the contributing guide sets the rules every pull request follows.
What a good control review contains
A review is useful when someone else can repeat it. Whether the control holds or fails, it states these six things.
- The control and the version reviewed The control id, for example AIGE-CTL-EVAL-001, and the version of the profile you read.
- The environment you tested it in By category, such as a containerised evaluation harness or an agent calling MCP tool servers. Never a vendor or product name.
- Whether the requirement is testable as written Could you decide pass or fail from the text alone, or did you have to guess what it meant?
- The evidence you could or could not produce The record the environment actually leaves, and the part of the evidence requirement it cannot meet.
- The source behind any objection A public document, specification or incident record that supports the change, not an opinion alone.
- What should change The wording, the evidence requirement or the mapping you would put in its place.
The control review form asks for each of them. A review that finds a control holds as written is as useful as one that finds a gap.
Licence, versions and credit
Everything on this site is licensed CC BY 4.0, and so is a contribution once it is merged. Each release is archived on Zenodo: version 0.5.0 is DOI 10.5281/zenodo.22956197, and the concept DOI 10.5281/zenodo.22857084 always resolves to the latest release. Citation metadata is in CITATION.cff, and every change is recorded in the changelog.
Accepted substantive contributions are credited by name in bok/CONTRIBUTORS.md,
shown on the contributors page; contributing does not by
itself confer co-authorship. A control profile or research note moves from draft to published
only once a credited reviewer has reviewed it; the methodology
sets out how sources, review and corrections work.
Review the first control profile
Draft controls for AI evaluation environments, each open for technical review.