A production SLP-compliance platform Khula built for South African mining — spec-driven, AI as the primary builder, shipped in four days without dropping a single production standard.
Author the plan. Track the work. Prove it to the regulator.
Rootline is a multi-tenant platform for mining operations to write Social & Labour Plans, track delivery against every Mining Charter commitment, and leave behind an immutable record a DMRE inspector can read. One data model, tenant-isolated by row-level security, from first draft to audit file.
How the calendar shrank, and what it didn’t cost.
Four days is not a corner-cutting story. It is what a locked spec, AI used as the primary build assistant, and one shared data model do to the parts of a build that normally take weeks.
Spec-driven build
The data model, roles, and Mining Charter section structure were locked on day zero, so implementation was execution against a fixed target instead of discovery.
AI as the primary builder
AI wrote the bulk of the schema, RLS policies, workflow, and doc-generation code under review — not bolted into the product, but used to compress the writing of it.
One model, every surface
Authoring, tracking, reporting, and the audit trail read from a single Postgres schema, so a rule written once renders everywhere instead of being rebuilt per screen.
What four days didn’t cut
Tenant isolation is enforced in the database with Postgres row-level security, not in application code. The audit trail is immutable — append-only, no edit path. The build carries 80%+ test coverage, and the data model is POPIA-aligned from the schema up. Speed came out of how the code was written, not out of the standards it was held to.
A plan in one place, the proof in twelve others.
Under the Mining Charter, a mining right carries a Social & Labour Plan — commitments on skills, procurement, local economic development, and housing that the operation must deliver and report on to the DMRE. The plan is a document. The delivery happens across departments over years.
In most operations the SLP lives in Word and PDF, the commitments get re-keyed into spreadsheets, and the evidence that each commitment was met is scattered across email, shared drives, and people’s memory. When a Reg 45 report or an inspection lands, someone spends weeks reassembling a story the systems never held in one place.
The gap is not effort. It is that the plan, the tracking, and the proof were never the same object.
Disconnected SLP documents
The authored plan and the day-to-day delivery data live in different tools, so the plan drifts out of date the moment work starts.
Manual Reg 45 reporting
Annual compliance reports are hand-assembled from spreadsheets and folders — slow, error-prone, and impossible to reproduce.
Scattered proof for the regulator
When an inspector asks “show me,” the evidence has to be hunted down after the fact rather than captured as work happens.
Eight modules, one compliance record
Each module carries a branded name and the plain UI label it ships under. They share one tenant-isolated data model, so a commitment authored in Rootplan is the same object Linewatch tracks and Rootmark proves.
SightlineDashboard
The tenant’s live status view — tracked compliance tables and where every SLP edition currently stands.
RootplanSLP authoring
Write the Social & Labour Plan against the Mining Charter section skeleton, one structured commitment at a time.
LinewatchCompliance tracking
Track actual delivery against each planned commitment and surface drift before it becomes a finding.
ClearlineReports
Generate Reg 45-shaped compliance reports straight from the tracked data as a Word or PDF document.
TimberlineCalendar
Keep reporting deadlines and commitment milestones on a single timeline the whole tenant works from.
FaultlineDirectives
Log regulator directives and internal actions, and hold them against the commitments they affect.
RootguideTraining
Reference material that keeps authors and reviewers aligned on how each SLP section should be filled in.
RootmarkEvidence & Audit
The append-only spine — every change, approval, and piece of evidence captured in an immutable trail an inspector can follow.
One spine, five stages
A commitment moves through Rootline in a straight line — and the moment it is locked, the record behind it stops being editable.
Author
Write commitments in Rootplan against the Charter skeleton.
Review & approve
Reviewers check each section and sign it off by role.
Lock
The edition is frozen. The audit trail becomes append-only from here.
Track
Linewatch records actual delivery against every locked commitment.
Prove
Clearline and Rootmark render the report and the evidence file.
Inside the two screens that carry the work
Authoring on one side, tracking on the other — the same commitment object, seen at two points in its life.
The Rootplan authoring screen, mid-edit — identifying details are blurred for client confidentiality.
Write the plan as structured commitments, not prose
Rootplan holds the Mining Charter section structure as a skeleton and asks the author to fill it in commitment by commitment — each with an owner, a target, and a section it answers to. Because every line is a typed object rather than a paragraph, the plan is trackable from the moment it is written.
The Linewatch tracking screen — identifying details are blurred for client confidentiality.
Track actual against planned, and see drift early
Linewatch reads the locked commitments and lets teams record what was actually delivered against each one. Planned-versus-actual sits in a single view, so a commitment falling behind shows up as it happens rather than at report time — and every update lands in the audit trail.
One platform, many operations, no data bleed
The Administration / Tenants control. Khula operates across tenants from one place; the tenant name in the selector is intentionally redacted here.
Every mining operation on Rootline is a tenant with its own SLP editions, tracking, evidence, and branding. Isolation is enforced in Postgres with row-level security — a tenant’s rows are unreachable from another tenant’s session at the database layer, not merely filtered in application code.
White-label branding lets each operation see its own identity, while Khula operates centrally: an authorised operator switches the active tenant from the Administration screen and works inside that workspace, with the top-of-page tenant header making the current context unmistakable.
The result is a single platform Khula can run and support across many mining clients, without any client’s compliance data ever touching another’s.
From a spreadsheet of commitments to a tracked record
The same SLP commitments, seen the old way and the Rootline way. Illustrative rows — the shape of the change, not a specific client’s data.
Commitments re-keyed into a spreadsheet. Status is a hand-typed word, proof lives elsewhere, and nothing is reproducible.
| Commitment | Target | Status | Proof |
|---|---|---|---|
| Portable skills | 120 learners | Unknown | Email? |
| Local procurement | 40% | Behind | Drive |
| LED — clinic | Phase 1 | Verbal | — |
| Housing units | 60 units | Stale | Folder |
| Bursaries | 25 awards | Manual | Inbox |
Each commitment is a locked object with planned-versus-actual, a live status, and an evidence link written to the audit trail.
| Commitment | Target | Status | Evidence |
|---|---|---|---|
| Portable skills | 120 | On track | Logged |
| Local procurement | 40% | At risk | Logged |
| LED — clinic | Phase 1 | Met | Logged |
| Housing units | 60 | Behind | Logged |
| Bursaries | 25 | Met | Logged |
How the build ran, day by day
A locked spec on day zero, then four days of execution — each day standing on the isolation and audit foundations laid the day before.
Spec locked
Data model, roles, Mining Charter section structure, and the plan-to-proof flow fixed before a line was written.
Foundations
Auth, multi-tenancy, and Postgres row-level security stood up first, so every later feature inherited isolation by default.
Rootplan
SLP authoring and the review-approve-lock workflow, writing structured commitments against the Charter skeleton.
Linewatch & Clearline
Compliance tracking of actual-versus-planned, plus Reg 45-shaped report generation via docxtemplater and Playwright.
Harden & review
Notifications, background jobs, test coverage to 80%+, and a security review of the tenant-isolation and audit-trail guarantees.
The stack that made four days safe
Boring, proven pieces in a deliberate order — isolation and immutability at the bottom, document generation at the top.
Stack, foundation to output
The Mining Charter is a skin, not the machine
Strip Rootline back to its mechanics and there is nothing mining-specific about them: structured commitments against a policy skeleton, planned-versus-actual tracking, escalation when the two drift apart, and an immutable record left behind. That engine would outlive its first client’s framework.
The Mining Charter gives Rootline its current skeleton — Reg 41–46 sections, SLP commitments, Section 29 directives, a compliance file. But those are the policy layer. Underneath sits a domain-agnostic pattern that Khula designed the platform around.
Consider what the same engine would look like pointed at a management consultancy’s cadence-management practice — the SDCA (Sustain-Do-Check-Act) and PDCA (Plan-Do-Check-Act) discipline a firm like Semousu-Moloi Projects runs with its clients. This is illustrative, not a live integration: swap the skeleton and the machine keeps turning. You would replace Reg 46 sections with SDCA/PDCA checkpoints, SLP line items with work-practice or KPI targets, Section 29 directives with missed cadence checkpoints, and the regulator’s compliance file with an audit-trail proof record for the engagement.
Nothing in the tracking loop would have to change. This is the shape a management consultancy’s engagement tooling would take on the same engine — and it is why Khula treats the pattern, not the Mining Charter wiring, as the reusable asset. The engine outlives the first client’s specific framework.
Illustrative only. The SDCA/PDCA column is a hypothetical second application shown to make the point that the pattern is domain-agnostic. It does not describe an existing Rootline deployment or customer.
The engine’s four moving parts, mapped onto what is built today and onto one hypothetical second domain.
| Engine part | Mining SLP (built) | Consultancy KPI tracking (same engine, illustrative) |
|---|---|---|
| Skeleton | Reg 41–46 sections | SDCA / PDCA checkpoints |
| Commitment type | SLP line items | Work-practice / KPI targets |
| Escalation trigger | Section 29 directive | Missed cadence checkpoint |
| Proof left behind | Compliance file | Audit-trail proof record |
Rootline was built so a mining operation never again has to reassemble its compliance story after the fact. The plan you author is the thing you track, and the thing you track is the thing you prove.
Plan to proof, in one tenant-isolated record — authored, locked, tracked, and left behind as evidence an inspector can follow without taking anyone’s word for it.