Kora — Site configuration, policy & exceptions

Set at onboarding · Company A only · hospital may request change

Site shape

The topology is free. The node kinds are not. Every site is a tree built from five fixed kinds, so a leg is always (parent, child) and loss-by-leg reporting works at any depth without special-casing. Adding a floor substore later is a config change plus an opening deployment movement — never a migration.

Try it: switch between the three shapes. The tree, custody depth and the count of affected policies all change with it.

Node tree

4 nodes · 3 legs

          ▪ holds stock
          ▪ in-transit
          ▪ issue-out point, no balance
        

Node kinds

closed set

Kind	Stock	Custodian	Attests
WAREHOUSE	yes	Company A	yes
DEPOT	yes	Company A	yes
SUBSTORE	yes	either	yes
CONSUMPTION	no	—	receiver only
PROCESSOR	transit	vendor	yes

Sites never invent kinds, and never invent item types. Both come from Company A's central catalogue — otherwise the network grid and vendor scorecard become unjoinable across clients.

Depth 1

Counter only

No hospital participation. Ward figures attributed via collector + roster, labelled as attributed.

Depth 2

Floor substores

Hospital appoints floor custodians who hold balance and countersign. Full attribution.

Depth 3

Point of use

Cart-level accountability. Rare — mostly hotels with per-room service standards.

What this shape changes downstream

Shape A

Company A sets · hospital may request an exception

Policy sheet

Three enforcement levels, not two. Warn is the one that keeps this from feeling like another thing to do — most operational edge cases aren't abuse, they're Tuesday. Blocking them teaches staff to work around the app; recording them with a reason gives Company A the data to loosen or tighten later.

Try it: change any policy's enforcement. The consequence line below it rewrites, and setting one to forbid is what unlocks the exception-request flow for the hospital.

Policies · Sahyadri Nashik

8 policies · 1 forbidden

Enforcement levels

Allow — permitted silently. Nothing is recorded beyond the movement itself.

Warn — permitted, requires a reason code, surfaced in monthly reconciliation. The flow never stops.

Forbid — blocked at the point of action, with a visible route to request an exception. A dead end with no route is how you lose a client.

Defaults ship per site type — hospital, hotel, clinic — so onboarding is a review, not a blank sheet.

Warn-level reasons this month

from reconciliation

Reason	Count	Policy
Cross-depot cover during shift gap	14	lateral_issue
Ward emergency, no return available	9	one_way_issue
Count mismatch under tolerance	31	variance_tol
Soiled beyond wash recovery	6	condemn_value

14 lateral issues in a month is not abuse — it is a shift-coverage gap telling you the policy should probably be allow, or the rota should change. That is the argument for warn over forbid.

Deploy what is needed · skip what is not

Modules

Anything switched off does not appear anywhere in the UI — not greyed out, absent. A hotel should never see the words "infected linen" on any screen. But every module needs a defined behaviour when it is off, decided now rather than discovered in month three.

Try it: switch modules off and read the consequence that appears. Two of them are locked on above a value threshold — those are the ones where "off" silently corrupts the numbers.

Modules · Sahyadri Nashik

9 available · 7 on

Resulting deployment

what staff will see

Screens rendered

A hotel configuration typically drops to 4 modules and the app becomes a two-screen product. Same codebase, same ledger.

Why two are locked

Condemnation approval. Off means the supervisor self-approves write-offs. That is the drain that hides theft — so it is non-optional above a value threshold Company A sets centrally.

Rewash tracking. Off means stained returns land in clean stock and the laundry's return rate looks perfect while the depot starves. A site can only switch it off if it accepts a variance tolerance instead.

Hospital-owned · self-serve · no ticket to Company A

Staff roster

Company A owns the shape. The hospital owns the people. This is the one screen the hospital administers itself — add, suspend, reassign — because housekeeping turnover is high enough that a Company A approval loop would jam the whole system inside a month.

Try it: suspend a staff member. Their code stops working immediately; their historical attestations stay in the ledger forever, because the ledger is append-only.

Authorised to collect from Room C

7 active · 1 suspended

Name	Area	Shift	Code	Attestations 30d

Codes are issued by the hospital, never by Company A.

Capabilities

bound to node, not title

Roles are templates over capabilities. A new client wanting a title nobody has had before is a template, not code.

	issue	recv	attest	dispatch	condemn	approve
Depot supervisor A	✓	✓	✓	✓	✓	—
Floor custodian H	✓	✓	✓	—	req	—
Housekeeping H	—	✓	✓	—	—	—
Laundry driver V	—	✓	✓	✓	—	—
Regional mgr A	—	—	—	—	—	✓

A Company A · H Hospital · V Vendor. Employer matters: a movement with two parties from the same employer records, but does not count as attested custody transfer in loss attribution.

Two invariants no configuration can override

Every movement has two parties. Where they share an employer, the movement is recorded but flagged as internal — it moves stock without transferring custody.

Nobody approves their own condemnation. At any depth, in any configuration, in an emergency. This is the single rule that stops write-off becoming the exit route for shrinkage.

Flow · hospital raises → Company A decides → grant rides on the movement

Exception request

A forbid policy without a route to request an exception is a dead end, and dead ends are how a system gets abandoned. Here the block is real, but there is always a next step — and whatever gets granted becomes part of the record rather than a favour nobody can trace.

Blocked · lateral issue

Room C-North · 14:08

Requested40 bedsheets, 40 pillow covers

CollectorS. Pawar · Housekeeping

Assigned areaFloor 6 · served by Room C-South

Policylateral_issue = forbid

Room C-North cannot issue to Floor 6. Floor 6 is served by Room C-South. Company A has set cross-depot issue to forbidden at this site.

The block always offers two ways forward. Neither of them is "give up and take the linen anyway", which is what happens with a paper register.

Why this is forbidden here

Sahyadri Nashik runs two depots with separate par calculations. Lateral issue makes each depot's consumption rate meaningless, which breaks days-of-cover and therefore breaks emergency allocation.

At other sites the same policy is warn — the movement goes through with a reason code and shows up as its own leg in reconciliation.

Same code, different posture. That is the whole argument for policy-as-data rather than policy-as-if-statement.

Request an exception

A. Kulkarni · Hospital admin

Policy

Scope

Reason

Attach

The blocked attempt is attached automatically. Company A sees what was actually tried, by whom, at what time — not a retyped account of it.

Scope matters

Grant-once auto-expires. It cannot quietly become the new normal.

A window auto-expires too, and the site gets a notice three days before it lapses.

Permanent is not a grant at all — it forces the policy to change, with a named approver and a dated record. That is deliberate: it stops silent exceptions accumulating until nobody remembers who approved what.

Exception request X-0071

V. Rane · Vestara regional

SiteSahyadri Nashik

Policylateral_issue

Requested byA. Kulkarni · Hospital

Scope requestedSingle case

Blocked attemptMV-48231 · 14:08

Context: 3rd lateral request at this site in 30 days — all citing the Floor 6 lift. Consider a window rather than a third single-case grant.

Request history · this site

Ref	Policy	Scope	Outcome
X-0071	lateral_issue	Once	open
X-0064	lateral_issue	Once	granted
X-0058	lateral_issue	Once	granted
X-0041	condemn_value	Window	expired
X-0033	one_way_issue	Permanent	declined

Repeated single-case grants for the same reason are a signal the policy is wrong, not that the site is difficult. This table is how Company A notices.

Granted

G-0071

Exception granted

V.RANE · VESTARA REGIONAL
03 AUG 2026 · 14:31 IST
X-0071 · SCOPE: SINGLE CASE

AuthorisesRoom C-North → Floor 6

LimitOne movement

ExpiresOn use

Attested byV. Rane · A. Kulkarni

The part that matters

The grant is itself attested and lands in the ledger, tagged to the movements it authorised. So the reconciliation statement carries the approval inline: "Room C-North issued 40 sheets to a South floor on 3 Aug, under G-0071, granted by V. Rane."

Without that, an exception is a loophole. With it, an exception is just another attested fact.

Supervisor at Room C is notified and the previously blocked action is now available — for exactly one movement.

Append-only · the grant rides on the movement, not beside it

Grant in the ledger

Configuration changes are movements too. Policy edits, exception grants, roster suspensions and topology changes all land in the same append-only record as linen — because "who allowed this, and when" is exactly the question a disputed month turns on.

Ref	Timestamp	Type	Detail	Qty	Under	Attested
MV-48244	03 Aug 14:36	LATERAL_ISSUE	ROOM_C_NORTH → FLOOR_6	40	G-0071	RK·SP ✦
CF-0071	03 Aug 14:31	GRANT	↳ lateral_issue · scope ONCE · expires on use	—	X-0071	VR·AK ✦
CF-0070	03 Aug 14:19	REQUEST	↳ raised by A.KULKARNI · attached MV-48231	—	—	AK ✦
MV-48231	03 Aug 14:08	BLOCKED	ROOM_C_NORTH → FLOOR_6 · policy lateral_issue	40	—	⚑ not executed
MV-48226	03 Aug 11:50	ISSUE	ROOM_C_NORTH → FLOOR_2	28	—	RK·MB ✦
CF-0066	02 Aug 09:14	ROSTER	↳ D.SHINDE suspended by A.KULKARNI · code revoked	—	—	AK ✦
CF-0063	31 Jul 17:02	POLICY	↳ variance_tol FORBID → WARN · tolerance 2%	—	—	VR ✦
CF-0059	28 Jul 10:40	TOPOLOGY	↳ SUBSTORE FLOOR_6 added · opening deployment 120	120	—	VR·AK ✦
CF-0055	26 Jul 15:22	MODULE	↳ rewash_tracking enabled · variance_tol tightened	—	—	VR ✦

Blocked attempts are recorded too

MV-48231 never executed, but it exists. Most systems throw blocked actions away, which loses the single most useful signal about whether a policy is working.

A site with 40 blocked attempts a month has a policy problem, not a discipline problem. A site with zero either has perfect policy or staff who have found a way around the app — and both deserve a look.

Blocked rows carry no quantity into any balance. They are evidence, not stock.

On the reconciliation statement

July · Sahyadri Nashik

Movements outside standard policy

Lateral issues under grant3 · 108 pcs

One-way issues (warn)9 · 47 pcs

Variance within tolerance31 · 62 pcs

Condemnations above threshold2 · ₹11,400

All authorised & attested✓

This block is what makes a disputed month short. Every irregular movement already carries its authorisation — there is nothing left to reconstruct from memory.