A compliance engine that can be asked what will be true next month
Asbestos abatement in British Columbia is governed by dates: licence expiry, worker certificates, notice windows measured in hours. Clearance is a working prototype of the workflow layer that tracks them - built to test the idea, not to sell it.
Visit the working prototype- Zero
- Jurisdiction rules in schema
- All of them live in packs
- HTTP 422
- Close-out gate
- Server refuses, and says why
- asOf
- Evaluation
- Engine never reads the clock
- Sourced
- Every rule
- Verified or flagged an assumption
The challenge
A WorkSafeBC-licensed abatement contractor has to hold a current licence, put certified workers on the right class of job, file Notices of Project inside statutory windows before work starts, get air clearance to pass before closing out, and keep waste manifests. Miss one and the job is a stop-work.
Today that is tracked in Outlook reminders and a folder of PDFs. Document stores exist and are well served; what is missing is anything that knows the rules and says no.
The honest problem underneath was different again: the previous project in this founder's history was built first and validated never. Writing more code was the wrong instinct.
What we did
So the build was scoped deliberately as a prototype - something to put in front of a contractor on a validation call, so the conversation is about a screen rather than a description. No build step, no front-end framework, roughly a thousand lines of vanilla JavaScript that renders and posts but never decides. Someone can read all of it in an afternoon and judge whether the idea deserves a real stack.
Two decisions carry the design. First, the schema contains no numbers - no 48, no 56, no 1095. It knows about licences, certificates, notices, clearances and manifests, objects that exist in every jurisdiction, while every threshold lives in a rules pack tagged either verified with its source or assumption. A second hazard is a new file, not a migration.
Second, the engine never reads the clock. Every evaluation takes an `asOf`, so the interface can be asked what will be true in forty-five days: the licence lapses, notices go overdue, warnings become stop-works. Nothing in the database changed - the engine was asked a different question. That property is also what makes the rules testable.
The server decides and the browser renders. Closing a job re-runs the engine and returns 422 with the list of blockers, so a job whose air clearance came back at 0.029 f/cc cannot be clicked past.
The outcome
It works, and it is deliberately not finished. It does not file anything with WorkSafeBC, does not store real documents, and has no authentication or multi-tenancy. Several rules are invented and are shown as assumptions on screen rather than hidden, because a compliance tool that quietly guesses is worse than no tool.
What it produced is a validation instrument. The next three actions on the project are all research - count the licensed contractors, establish whether notice filing has an API at all, and make fifteen phone calls - and the prototype exists to make those calls concrete.
We include it here because it is the clearest example of how we think about a product idea: build the least code that makes the hypothesis testable, mark every assumption, and be willing to stop.