CIC Maker

Every food factory needs Cleaning Instruction Cards for its BRC audit – one per machine, telling an operator exactly how to clean it. Most sites make them inside their chemical supplier's software, which means they don't really own the documents that keep them audit-ready. I built CIC Maker so a site can make and keep its own, for free. It started as a way to draw the cards; it's now the control around them as well.

The problem

A Cleaning Instruction Card is a legal document. It tells an operator exactly how to clean one machine – the chemical, the dilution, the PPE, the steps, the checks. When an audit lands you have to produce the right card for every piece of equipment, current and correct.

The usual way to make them is the chemical supplier's system. It works, but the cards live in their software, on their terms, and changing supplier can take the work with them. Making a card by hand instead is slow and easy to get subtly wrong. And either way the harder question is left open: when someone edits a card, how does anyone know the copy already printed and hanging by the machine is the one being followed?

The solution

CIC Maker is a single web page that builds cleaning cards from your own data, keeps them under version control, and saves them where you tell it to. No account, no server, nothing leaves the machine.

• Draft until someone authorises it. Unfinished cards print with a DRAFT watermark across every page, and the tool names what's still missing before it will let one be authorised. It records who authorised it and at which version. Edit an authorised card and it becomes a new draft, so the copy hanging by the machine never changes underneath anyone.
• A change log that can't be rewritten. You sign in with your name and position – no password, no account – and every save, authorise, rename, archive and export is added to a log. Entries are appended, never edited afterwards.
• Five languages, and the parts that must not move don't. English, Polish, Romanian, Russian and Czech, with the switcher built into the exported file. Reference numbers, chemical names, site and equipment IDs are locked, so a document number can't get translated by accident. Anything not yet translated falls back to English, so a half-translated card still prints.
• Your data, in your folder – or no folder at all. Areas, chemicals and methods come from plain CSV files you control, and the app reads and writes to a folder you pick. Or connect nothing and still build, preview, print and download.
• What actually goes on the card. 21 section types, from the cleaning steps to electrical isolation and equipment fault reporting, each one reorderable, resizable or hidden. 149 pictograms for PPE, chemicals and controls, with every cleaning tool drawn in four utensil colours, so a red brush prints red. Photos cropped in the browser, with pins that also come out as a numbered point table.

What changed

A site can author, authorise, print and keep its own cleaning cards without paying for or depending on anyone else's software – and it keeps a record of what was issued, by whom, and when. It's free to use for any purpose, commercial included, and the source is there to read.

It works fully offline with no account and no server, and its security policy means it can't call out even if something in it tried. Writes are crash-safe: a bad save rolls back, and the tool recovers on reopen. Nothing is hard-deleted – delete archives a card, and archived cards restore. Exports are self-contained, with photos baked in, so a card re-opens identically on a machine with no data folder attached, and an exported card imports straight back into an editable one. It ships with a complete worked example on a made-up factory, so you can read a finished card before you build your own.

What I want to build next

A cleaning card names a chemical and a strength, and both of those come off the safety data sheet. Checking one against the other is the kind of slow, fiddly job that gets done properly the first time and skimmed after that, so a card can hang on a wall for a year specifying a dilution the data sheet doesn't support. I want the tool to read the data sheet itself and say where the card disagrees with it.

The second one is propagation. Change a cleaning method today and every card using it has to be found and edited by hand, which is how outdated printouts end up surviving on the line. The method should be the master and the cards should follow it.

Past those two, the same kind of reading – a language model over the card and the paperwork behind it – would take the smaller jobs: checking a finished card against what BRC actually asks for, rewording one that reads badly, and translating past the five languages I've done by hand. None of it is built. It's where the tool goes next, not what it does today.