Internal build status . not shown to a prospective agency
Vardium, as built
A security operations layer for Singapore security agencies. Officers capture checkpoint proof and incidents from the phone already in their hand. A supervisor sees it land on one screen. The agency keeps a defensible record of coverage, evidence and compliance. This page is the engineering record: what renders, what each surface does not do, and what is deliberately not built. The polished, guided version of this same product is at /walkthrough.
The rule the whole design serves
No server-issued receipt means not submitted. The officer is told to retry or call it in. The officer is never left inferring success from silence.
Surfaces that exist
Every card below is a route that renders and reads the live database. What each one does not do is printed on the same card, not hidden further down the page.
Officer/officerThe phone screens: your record, and reporting an incident.Real: Reads and writes the live database under the same tenant isolation as every other surface. Photo, voice note and the officer's own words. Held on the phone first and marked sent only when the server returns a receipt. Four languages and a text size control that scales the whole screen.Not: A signed-in officer is authenticated by a sign-in code and a PIN at /officer/sign-in. This surface is still reachable without that on the demonstration deployment, where a signed cookie names the device and checks no credential, and every screen reached that way says so on the page.Checkpoint tags/scanIssue a signed checkpoint tag, then scan it.Real: A tag is signed, expires with the shift, names one officer and one checkpoint and works once. Only its hash is stored. Scanning at /scan/[token] checks the signature, the expiry, the officer and the replay.Not: Issuing is a supervisor action and this board has no sign-in of its own, so it is restricted to the demonstration agency and needs a named device.Supervisor/supervisorSign-in requiredOne screen: live feed, incident review, coverage.Real: Sign-in is at /supervisor/sign-in, throttled per account and per address, and the role is checked again server side inside every route the page calls. The no-show watch shows what the sweep detected on its own, the callout it opened, who has been asked, who declined and the countdown to escalation, beside whether the sweeps are actually running.Not: Supervisors and managers only. An officer or a client account is refused here by requireRole on the server, on every request, whichever door it signed in at.Compliance/complianceFifteen regulatory obligations with a live status each.Real: Every status is computed from this agency's rows at request time against a versioned rule set. Nothing is hardcoded and nothing is cached. Where an input is missing the row says so rather than showing green. GET /api/compliance/export produces the inspection pack as JSON.Not: Indicators, not filings. No wage is computed and nothing is submitted to any authority. Retention is now enforced nightly for message records by the retention purge, which reads the same eighteen month period this console reports. Evidence itself is append only at the database and cannot be deleted by any job, so media past retention is counted and reported rather than removed.Reporting/analyticsCoverage by site, fill rate over time, hours by officer, and the exports.Real: Every figure is counted from this agency's own rows at request time, and a rate with no shifts behind it renders as words rather than as zero per cent. Payroll hours export as CSV, raw hours and licence grade only, with no wage rate applied anywhere. The structured record export at /api/export/record is a regulatory obligation on every package and works on the day an agency leaves. /analytics/officer-text puts an English rendering beside the officer's own words, never in place of them.Not: Coverage, fill rate, payroll and translation are professional capabilities and service-level exceptions are a command capability, so a cheaper package sees a panel saying which feature it is and what package includes it. No translation service account is configured, so officer text is shown as written with the English column empty and the reason printed.Client portal/clientSign-in requiredWhat a client sees: completed rounds, approved reports, service history.Real: A separate door at /client/sign-in for the named contacts at each client. What a contact sees is narrowed to the sites that person was granted, by Row Level Security rather than by a filter in a query, so a pasted id from another client returns nothing rather than being refused. It produces a branded period report and a proof pack for one incident, both printable, both carrying the agency's name and never this platform's. A live test proves the isolation by handing one contact another client's real incident id.Not: Read only, and deliberately narrow. No officer is named anywhere on it or in anything it produces, there is no live location and no roster. A report is produced when a client asks for it: nothing emails one on a schedule, because no email account is connected. Only approved records appear, so a report still under review is counted and not shown. Service-level exceptions are a command capability and the seeded agency is on professional, so that panel says what it is and shows no data.Relief/reliefAn uncovered post, the callout, and the record it leaves.Real: Detects an uncovered post, screens the standby list against the eligibility rule, composes the ask in the officer's own language, takes the first acceptance and escalates with the full contact record. /relief/officer is the same record as the officer sees it.Not: No messaging account is configured, so no message reaches a phone. The send path, the inbound webhook and its signature check are built and run on every message; replies can arrive from a phone or be typed in, and both take the same path. Detection and escalation now run on a clock as well as by hand: a sweep opens the callout for an overdue clock-in and a second sweep hands an unfilled callout to a named supervisor after the configured wait.
Not built
There is nothing to open here. This list exists so that nobody has to discover any of it by clicking and finding a screen missing.
- Two of the six scheduled jobs
- Four jobs now run on a clock: the no-show sweep every minute while a shift is on, the escalation sweep every five minutes, the retention purge nightly and the client report nightly. Every run writes a row, every failure is on the job's own row, and a job already running is refused by the database rather than started twice. Two are registered and paused and say so. The compliance expiry sweep has no runner on purpose, because the compliance console computes those indicators when it is read and a second copy on a clock is a way for the two to disagree. The seed itself is manual. One further limit: evidence is append only at the database, so the retention purge deletes message and run records and can never delete media. It counts the media past retention and reports it instead of removing it.
- Scheduled delivery of the branded client report
- The client portal, the branded period report and the proof pack are built and are at /client. What is not built is delivery: nothing emails a report to anybody, because there is no email account connected to this build. The nightly job composes a plain-text daily digest into the outreach record and transmits nothing, and the printable period report is produced when a client asks for it in the portal. A client who wants one every month has to open the portal and ask.
What the data behind these screens is
One seeded agency, Sentinel Guard Services Pte Ltd, with three sites, six posts and twelve officers, on the Command package. Every officer, site, shift and incident in it is invented. None of it is a real agency, a real person or a real client, and no figure on any screen should be repeated to a customer as a result. The database itself is real: every read and write goes through Row Level Security under the same tenant isolation a production tenant would get, and tests prove that isolation against the live database rather than asserting it.
Architecture, data model and the per-surface notes on what is and is not built are in /docs in the repository.
v0.9.10 . WiBiz (wibiz.ai)