Technical details of the development assistant.

What it creates

The directory it sets up, file by file

Everything AIQT keeps for your project lives in one directory, .aiqt/, created at setup if it does not already exist. During setup the wizard asks which of these files you want, and the default is all of them, so your assistant follows good practice from the first day rather than from when you remember to ask.

your-project/
├── .aiqt/
│   ├── config.md              yours: own it, edit it, commit it
│   ├── CHANGELOG.md            what changed, and when
│   ├── TODO.md                 the work coming up
│   ├── DONE.md                 what has shipped
│   ├── ROADMAP.md              where the project is heading
│   ├── open-findings.md        defects, tracked to closure
│   ├── pending-decisions.md    decisions waiting on you
│   ├── ...                     the QA audit registers (below)
│   └── core/                   the updater's only write location
├── src/                        untouched
└── ...                         untouched

• config.md: your configuration, including which guardrails are active and the sharing setting. Yours to own, edit, and commit, and updates never rewrite it. The next section covers it in full.
• The practice files (CHANGELOG.md, TODO.md, DONE.md, ROADMAP.md): what changed, the work coming up, what has shipped, and where the project is heading, so you and your assistant share one record of where things stand.
• The QA audit trail (open-findings.md, pending-decisions.md, the validation-sweep history, the publications-screening register, the deep-assessment register, the verifier-override log, and an improvement log): a committed, reviewable record of what the assistant's quality checks did, so a teammate or a manager can audit the QA itself.
• core/: the one directory AIQT's updater writes to. A guard refuses every write outside it, so a diff after any update shows changes in exactly one place, and nothing else in your repository changes without your say-so.

With your permission, AIQT sets these up, and every one is yours to keep, edit, or remove. They are committed with your project, not hidden away, so the record stays reviewable. They help you and your development assistant equally: the assistant reads them to pick up context and updates them as it works, so the two of you are never out of sync.

A tool that updates itself inside your repository earns a hard question: what else can it touch? With AIQT you can check the answer yourself, because the updater writes only inside .aiqt/core/, and reviewing an update takes the same shape as reviewing any other change: read the diff, and the diff is small and contained.

Your configuration

The config file you own

Your choices live in .aiqt/config.md, and that file is yours: you own it, you edit it, you commit it. In the 1.1.0 design, updates never rewrite it.

The config also carries the sharing setting described in the next section, so the decision about what leaves your project sits in a file you control, alongside every other decision you have made.

Sharing back

New-guardrail seed PRs

When a guardrail gap lets an issue through, the fifth rule closes the gap locally. The 1.1.0 design adds an optional last step: contributing the new guardrail back to the AIQT project as a seed PR, so a gap found once is closed for every developer who uses AIQT.

Why this is worth turning on. Every team's assistant misses different things. A seed PR turns one team's miss into everyone's guardrail, and because seeds are scrubbed to concept, trigger, and goal, contributing costs you nothing you would want to keep. The exchange runs both ways: the guardrails your assistant ships with include the ones other developers contributed the same way, under the same ShareAlike licence.

CI

In your pipeline

Standardizing quality assurance

One QA standard, whichever model checks the work

A review by a single model shares that model's blind spots. AIQT standardizes the check itself: for substantive work, two verifiers from different model families (one Claude-family, one GPT/Codex-family) are given the same brief, each instructed to refute the change rather than confirm it, and their verdicts are reconciled. Different families miss systematically different things, so the cross-family pair catches what either alone would let through. This is how AIQT itself is built and reviewed; in the 1.1.0 design, the development assistant brings the same standard to your project.

1. Routine changes run the ordinary gates. Most work needs nothing heavier, and a review that fires on everything stops being read.
2. Substantive changes get the dual-family pair: the same refute-brief to both families, verdicts reconciled, disagreements examined rather than averaged away.
3. Delicate changes escalate to a heavier harness: where a wrong result is a correctness defect no simple check catches, the change is large or delicate, and an escaped error is costly, independent adversarial verifiers are briefed to refute the work, and the result is applied deterministically rather than by hand. The review is up-skilled for the work that warrants it, and only that work.

The point of the tiers is that the standard scales with the stakes instead of depending on who happened to run the check. A passing review means the review actually ran; a failing one is surfaced, never quietly weakened. That is the AIQT ordering applied to review itself.

Where it runs

The same check, in your pipeline and on your machine

A QA standard only standardizes anything if it holds in both places work happens: at the gate, and at the desk. In the 1.1.0 design it runs in both.

The result is one standard applied the same way wherever the work runs and whichever model does the reviewing: quality stops depending on who ran the check or which tool they used.

Per-language depth

Language and framework depth, composed at install

The governance core is deliberately language-neutral. Deep per-language and per-framework guidance comes from vetted aligned sources, and the setup generator composes them in at install time.

During setup, the generator detects your stack and presents the aligned sources that apply to it. For each source you see the facts a decision needs: what it covers, its licence, when it was last reviewed, and the gaps it leaves. Then you choose, taking all that apply or deciding one by one. AIQT lists each source, shows you these facts, and credits and links the people who do that work. The decision to use a source is always yours.

• Coverage: what the source addresses in your stack.
• Licence: the terms it is published under.
• Last reviewed: when it was last checked, because per-language depth has a shelf life.
• Gaps: what it leaves uncovered, stated up front.

Ready to try it

Set it up, or read the source

The setup and verification steps are on the overview page, and where 1.1.0 stands is stated plainly there too.