Quality is where a business that makes or receives goods keeps its QC and QA: what good looks like for each item, the checks made against it, the stock held until it passes, what went wrong and what was done about it, and the procedures the floor works to. It opens on Today, made for a tablet on the floor: what to check now, what is on hold, the open non-conformances and CAPAs, the SOPs waiting for your signature, the records filled in today, the changes waiting for an approval, and the deviations in effect, waiting or being investigated. Its other views are in groups, each with a second row: Checks (inspections and specs), Issues (holds, non-conformances, deviations and CAPAs) and Documents (the SOPs' procedures, who signed what and the records, the changes, the standards and the templates). Each group opens on the view last open in it.
Turn it on
An owner switches Quality on in Inventory, Setup, Quality and SOPs, or in Admin, Modules. It needs Inventory. Quality then shows in the menu beside the other sections. It cannot be switched off while anything is on hold: release or close the holds first.
SOPs have a switch of their own beside it (10/07/2026), so a salon keeps its procedures and their read-and-sign without specs, inspections and holds. On by themselves they are a section named SOPs; with Quality on too the section is Quality and SOPs. A business that already had Quality on keeps its SOPs on. An SOP read and signed also completes a training that asks for it (see Training and certifications).
Two switches on each login (under Settings, Logins) say who does what:
- Quality records: inspections and checks, holds by hand, non-conformances, CAPAs and their actions, deviations and the lots and runs they touched, drafts of specs and SOPs and the record forms in them, and the records filled in and their second checks. Every login has it unless an owner turns it off.
- Quality release decides, and signs: approving a spec or an SOP, releasing a hold, deciding what is done with a non-conformance, closing a CAPA, voiding a record, approving a planned deviation and closing a deviation. Owners have it; an owner gives it to the QA lead.
A signed decision is signed by typing your own name as the team knows it. The name, the time and the decision are kept with the record and in the activity log.
Specs
Under Specs, each item gets a spec: its tests and when it is checked.
- A test is a number with its limits (pH 5.0 to 5.8, a fill weight of at least 148 g, micro at most 1,000 CFU/g), with a unit, a target and how it is tested; or a check against a written standard (appearance: smooth off-white cream, no grit or separation; odor: as the standard).
- A checkpoint says when it is checked: at receiving (and whether the vendor's certificate of analysis is read against it), during the run at a step you name (on the item's own run, or on the run that makes its bulk, and again every so many minutes), or before release. Each says its sample: a set number, a share, the square root of the containers plus one, or every one. Receiving and release can hold what they cover until it passes.
A spec is written as a draft, then approved with a signature by a person with Quality release. It is in effect at once; the version before it is superseded and kept as it was, so every inspection says which version it was made against. A change is always a new version.
Inspections
Inspections come due by themselves:
- At receiving: when a delivery of an item whose spec checks it at receiving is received, its receiving inspection comes due, with its sample, and what came in goes on hold until it passes. With the COA read, the inspector types what the COA says beside what was measured, and the lot the COA names: a COA for another lot fails the inspection.
- During the run: the checks a run on today's schedule asks at its steps show on Today, as many times as the run's length asks. They are recorded as they are made.
- Before release: when a run's finished goods come back, the batch's release inspection comes due and its lot goes on hold. An item that is not tracked by lot is inspected but cannot be held; turn on lot tracking to hold each batch.
Each finding is judged against its limits as it is typed: pass, fail for a check, or out of spec for a number outside its limits. One failed test fails the inspection; a failure holds the lot or the delivery it covers, and it waits on Today until it is written up. Inspections, Check a delivery makes a delivery's checks due when it came in before its items had a spec.
Holds
A hold is on a lot, wherever its stock is, or on what one delivery brought. Held stock is never picked, sold, shipped, sent to a maker or used in a run: the register, orders, pick lists, transfers and production each refuse it in a sentence that names the hold. It still counts as on hand, and as not available (see What the stock numbers mean).
A hold is made by itself while an inspection is due or after one fails, with a non-conformance, or by hand under Holds, Put on hold. It is released only by a person with Quality release, with a signature, once no inspection is due on it and its non-conformance is decided; after a failure, a note says why it is released. A hold closes by itself when a non-conformance writes off all of its stock. Every hold, release and closing is in the activity log.
Non-conformances
Write one up when something is not as it should be: a failed lot, a delivery not as ordered, underfilled bottles, a complaint. Say what, where it was found, how much and how serious. Written up from a failed inspection or a hold, the item, lot, delivery, run, vendor and hold come with it.
A person with Quality release decides what is done with it, and signs:
- Use as is: the hold is released with the decision, which says why.
- Rework: once it is reworked, say what was done; a re-check against the spec comes due, and the hold waits on it.
- Scrap: the stock is written off as failing a quality check, and the hold closes.
- Return to the vendor: written off the same way, with a claim against the vendor for what it cost under Inventory, Losses.
It is closed once what was decided is carried out, its re-check recorded and its hold released.
CAPAs
A CAPA, a corrective or preventive action, finds why something went wrong and makes sure it does not happen again. It answers one or more non-conformances, or stands alone. It carries the problem, the root cause once it is known, an owner and a due day, its actions (each with an owner and a day, ticked done), and the plan for checking that it worked. Once every action is done, record the check and whether it worked; if it did not, add more actions. A person with Quality release closes it with a signature once it is checked and found to work.
SOPs
Under SOPs, each procedure is a controlled document with a number (SOP-001), an area, an owner and how often it is reviewed. A version is written as a draft (headings with #, steps with 1. 2. 3., lists with a dash), sent for review, and approved with a signature by a person with Quality release, or sent back with what to change. Approved, it takes effect that day and the version before is superseded.
Say who must read it: everyone, a role (owners, admins, managers, the front desk, staff), or named people. Each of them sees it on Today to read and sign, and signs again whenever a new version takes effect. Who Signed What shows each person against each SOP in effect: signed, a new version to sign, or never signed.
The SOP builder
Write an SOP asks what to begin from: a blank page, one of four starters (a general procedure, cleaning and sanitation, operating equipment, receiving and inspection), or one of the business's own templates. A starter puts its headings in, and its guidance shows beside each section while you write. The guidance is never written into the SOP: an SOP holds only what its writer wrote.
The text is written section by section. Each heading starts a section; rename it, move it up or down, add another, or take one out once nothing is written under it. Edit as text writes the Markdown itself (headings with #, steps with 1. 2. 3., lists with a dash, and two stars on each side for bold), and an SOP written before the builder reads exactly as it did. A draft is saved whole: if someone else saved it after you opened it, you are told when, and choose to save yours over it or read theirs first.
Compare two versions shows any two side by side, or one above the other on a phone: each line taken out and added, and inside a changed line the words that changed. A version sent for review opens compared with the version in effect, so the reviewer reads what changed before approving it. Each version also downloads as a PDF in the business's brand, with its number, version, where it stands, who approved it and a page footer on every page. A draft or a version in review says so on every page and ends with what changed.
Periodic Review on an SOP's page says when its next review is due. Reviewed: no change needed records the review, and the next one is counted from that day. It needs a change records what was found and starts the next version with it as the reason (or adds it to the version already open). Reviews due this month and late ones show on Today, and above the procedures in SOPs' own view. Change its details sets how often it is reviewed.
SOPs It Relies On names the other SOPs an SOP depends on, and each shows the ones that rely on it too. An SOP's code written in its text, such as SOP-004, opens that SOP when it is read. Make a template from its sections turns an SOP's headings into a template, each with a line of guidance you write; Templates, beside the procedures, keeps the business's templates and shows the starters. A template is archived, never deleted, and the SOPs begun from it keep its guidance.
Records
The logs and checklists an SOP calls for are its record forms: a tank cleaning log, a line clearance, a daily sanitation sheet, a batch sheet. On an SOP's page, Records It Calls For lists them.
- A form is part of its SOP. It is written into the SOP's draft (Add a record form to version 2) and takes effect when that version is approved. To change one, start the SOP's next version: its forms come into it as they are, and Change it in version 3 or Take it out of version 3 changes only the version being written, while the version in effect keeps its own. A version in review shows each form as new, changed (and how), or taken out, so the reviewer approves the forms with the text.
- What it asks. A name, a line saying when to fill one in, what each record is about (a lot, a production run, a room, chair or machine, a location, or nothing in particular), whether a second person checks each record, and its fields. The fields are the form builder's own: a number, yes or no, a choice, several choices, a line or a paragraph of words, a date, a scale, a heading and an explanation. A record is signed by typing your name, so pictures, drawings and signature boxes stay with client forms.
- A number's limits. Give a number its lowest and highest allowed (rinse water 60 to 80 °C, sanitizer 200 to 400 ppm). A reading outside them is never refused: it is marked as it is typed, the record counts it, and the person says in the note what was done about it.
Fill one in, on the SOP's page, the form's page or Records, opens the form as the SOP's version in effect has it. Say what it is about, answer it, and sign by typing your name. The record keeps the form's version and the SOP's version it was done under, so it reads the same after the SOP moves on, and the name of what it was about as it was then. A form that asks for a second check leaves the record waiting until someone other than the person who filled it in checks it and signs.
A record is never changed or deleted, by anyone. A mistake is voided by a person with Quality release, saying why and signing, and the record is filled in again; the voided one stays on file, marked.
Records, beside the procedures, is what an auditor reads: every record, newest first, filtered by form, by days, by who filled it in, and by where it stands (waiting for a second check, out of limits, voided). Each one opens with the version it was done under. Download as a spreadsheet gives them with a column for each field of the form, or, for several forms, each answer beside what was asked. Today counts the records filled in today and the ones out of limits this week, and lists those waiting for a second check. A production run's page and a lot's stock tag say how many records are about them, with Open them.
Standards
Under SOPs, Standards keeps the standards the business works to, such as ISO 9001:2015, OSHA 29 CFR 1910, HACCP or a state board's rules. Add a standard by its name (common names are offered as you type) and, if the floor calls it something shorter, a short code. Then add the clauses of it the business answers to: each one's number as the standard numbers it (7.2, 1910.1200(h)) and a short title in your own words. The app keeps no standard's text, so the clauses are always the business's own reading of it.
For each clause, Change what serves it picks the SOPs, the trainings and the record forms that answer it. You can also say it from the other side: an SOP's page, a training's page and a record form's page each have Standards It Serves, with Change the clauses it serves.
A standard opens on its coverage. Each clause shows its SOPs, with where each stands (in effect, in review, its review due, how many of its readers signed), its trainings, with how many of the people who must have each are current, and its record forms, with how many records are kept and the day of the last one. A clause nothing serves says so. Download as a spreadsheet gives the same coverage, clause by clause. It is the business's own map of the standard, not an auditor's finding.
A standard or a clause is archived, never deleted. It leaves the coverage and keeps what served it, for when it is brought back. Under Training, the matrix (by person or by job) can be narrowed to one standard: it then shows only the trainings that serve its clauses.
Change control
With Quality on, Changes keeps every change to how the work is done: a new version of an SOP or a spec, a new piece of equipment, another material or supplier, a process run another way. Open a change writes one as a draft, numbered CC-001 and up. It says:
- why it is made and what changes;
- what kind of change it is: a document, a process, equipment, a material or a supplier;
- how far its impact reaches and how risky it is, each low, medium or high, with a line in words;
- its owner and the day it is planned to take effect.
What It Changes names the SOPs, items' specs, record forms and trainings it touches, or something said in words. An SOP's page and a spec's list the changes that name them, with Open a change for it. For an SOP, Start its next version begins the version the change makes, with the change's number as its reason, and Write it down for this change takes a version already being written; an item's draft spec is written down the same way. A record form changes with its SOP's next version, so name that SOP too. Under a training it names, the people due for it are listed, with Book a session for them.
Who Approves It names the people, and the jobs, whose approval it needs; anyone who holds a job named signs for it. Send for review asks each of them, and each approves it or sends it back with a note, signing by typing their name. Quality's own approval, by a person with Quality release, is always the last. A change sent back goes to its owner, who changes it and sends it again: each sending is a round of review, and every approval and rejection of every round is kept. While it is in review, its owner or a person with Quality release can take it back to change it.
Approved, a change waits for its day. One that names SOPs or specs is in effect by itself once each version written for it is approved, on or after its day; one that names none is put into effect with Put it into effect once the change is made. Tasks says what is to be done for it, who does it and by when: retraining, new labels, the old forms taken off the floor. Once it is in effect and every task is done, a person with Quality release closes it, signing. A change not yet in effect can be canceled, saying why: it stays on file, marked, and the versions written for it are free for another change.
Today lists the changes waiting for your approval, the ones waiting for Quality's (to a person with Quality release), and the ones whose day has come.
SOP and spec versions take effect only through an approved change is the setting, under Inventory, Setup, Quality and SOPs, turned on or off by a person with Quality release. It starts off. With it on, a second or later version of an SOP or an item's spec is approved only as part of an approved change that names it, and no earlier than the change's day. A version sent for review before the setting was turned on, or a spec drafted before then, stays approvable as it was, and a first version never waits for a change.
Deviations
A deviation is a departure from an SOP, an item's spec, or something said in words, numbered DEV-001 and up, under Issues, Deviations. There are two kinds:
- Plan a deviation before the work departs on purpose: a second mixer while the first is repaired, another supplier's lot of a material for a few batches. It says what it departs from (an SOP, kept with its version in effect, an item's spec, or something in words) and which step, limit or instruction; how the work will depart and where; its first and last days, and if you like at most so many lots or runs; how it is kept in hand; its impact and its risk, each low, medium or high; and its owner. It starts as a draft. A person with Quality release approves it, signing, no later than its first day, and the version of its SOP or spec in effect that day is the one it departs from. It is in effect through its last day while it has lots or runs left, and lapses after. One lasts a year at most: a change made for good is a change, under Changes.
- Write up a deviation once the work has departed without a plan: a step skipped, a batch cooled for less time than its SOP says. It is open from the start, with the day it happened and the day it was found, what happened and what was done at once. Write the investigation says what was looked into and its root cause.
Lots and Runs It Touched names the runs and the lots (an item and its lot) it covered; a planned one names no more than it holds for, and none once it lapses. Where It Leads opens a non-conformance from it when product is affected, and a CAPA when the cause is in the system: each keeps the link for good, and its own page says which deviation it came from. Link one already open links a non-conformance or a CAPA written up before.
A person with Quality release closes it, signing: a planned one once its first day has come, an unplanned one once its investigation and root cause are written, and either once every non-conformance it led to is decided and every CAPA it led to has its actions. A planned one before its first day, or one written up by mistake, is canceled by its owner or a person with Quality release, saying why; it stays on file, marked, with what it was linked to.
An SOP's page and a spec's list the deviations from them, with Plan a deviation from it. Today lists the planned deviations in effect, those ready for Quality's approval (to a person with Quality release), the unplanned ones being investigated, and the planned ones lapsed and waiting to be closed.
Best practices
- Write a spec for each finished item and for each raw material that comes with a COA before anything else: inspections come due, and stock is held, only for items with a spec.
- Keep each limit to what can be measured where it is checked. A test that needs a lab, such as micro, belongs to the check before release, and the batch is released when the result is back.
- Give Quality release to one or two people, not to everyone: a signed release means someone answered for it.
- Write up every failure, even a COA that names the wrong lot. The non-conformance keeps what was found, what was decided and who signed it.
- Close a CAPA only once the check shows it worked, and change the SOP it touched in the same week.
- Keep an SOP's new version in review for days, not weeks: people sign the version in effect, and a version waiting in review is one nobody is following yet.
- Do the periodic review even when nothing needs to change, and say who read it through in the note: "no change needed" with a name and a day is what shows the procedure is still how the work is done.
- Map each standard clause by clause before an audit, and give every clause at least one SOP, training or record form. A clause nothing serves is the first question an auditor asks.
- Give every number on a record form the limits it must fall within, and ask for a second check on the records that release product or clear a line. A reading out of limits with what was done about it is a record an auditor trusts; a log with no limits says nothing.
- Void a record only when it is wrong, never because the reading was bad: a bad reading recorded honestly, with what was done about it, is what the record is for.
- Turn change control on before an audit asks why each version changed, or once more than a few people write SOPs: from then on every new version says why it was made, who agreed to it and the day it took effect.
- Name the people who do the work among a change's approvers, not only managers: the person who cleans the tank sees what a new procedure misses.
- Plan a deviation rather than write one up after: approved before its first day, it shows the departure was weighed and kept in hand. Name each lot or run made under it as it is made, so each one's record says so.
- Write up an unplanned deviation the day it is found, even when no product is affected, and find its root cause before closing it: the same small slip, written up three times, is what a CAPA is for.
Programs and the assistant
The API's Quality part does what the section does (with the SOP builder's comparisons, reviews, links and templates, the record forms and records, the changes with their approvals and tasks, and the deviations with their lots, runs and links), and announces inspection.failed, lot.held, lot.released, ncr.opened, capa.closed and sop.effective to webhooks. A signed decision made through a key is signed by the key's maker, who needs Quality release, and waits for a person's approval under Settings, Approvals unless an owner sets it to Do it there. A record filled in through a key is signed by its maker too, who needs the Quality switch; an assistant asks a person before it fills one in, checks one or voids one. A change approved through a key is approved by its maker, who must be one it names or hold a job it names; Quality's approval and closing it take Quality release; an assistant asks a person before it approves, closes, cancels or puts a change into effect. A planned deviation's approval and a deviation's closing through a key are signed by its maker, who needs Quality release; an assistant asks a person before it approves, closes or cancels a deviation. The assistant reads Quality as Today shows it, or one item's spec, inspections and holds, when Quality is on and your login has its switch.