If an activity is not documented, it is considered not performed.
The closing line of the universal standard, written on 19 July 2026, before any of the software that would eventually enforce it.
Closer to a quality management system than a startup handbook.
That is the document's own assessment of itself. Every standard has the same seven parts, which is what lets somebody audit against it rather than interpret it.
Clinical
Consultation
Collect complete and accurate information before any recommendation. Do not recommend treatment before assessment; do not guess missing information; do not promise outcomes.
Assessment
Create a documented understanding of the patient's current health status. Do not skip assessments, make assumptions, or alter assessment records.
Treatment
Deliver safely and according to the approved plan. Do not deviate, do not perform unauthorised procedures, do not leave treatment undocumented.
Continuity
Follow-up
Monitor progress and maintain continuity. Every patient has an updated progress record and a defined next step.
Operations
The stated outcome: daily operations remain consistent regardless of personnel.
Outward
Marketing
Do not promise cures. Do not guarantee results. Do not use misleading claims. Do not create fear to influence decisions.
The document also explains its own layering: each required action can later expand into its own procedure without changing the standards document itself. Principles first, execution second — so the foundational layer stays stable while the operational one is allowed to churn.
A standard that depends on everybody remembering it is a hope.
| Written standard, 19 July | What the system does about it |
|---|---|
| Do not recommend treatment before assessment. | No care plan can exist without an assessment recorded against the encounter, and the four-step encounter has a progress rail that will not let a step be skipped. |
| No treatment begins until the patient understands the plan. | Findings are rendered for the patient and the acknowledgement recorded. The server refuses to raise an order while that acknowledgement is missing — the server, not the interface. |
| Record every completed session. | There is no path to a completed session without a recorded patient response. Documentation is not a step after the work; it is how the work finishes. |
| Do not alter assessment records. | Signing an encounter makes it immutable — a medico-legal decision taken early because it is far cheaper than retrofitting one. |
The document's phrase is if an activity is not documented, it is considered not performed. In the software, an activity that is not documented cannot be marked performed at all.
The standards themselves are ordinary; any competent clinic could write them. What is unusual is that the gap between the standard and the behaviour was closed by removing the non-compliant path.
One door for everybody who is not a patient. The role decides what opens.
| Role | What it reaches |
|---|---|
| Reception · Therapist | The diary, patients, check-in, sessions, desk payments. A therapist cannot record a payment — the hardening audit proved they previously could, and proved the fix by invoking the action directly. |
| Clinician | Assessments, encounters, care plans. The clinical record is theirs to write and to sign. |
| Manager | All of the above, plus collections, insight and the enquiry pipeline. The manager runs the day. |
| Owner | Everything, plus the back office — the only role that sees what colleagues are paid. |
| Community partner | Their own code, QR and funnel. No patient details at all, confined by a middleware allow-list rather than by hidden links. |
Pay is owner-only for a stated reason that is not hierarchy: what a colleague is paid cannot be un-shared once seen. A manager who already holds collections and insight does not need it to run the day, so the access that cannot be reversed is the one withheld.
Refusing service was redesigned to need two people — one to raise it, another to approve — applied quietly, with no accusation in the message.
A grid that assumes everybody turned up is recording an opinion, not an observation.
- Before
- The console could always answer what came in. Nothing recorded what went out, so the only question that matters at the end of a month could be answered from a notebook and not from the system.
- What forced it
- A back office had to exist. The two interesting decisions inside it are both refusals to be clever.
- The decision
- Attendance has three states, not two: present, absent, and not yet marked as its own value rather than a default that reads as present. And approving leave does not mark the days — plans change, and attendance should follow what happened rather than what was agreed.
- What it changed
- One ledger carries rent, maintenance, utilities, vendors, supplies, marketing, statutory payments and salaries together. Salaries deliberately included, because a salary is money out like any other and two ledgers is one you forget to add.
Pay is eventually calculated from the attendance grid, which is the whole argument: a convenience default there is a quiet claim about somebody's day that nobody actually made.
They can tell you their poster is working. They cannot tell you who read it.
- Scans of their own code
- Bookings
- Attendances
- Programme starts
- Money owed, and settlement history
- A name
- A phone number
- A reason anybody came in
- Any part of a clinical record
Paying for medical referrals is a different thing, legally and ethically, from paying a gym for introducing its members. The difference is not the money — it is whether the person being paid can influence clinical judgement.
The reason was written into the module's own documentation, in full, for a stated purpose: in two years somebody will propose showing partners a name just to help them follow up, and the reason that is not allowed needs to be sitting in the file rather than in one person's memory.
An operating model on paper and in code.
- Six standards, each with required actions, required behaviour, do-nots, escalation triggers and an expected outcome
- A capability matrix in one module that mirrors what is published to staff — and states that if the two disagree, the code is authoritative and the page is wrong
- Two-person refusal, owner-only pay visibility, and a partner role confined by middleware rather than by interface
- Nobody was observed working. No shift was watched, no member of staff interviewed, and no audit against the standards has been run
- The partner programme has never run: no partner had been signed and none had been paid through the system
- Whether the standards are followed in the building is unknown; the only claim here is about what the system permits
Daily operations remain consistent regardless of personnel.
Nirmalkaya · one of six perspectives on the same project