For teams and organizations
Ask two colleagues what their AI assistant means by "done" and you will get two answers. Today the quality of your team's AI-assisted work depends on who did it and which tool they used. AIQT replaces that with a single governance standard: the same skill loads into Claude, ChatGPT, or Copilot, so the same rules apply whichever assistant a colleague uses. Because the pack is published under CC BY-SA, a fix one team contributes can be reused by every other team under the same licence.
The value proposition
One definition of "done", applied by every assistant, with a record behind it. That is the whole proposition, and here is what it changes.
The quality-versus-speed argument happens once, in advance, instead of on every deadline. Every assistant on the team works to the same ordering, so the call is already made before the pressure arrives.
Claims trace to sources, catches are named, overrides are logged with a way to revert them. Whoever approves AI-assisted work approves something they can check, not something they have to take on faith.
The standard is portable across assistants and toolchains. Swap Claude for ChatGPT, or add Copilot, and the rules travel; your team's definition of "done" is not locked to any vendor.
When a gap lets an issue through, the guardrail is fixed so it should not recur, and teams that opt in can share the fix back. Under the ShareAlike licence, one team's lesson becomes every team's guardrail.
Today
Most teams already have people working with AI assistants, each with their own habits, their own tools, and their own idea of what "done" means. AIQT replaces that spread with one ordering, decided in advance: Accuracy, Integrity, Quality, and Trust before progress, speed, and cost. Nobody has to re-argue it under a deadline.
AIQT 1.0.0 is one skill anyone on the team loads into a chat assistant that accepts one. From then on, every assistant is held to the same stated standard: claims match their sources, checks are kept at full strength, and work is finished only once a check confirms it. Put the skill in your onboarding and a new joiner works to the same standard from day one.
Under AIQT, every claim traces to evidence, and every override is logged with a way to revert it. When a guardrail catches something, the assistant says which guardrail and what it caught. When something fails, the failure is surfaced. That gives a reviewer, a lead, or an auditor something concrete to check.
Trust is granted by a person, and earned by the record. Because the record shows what was verified, what was overridden, and what failed, a manager signing off on AI-assisted work is signing off on evidence they can check.
When a guardrail gap lets an issue through, the guardrail is improved so it should not recur, and with permission the portable fix can be contributed back. Sharing is opt-in, and the ShareAlike licence keeps every contributed improvement open, so a fix another team contributes can be reused by yours under the same licence.
Teams that write code have a version on the way: the development assistant, currently in development, installs the same governance core into a project, keeps to its own directory so nothing else in your repository changes without your say-so, and integrates with your CI.
Ideas
The two directions below are ideas under consideration. We are sharing them so you can see where our thinking is heading, and so you can tell us whether they would help your organization. There are no dates attached and no commitment behind them; they may change shape or may never ship.
A web console would show governance activity across your projects without requiring a terminal. The benefit for a team lead: one place to see what the guardrails caught, what was overridden, and how the standard is holding across the work, in a form the whole team can read, including the people who never open a command line.
This is an idea we are considering. It carries no date and no commitment.
Enterprise management would cover what an organization needs beyond an individual: central policy, shared configuration, and reporting across teams. The benefit: an organization could set its standard once and have every team inherit it, keep configuration consistent from one source, and see across teams how the standard is being applied.
This too is an idea we are considering. It carries no date and no commitment.
How we decide
We move an idea into a release only when we can say what it does and show that it works. That rule is why this page separates today's capabilities from ideas so firmly: the same standard AIQT holds an assistant to, we hold ourselves to. A claim about the product should trace to evidence, and "available" should mean a check actually ran.
Open source
AIQT is published under Creative Commons Attribution-ShareAlike 4.0. The guardrails are portable across toolchains, so adopting the standard leaves your team free to change tools without changing rules. Improvements contributed back carry the same ShareAlike licence, so a fix one team contributes can be reused by any other team. Contribution is opt-in. Start with the overview on the home page, or go straight to the source.