(Accuracy = Integrity = Quality = Trust) > Progress > Speed > Cost

For teams and organizations

One standard your whole team can work to.

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 intended to reach across Claude, ChatGPT, and Copilot, so a colleague on one assistant is meant to work to the same rules as a colleague on another. That cross-assistant reach is the intent, not a verified result yet: the evidence page marks every platform pending, with ChatGPT, Gemini, and Copilot not yet tested. Contributing a fix back is Rule 5's voluntary Guardrail-Seed give-back, separate from the software licence, so a fix one team contributes can strengthen every other team's guardrails. Adoption today is human-led: each person adds AIQT to their own assistant, under a rollout your team runs. Central deployment, policy enforcement, and cross-team reporting do not exist today; two of them are ideas we are considering.

Today

What a shared standard gives your team today

One definition of "done", intended for every assistant on the team, with a record behind it. Most teams already have people using AI assistants, each with their own habits and their own idea of what "done" means; AIQT replaces that spread with one ordering, decided in advance.

Consistency you did not have to police

The quality-versus-speed argument happens once, in advance, instead of on every deadline. Every assistant on the team is meant to work to the same ordering, so the call is already made before the pressure arrives.

Sign-off backed by evidence you can check

Claims trace to sources, catches are named, and overrides are logged. With the 1.0.5 chat Skill, that record lives in the conversation itself: the stated sources, the named catches, and the logged overrides you can scroll back to. Repository-level records are part of the 1.1.0 design, in development, and aggregate reporting across a team is an idea we are considering.

A standard that survives tool changes

The standard is designed to be 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.

Improvements that compound, opt-in

When a gap lets an issue through, the guardrail is improved so it should not recur, and teams that opt in can contribute the portable fix back. Sharing is opt-in, a voluntary Rule 5 Guardrail-Seed give-back separate from the software licence, so one team's lesson can become every team's guardrail.

Teams that write code have a version on the way: the development assistant (1.1.0, in development) installs the same standard into a project, keeps to its own directory, and integrates with your CI.

Not available today

What does not exist yet

Said plainly, so you can plan around it.

  • Central deployment of the Skill to a team.
  • Technical enforcement of the standard: it is a behavioural standard the assistant follows, not a control that blocks a model.
  • A shared or aggregate record across people.
  • Admin controls, policy management, and cross-team reporting.
  • Commercial support and service levels.

Three of these lead to the two ideas we are considering, below: the shared record to the web console, and central deployment and admin controls to enterprise management. The other two, technical enforcement and commercial support, are not among them.

Start a team pilot

How to evaluate AIQT with your team

Today's team path is a human-led pilot: a small group, the assistants they already use, and a few weeks of normal work. Here is a shape that works.

  1. Choose a small group and the assistants they already use (Claude, ChatGPT, or Copilot).
  2. Each person installs AIQT 1.0.5 and confirms that it is on.
  3. Run two or three weeks of normal work, noting a few observations: unsupported factual claims, completion claims without a check, missed requirements, clarification questions asked, overrides, rework, and reviewer confidence.
  4. Compare against the period before, on the same observations.
  5. Decide: keep it, extend it, or remove it.

Questions, or want to share what you found? Open a GitHub discussion. There is no sales or support team yet; this is an open project, and that is the honest state of it. The evidence page collects the release, limitations, and documented cases.

Ideas

Ideas we are considering for organizations

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.

Ideas we are considering

A web console for governance activity

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.

Ideas we are considering

Enterprise management

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.

How we decide

How we decide what ships

We move an idea into a release only when we can say what it does and point to the evidence behind it, marking what is still pending rather than implying it. 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

Open source, portable, and shared

The guardrails are designed to be portable across toolchains, so adopting the standard leaves your team free to change tools without changing rules. Contributing an improvement back is Rule 5's voluntary Guardrail-Seed give-back, separate from the software licence, so a fix one team contributes can strengthen every other team's guardrails. Contribution is opt-in. Start with the overview on the home page, or go straight to the source.