Where the projects fit in the solution lifecycle
Last updated 5 November 2026
Every solution an organization delivers moves through the same phases: it is planned, built or bought, configured, checked, released, run, changed, assessed, and in time handed over or retired. My 6 projects each serve 1 or more of those phases, and 3 of them work at every phase once installed. This page sets out when to bring each one in, where it plugs in, what it produces, and what it gives you.
The lifecycle
The phases carry plain names of my own, so that they fit solutions you build, buy, configure, or take as a service.
- Govern. Set the policies, roles, registers, and rules before the work starts.
- Plan and design. Decide what is being built or bought, and what it must meet.
- Build and configure. Write the code, set up the services, and choose the settings.
- Verify and release. Check the work, record what was checked, and ship.
- Operate and change. Run the solution, make changes, and keep the records.
- Assess and demonstrate. Before a decision such as a release, a handover, an acquisition, a supplier approval, or a customer's assurance request, establish with evidence where the solution stands, and remediate.
- Hand over or retire. Pass the solution to its next owner, or take it out of service, with the records that explain it.
The map
Primary: the phase the project is built for. Also: a further use its own site describes. Throughout: the project acts at every phase once it is installed.
| Phase | GRC Library | AIQT Guardrails | Clean Language | Secure Config | OPFiles | Audit This |
|---|---|---|---|---|---|---|
| Govern | Primary | Throughout | Throughout | Throughout | ||
| Plan and design | Also | Throughout | Throughout | Throughout | ||
| Build and configure | Throughout | Throughout | Primary | Throughout | ||
| Verify and release | Throughout | Throughout | Also | Throughout | Also | |
| Operate and change | Also | Throughout | Throughout | Also | Primary | |
| Assess and demonstrate | Also | Throughout | Throughout | Also | Also | Primary |
| Hand over or retire | Throughout | Throughout | Also | Also |
Installed once, active throughout
3 of the projects are rules or records that an AI assistant carries into every phase. Install them at the start of a project, or when a new assistant or tool is introduced, and they apply to everything that follows.
AIQT GuardrailsThe conduct standard
An assistant sounds as confident when it guesses as when it knows. AIQT holds it to 1 written standard, which puts Accuracy, Integrity, Quality, and Trust ahead of Progress, Speed, and Cost: claims are checked or marked as unchecked, shortcuts are reported, and done means that the stated bar was met. It installs as a skill in chat assistants, by 1 prompt in development assistants, and, in Claude Code, as an opt-in plugin of hooks that blocks or warns on the actions it is built to catch. Audit This reads it first and obeys it throughout, which is why it governs the assistant's conduct in the other 5 projects.
Results depend on the assistant and the model you use.
Clean LanguageThe writing standard
Whenever an assistant writes something the organization will rely on, from a design note to a policy, a release note, an incident update, or an audit report, its prose can drift from the facts. Clean Language is a small file of rules added to the assistant once: it removes filler, contrast framing, and dashes, and keeps your facts, figures, names, and quotations as you gave them, by instruction.
A model can still change meaning, so read the result before you rely on it, and have a qualified person review high-stakes text.
OPFilesThe operational record
Records kept in chat logs and hand-edited notes drift from what the tools did, so nobody can cite them in a review, an audit, or a handover. OPFiles pairs machine-written TOML records with generated, readable views and adds a drift gate, which runs as a required commit or CI check and fails the moment the 2 disagree. An AIQT adoption sets it up by default.
Its checks establish that the records are well formed and in step with their views; a review must still confirm that what they record is true.
Phase by phase
GRC LibraryGovern
A governance, risk, or compliance programme starts from a blank page. Charters, policies, procedures, and registers have to be written, and each must then be mapped to the frameworks an auditor will ask about. GRC Library gives you a cross-referenced set of organization-neutral documents in 12 domains. Each document names its owner, approver, and classification, and is mapped to the relevant frameworks. The library also includes a crosswalk of standards, laws, and programmes, and templates to help you adopt it: a quickstart, a roadmap, and a maturity self-assessment. Bring it in before the first control is reviewed, and return to it whenever an audit or a customer asks for the documents behind a control. Its executive path supports oversight at any phase.
You adapt the documents with your own names and details and approve them. Adopting them confers no certification, and legal advice is outside the library.
Secure ConfigBuild and configure
An assistant that sets up a service can leave it exposed unless told otherwise, with gaps such as encryption left off, default credentials kept, and factory settings unchanged. Secure Config gives it short guides, 1 for each deployment decision, drawn from the vendors' documentation. The assistant applies 10 rules to every service and runs an 11-check verification checklist before reporting completion, recording each item as pass, fail, untested, or not applicable. Use it at each deployment decision, on each later change to a service, and as a review of what is already running: its ready-made tasks include auditing a project, reviewing an AI and agent stack, and adding single sign-on and MFA, and 3 of the tasks wait for your approval before changing anything.
Its checklist steps are reasoned from documented vendor behaviour, with no deployment run recorded, so a passed checklist records a reasoned result and verifies no control on its own.
Audit ThisAssess and demonstrate
Before a release, a handover, an acquisition, a supplier approval, or a customer's assurance request, you need evidence of where a solution stands against the security, governance, privacy, and quality references that apply to it. Audit This gives your assistant 2 prompts. The first plans an assessment shaped by the decision you face, selecting from a tiered register of openly published references and giving a reason for every inclusion and exclusion. The second runs the plan and reports findings with evidence, each carrying exactly 1 of 5 labels: demonstrated, reasoned, gap, untested, or not applicable. Planning and assessment change nothing; remediation happens only on your named approval and is re-verified with the same labels. The report is written for the teams who will remediate, with a distribution version for external recipients where the plan names them.
You run it yourself with your own assistant. Certification and attestation are separate services, and nothing here makes a project compliant, secure, or complete.
How they hand off to each other
- Audit This assesses against 4 of the other projects: AIQT as the conduct rule it reads first, Secure Config and GRC Library as references applied to every project, and Clean Language where written artefacts are deliverables.
- A Secure Config checklist result enters an Audit This report as reasoned, never as demonstrated, because the checklist's own steps are reasoned at source.
- Secure Config's gap assessment task asks an assistant to assess a project against the GRC Library's control sets, and the library publishes a compliance controls and gap register template to record the result.
- OPFiles records are the kind of self-reported evidence an assessment registers and weighs, and the OPFiles worklog is a record a handover can cite.
- Clean Language applies to what the other 5 produce: adapted policies, checklist reports, audit reports, generated views, and assistant answers.
- The GRC Library's automated contribution rules for assistants became AIQT, and OPFiles is part of AIQT: the 3 share 1 lineage.
Where to start, by situation
- Starting a project with an AI assistant. Install AIQT first, with OPFiles for the records, and add Clean Language if the assistant will write anything people rely on.
- Standing up or renewing a governance programme. Start from the GRC Library's Browse page, which groups the documents by the seat you hold, and adopt the documents your obligations need.
- Deploying or changing a service. Point the assistant at Secure Config's guide for the stack, and require the checklist in its completion report.
- Facing a release, a handover, an acquisition, or a customer's assurance request. Run Audit This's planning prompt, answer its intake questions, and let the plan select the references.
What this page does not claim
These projects help you assess, verify, find, remediate, and demonstrate. None of them makes a solution or an organization compliant, secure, or complete, and none replaces a certification, an attestation, or legal advice. Each project's site states its own scope and limits, and those statements take precedence over this summary.