Smart HMS
Overview
A health-and-safety system a business owner can set up by talking to it.
Details
At a glance
- Project type
- HSE and HR platform with a voice assistant
- My role
- Defined the product and its rules, designed the interface and the assistant, and implemented the system.
- Category
- Systems
- Status
- In development2026
What I did
- Set the governing principle that AI drafts and a rule engine decides
- Built the verified legal reference the rule engines cite
- Designed the spoken onboarding and the orb that carries it
- Implemented the application, the multi-tenant data model and the voice pipeline
Built with
- TypeScript: Application code across the stack
- Next.js: Application framework and server rendering
- Supabase (PostgreSQL): Multi-tenant database, authentication and row-level security
- Claude Sonnet: Drafting documents, and the language step inside the spoken conversation
- LiveKit: Carrying live audio between the browser and the assistant
- NB-Whisper: Norwegian speech recognition
- Azure Speech: The Norwegian voice the assistant answers in
- Three.js: The orb that reacts to the microphone and the reply
Next project
Virksom
The need
A Norwegian business owner with a few employees does not think in categories. They do not wake up wanting a risk register, a safety representative and a chemical inventory. They think: I have people working for me, what do I need in place so that I am not doing something wrong?
Existing systems answer that with a folder of blank templates and a list of things to fill in. The work stays with the owner, who is the one person in the company with no time and no training in employment law.
The idea
Ask the owner questions instead. Out loud, in Norwegian, the way an adviser would: what do you do, how many people, where do they work. From those answers the system writes the documents, builds the risk register, schedules the tasks and shows how far along the company is.
That only works if the owner can trust what comes out. So the product is built around one rule that is never bent: the assistant drafts, and something else decides.
Decision
AI writes the words, a rule engine decides the requirement
- Context
- A system that tells a Norwegian employer what the law requires of them is answering a question with a right answer. A language model that is right most of the time is the wrong instrument for it.
- What I decided
- A verified reference of Norwegian employment and safety law sits under the product, with the thresholds cited to their source. Deterministic engines read it and decide what a given company must have. The model only interviews, drafts and explains, and a guard blocks any wording that would claim a document is legally approved.
- Trade-off
- The assistant cannot improvise around a case the rules do not cover, and every new area of law has to be entered and verified by hand before the product can speak to it. That is slower, and it is the only version of this product worth shipping.
What the owner sees
One status, not a menu: how much is in place, and the single next thing to do. As documents are approved the status rises, and the tasks attached to them close on their own.
Underneath it is the whole of an employer's obligations: documents, risk, employees, chemicals, courses, absence, holiday, the safety representative, the working-environment committee. But the owner is never asked to navigate it. They are asked to approve one thing at a time.

The assistant
The way in is a conversation. The owner presses one button and talks; the assistant looks the company up in the national register, confirms it by name, asks what it needs to know, and then says out loud what it is creating and what it recommends.
The orb is the assistant's face. It moves on the owner's own microphone level while they speak and on the reply while it answers, so it is always clear which of the two is holding the conversation, a state a spoken interface has to make visible, because there is nothing else on screen to read.

How it works
- The voice pipeline is assembled from separate parts rather than a single speech-to-speech model: audio over LiveKit, Norwegian recognition by NB-Whisper, the language step on Claude Sonnet, and a Norwegian voice from Azure. Keeping them apart leaves a seam in the middle of the conversation where the guards can run.
- Audio is discarded. Only the transcript is kept, and personal identifiers are scrubbed from it before it is stored.
- A verified reference of Norwegian law, cited to Lovdata, Arbeidstilsynet and NAV, is the source the rule engines read. The model does not decide requirements.
- Everything the AI produces is a draft until the owner approves it, and every version is kept and audit-logged, so any document can be traced back to who approved which wording and when.
- Facts are entered once. A name, a role, a workplace or an organisation number captured in one place pre-fills every contract, routine and record that needs it.
- Multi-tenant PostgreSQL with row-level security, roles and an audit log; uploaded files sit in private storage reached only through short-lived signed links.
- A photograph of a chemical label is read by the model and turned into a pre-filled entry for the chemical inventory.
- The interface is Norwegian and English throughout, and employees confirm what they have read through a single-purpose signing link rather than an account.
Where it stands
The core loop runs end to end: a spoken conversation produces a company profile, which produces documents, risks and tasks, which the owner approves and which move the status. The voice pipeline is live and the employer-obligation engines cite verified law.
It is not launched. The deviations and settings screens are still placeholders, national-identity sign-in is not integrated, and the domain is not yet wired up. What the project has settled is the harder question: where a language model belongs in a product a business is held accountable to, and where it does not.