AI QA Manual
Sign in to manage quality manuals and their controlled copies.
For a company that has never been certified and has no manual to import. This is the front matter an auditor looks for before reading a word of the content: whose manual it is, its number, the scope it claims, and who approved it.
What the company does, in the words that will appear on the certificate. It can be changed later, but an auditor reads it first and measures everything else against it.
Creating the manual opens the writing screen — the clause tree on the left, and for each clause what this company actually does to meet it. Nothing reaches a copy holder until you issue a revision, so there is no harm in a half-written manual.
Clauses marked not applicable need a justification: an auditor accepts an exclusion that is reasoned and refuses one that is merely missing.
Clause 7.1.5: the instruments this company's conformity decisions rest on. An auditor who finds an uncalibrated gauge does not raise a finding about the gauge — they raise one about everything it has measured since.
The laboratory and its certificate number matter as much as the dates. A register that cannot say who proved the instrument, and against what, proves nothing itself.
Every certificate these instruments have had before the current one, and anything taken off the register. Kept because "show me the previous certificate for that scale" is an ordinary question at an audit, and an update that overwrote it could not answer.
Paste the key you were sent. Without a current licence the manual can still be read, printed and exported — only new revisions, copy holders and issued copies stop.
The language your quality system is written in. Everything the AI writes for you — the questions it asks about how you work, the wording it drafts, the reasons behind a score, the names of your audits — comes back in it. Clause numbers and the names of the standards stay as they are: an auditor asks for 8.4 by number in every country.
The app's own buttons and labels stay in English for now. A manual written in your language matters; a button marked “Print” does not.
These appear at the top of every screen, on your sign-in page, and on the cover of every copy you print. The logo is kept in your own database, so it is covered by the same backup as your manual and goes nowhere else.
Everyone has their own login and their own role. This is not the same list as the controlled copy holders: a copy holder receives the manual and never signs in, and does not use a licence seat.
Each active login uses a seat of its role. Deactivating someone frees theirs.
One manual per company. Each keeps its own revisions, copy holders and distribution register.
Clients never install anything: they are always on whatever is deployed to live. This page sets how often that happens, and records what has gone out.
| Step | What happens |
|---|---|
| 1. Build | Changes are made and tested on the development copy. Clients see nothing. |
| 2. Staging | git push origin main
deploys to the staging copy — same code, its own database. The tests run
first, and nothing restarts if they fail. |
| 3. Try it | Use staging as a client would. This is the only step that cannot be automated. |
| 4. Release | git push origin main:live.
Every database is backed up first, then live restarts on the new version. |
| If it goes wrong | git push origin
<previous>:live --force puts the old version back. |
The schedule below is a reminder, not a trigger. Nothing deploys on its own — a release is always a decision you make after looking at staging. Security fixes and anything that loses data go out the same day, whatever the schedule says.
Once a month means the first chosen weekday of the month — "the 1st" drifts across the week and lands on weekends. Every two weeks counts from the last live release, so a skipped slot does not reset the rhythm.