How to read this map
Each chapter walks one process in numbered steps. Every step names the actor, describes what the system does, and states what triggers the next step. Branches list every possible outcome at that point. Red-numbered steps are process endpoints.
1 · Approved data only. Dashboards, reports and the AI analyst read approved results exclusively. A figure that is not approved does not exist for reporting purposes.
2 · Transitions by procedure only. Submission and verification state changes go through guarded database procedures. Direct writes are rejected by the database itself, even for administrators.
3 · Approved results are locked. Once approved, a value and its RAG snapshot are frozen. Changing RAG thresholds recomputes non-approved results only. The only way back is a logged administrative reopen.
4 · AI assists, people decide. AI verification and analysis are first-level assistance. Every final decision — approve, reject, request clarification — is a person's, recorded with name, time and note.
5 · Everything is audited. Creations, updates, deletions, workflow events, overrides and decisions land in an immutable audit log with actor and timestamp.
Accounts, roles & access
Work is usually assigned before people are given logins. Add staff records someone by name — an email is optional — so they can immediately be named as a responsible officer, project manager or activity owner. They show as no account, and the system is explicit about what that costs: they cannot sign in, and nothing will reach them. Every screen that assigns work marks the option and spells out the consequence once it is chosen, and the notification engine skips them rather than queueing mail nobody will read.
Inviting them later moves everything already assigned to the staff record onto the new account and removes the placeholder, so the person never exists twice — once holding the work, once able to sign in.
Access is invitation-only and organization-bound. Eight roles carry 46 granular permissions; every screen and action checks them on the server.
1.1 · Requesting an account — public visitor
The visitor submits name, email and reason. No system account is created at this point.
The request is emailed to the platform owner’s configured address.
With an invitation sent, or with silence.
1.2 · Inviting a user — System Administrator
Enters full name, email, department and role(s). The invitation binds the future account to the organization at the authentication layer — a user can never sign up into the wrong organization.
The system emails a one-time invitation link from the platform’s verified domain.
With an active, organization-bound account.
The user appears in the user register; their role determines every subsequent capability in this map.
1.3 · Deactivation — exception path
The account keeps its history (submissions, decisions, audit entries remain attributed) but loses all access: row-level security resolves a deactivated user to no organization, so every query returns nothing. Notifications stop — the engine only notifies active users.
Immediately. Reactivation restores access without data loss.
Deleting removes the account and its sign-in identity outright, so it is allowed only where nothing depends on it. Opening Delete user asks the database what the account is attached to and shows the answer before anything is committed.
With an account removed, or with a clear reason why it cannot be.
1.4 · A forgotten password — exception path
Forgot your password? sits beside the password field. Giving an address sends a one-time link, valid for an hour, from the platform’s verified domain.
The confirmation reads the same whether or not the address belongs to an account. A form that says “no such user” tells anyone who asks which addresses are real, and the people who benefit from that are not the ones who forgot a password.
With the person signed in, or with a fresh link on its way.
No administrator is involved and no one else can see that it happened; the reset is the account holder’s own action.
1.5 · The code every record carries
{SEQ} the next number, {SEQ:3} the same padded
to three digits, {PARENT} the parent's numbering so a child continues it
rather than restates it, and {YEAR}. So OP-{PARENT}.{SEQ}
under outcome OC-1.1 gives OP-1.1.1.
1.6 · The nine roles
| Role | Core responsibility in the workflows below |
|---|---|
| System Administrator | Everything, plus the only role that manages the strategic plan, users, workflows and settings |
| Departmental M&E Officer | Periods, indicators, targets, RAG configuration, notification settings, engine controls |
| KPI Business Focal | Reviews and approvals, verification decisions, corrective actions, evaluations |
| DMD | First-line review of the department’s submissions; department performance |
| Data Focal | Enters results, uploads evidence, submits the department’s return |
| Project Data Focal | Submits project results and evidence; views and updates corrective action plans |
| Project Manager | Projects, milestones, activities, project evidence |
| Viewer | Read access to the dashboards, reports and information of their department |
| Auditor | Read access everywhere, including the audit trail; changes nothing |
Strategic plan & results framework
One strategic plan per organization, revised over its life — never multiplied. Only the System Administrator can create or change it; everyone else reads. The plan carries the hierarchy everything else aligns to.
Sets name, period (multi-year), vision and mission. Because an organization keeps one plan, revisions edit the existing plan rather than creating parallel ones.
Plan set to active — it becomes the root of the results framework.
The PDF is stored privately and rendered as a page-turning flipbook on the plan page, with table-of-contents navigation, page jump and full-text keyword search, so every staff member reads the same authoritative document inside the system.
Strategic Pillars → Strategic Objectives → Outcomes → Outputs. Each level links upward, so every record traces to the plan. Pillar rows open detail pages listing their objectives.
The Results Framework screen renders the full indented chain; indicators may now attach at any level (chapter 04).
All other roles see the plan, the flipbook and the framework read-only. Attempts to modify are refused by both the interface and row-level security.
The plan lifecycle ends at completed (period over) or archived.
Historical alignment is preserved: programs, indicators and results keep their linkage to the archived structure.
Programs, projects & activities
A project's physical progress used to be a number its manager typed in. It is now the arithmetic of the work underneath it:
An activity belongs to a milestone and carries a weight. A milestone's progress is the weighted mean of its activities, and its start and end dates are the earliest and latest of them — never typed in. A project's progress is the weighted mean of its milestones. All of it is maintained by trigger, so moving one activity or ticking one forward updates everything above it in the same statement. A milestone whose activities do not account for exactly 100% cannot be marked complete, and the database refuses it rather than the form.
A project's milestones and activities, the links between them, and any risks, issues, corrective actions, evaluations and evidence filed against it go when it does — they exist only because of it, and leaving them in their own registers pointing at something deleted is worse than removing them.
Everything is a soft delete: nothing is physically destroyed, the audit log records a count of what was swept, and it can be undone. Indicators are the exception — they are unlinked and kept, because an indicator carries approved results that belong to the organization rather than to the project that funded it.
Anything deleted anywhere in the system goes to Administration → Trash, where it can be restored or destroyed on purpose. Restoring a project brings back what was swept with it. After 30 days the daily run removes it for good — the trash empties itself, so deleted records neither pile up forever nor vanish the moment someone changes their mind. The audit log is never touched by any of this: what happened stays recorded whether or not the record survives.
Each project has a Gantt view. Milestones expand over their activities; dragging an activity bar moves it and dragging either edge resizes it, both snapped to whole days. Milestone bars are grey and cannot be dragged — a milestone has no dates of its own.
Activities can be linked: finish-to-start, start-to-start, finish-to-finish or start-to-finish, with a lag in days that may be negative. When a task moves, everything waiting on it moves too, keeping its own duration — but never backwards, because a constraint is a minimum and pulling a late schedule in is a decision rather than arithmetic. A link that would make two tasks wait for each other is refused.
Baseline. Freezing the schedule records what was agreed. From then on each bar carries a faint baseline beneath it and a badge showing how many days late or early it is running. Re-baselining is allowed but deliberate — it erases the evidence that the original plan slipped, so it asks first.
Given a project's name and context, the assistant proposes the milestones that kind of work is really broken into, each with its activities, weights, durations and the order they run in. It proposes only: the cards are selected, renamed, reweighted, removed or added to by hand, and nothing exists in the database until the project manager presses the button. It does not know how LEC specifically runs a job, which is why "Add custom milestone" sits beside it.
The delivery structure under the plan. Programs group projects; projects carry budgets, milestones and three progress dimensions; activities sit under milestones.
A project records its program, department, manager, dates, budget and health. Milestones get planned dates and owners — these dates feed the reminder engine (chapter 12).
Physical, financial and schedule progress are tracked separately; the dashboard shows the physical-minus-schedule gap as the project’s honesty check. Milestone completion records the actual date.
Project set to completed (or cancelled, which stops its reminders).
Project indicators and evidence remain queryable; evaluations (chapter 10) may reference the project.
Indicators, targets & RAG
Indicators are the measurement contract. Their definition, data source and verification method are not paperwork — the AI verifier reads them when judging evidence.
Code, name, definition, unit, value type (numeric, percentage, currency, count, ratio, date, yes/no, text), direction of success (higher-better, lower-better, exact, range), baseline, data source, collection method, calculation method, verification method, frequency, aggregation, and its attachment point in the results framework plus the responsible department and officer.
Each target belongs to one indicator and one period. Once any result against a target is approved, the target is locked — the database refuses changes that would rewrite history.
An organization-wide default (e.g. green ≥ 90 % achievement, amber 70–90 %, red < 70 %) with per-indicator overrides where a measure needs its own bands.
The indicator is ready for the reporting cycle.
The calculation engine applies achievement % (inverted for lower-better measures), variance and RAG automatically on every value entered.
Annual workplans & alignment
The workplan is a structured operational layer of the strategic plan — not a document divisions upload. Activities anchor to approved framework outputs, the system validates alignment and targets as they are typed, and final approval feeds the year's targets straight into monitoring.
5.1 · Opening a workplan cycle — M&E Administrator
Year, the strategic plan it operationalizes, submission and approval deadlines. One cycle per year per organization.
Generating the cycle creates one workplan workspace per division (the Division level of the organization structure) and notifies every division's submitters — in-app and by email — with the deadline.
5.2 · The division builds its workplan — Division officers
The strategic linkage is selected, never typed: the officer picks down the approved chain Pillar → Objective → Outcome → Output. Only the output is stored — the rest of the chain derives from it, so nobody can cherry-pick a convenient objective to fake alignment. The indicator comes from the library, filtered to that same results chain. Then: annual and quarterly targets, dates, responsible officer, budget and funding source, and the expected evidence.
Issues are computed in the database on every save, so they are identical for the officer, the reviewer and the quality dashboard.
5.3 · Approval chain — three recorded stages
Requires at least one activity. Editing locks the moment the plan is submitted — the database enforces it.
The department head is notified for stage 1.
Stage 1 Department Head Review (inside the division) → stage 2 Planning & M&E alignment & budget check → stage 3 Management approval.
The approved workplan materializes into monitoring: the year's quarterly and annual reporting periods are created if missing, and every activity's quarterly and annual targets become indicator targets for those periods — already-set targets are never overwritten; the counts are recorded in the event history.
Workplan at approved; the submitter is notified.
From here the standard cycle takes over: the reporting cycle (chapter 06) collects actuals against these targets, evidence verification (chapter 07) checks the proof, and performance dashboards roll achievement up the chain activity → output → outcome → objective. Management sees not just “the division achieved 85%” but which outputs put a strategic objective behind target.
5.4 · Corporate summary workplan — builds itself as divisions submit
The corporate summary workplan is a live aggregation of every division workplan that has been submitted (or is further along). It fills up as divisions submit — the coverage banner always states how many of the divisions are in ("Consolidated from 9 of 23 divisions") so a partial summary can never masquerade as the complete plan. Activities group under pillar → objective with budget and division rollups; indicators shared by several divisions consolidate their targets; unaligned activities appear in their own section with their justifications.
5.5 · Workplan quality dashboard — Planning & M&E, before approving
Divisions by status (approved / under review / submitted / returned / not started); the share of activities aligned, with indicators, with complete quarterly targets and with budgets; strategic coverage (“18 of 20 outputs covered”); budget totals per strategic objective with activity and division counts; and a needs-attention list — funding gaps, unaligned activities, target arithmetic errors — each linking to the division workspace where it can be fixed.
When every division is approved, the cycle closes and the year runs on the standard monitoring machinery.
The reporting cycle
Two rules, and either is enough. The officer named on the indicator may always enter its result, wherever in the organization that indicator sits — being responsible for a number is the claim that you are the one who reports it. Everyone else with the permission may enter results for their own unit and anything beneath it: a Department can fill in for a Section it staffs, but reach runs downward only, so sitting under the Managing Director Office does not make its return yours.
This is enforced in the row-level security policies, the submit procedure and the screen alike, so what a person can do and what they can see never disagree. My Submissions shows both — your unit's returns and every return holding an indicator you are responsible for — with the owning unit named on each row.
A result cannot leave the department without a file behind it. The submit procedure counts result rows with no live evidence and refuses the whole return if any exist, naming how many. The entry form asks for the file at the same moment it asks for the figure, so this is caught while the document is still to hand rather than at the end of the round.
Indicators reported monthly follow a monthly cycle without anyone opening anything. The twelve months of the year exist as reporting periods; on the first day of each month the daily engine opens that month, generates the department submissions and their result rows, and notifies every responsible party — the officer named on each indicator, the department's submitters and the department head — by in-app notice and email. The indicators appear under My Submissions at pending until the first value is entered. Quarterly, semiannual and annual indicators keep working exactly as before; opening a period by hand still does the same thing it always did.
Reopening removes an approval, so only the System Administrator can do it, and only with a written reason that is recorded against the report and shown to the department. The M&E Administrator instead raises a Request edit, which notifies every System Administrator and waits for a decision. Accepting a request does not itself reopen anything — the reopen is still performed deliberately, with its own reason.
The core process: a period opens, departments enter and evidence their results, submissions travel a configurable approval chain, and approved figures — and only approved figures — flow to dashboards, reports and the AI analyst.
5.1 · Opening a reporting period — M&E Administrator
Monthly, quarterly, semiannual or annual, with start/end dates and a submission due date. Status begins at upcoming. The due date drives every deadline reminder and escalation in chapter 12.
System The twelve monthly periods of the current year are created automatically and kept ahead — reporting closes ten days after each month ends. Months already past when the cycle first runs are created closed, so nobody is reminded about a month that was never collected.
One submission is generated per department that must report in this period, each containing one result row per indicator, all at draft. A department must report an indicator when it holds a target for the period, or when the indicator's own reporting frequency matches the period — so a monthly indicator is never quietly missed because a target was not loaded. Where no target exists the row still appears; achievement stays empty and RAG reads no data until one is set.
System notifies every responsible party in an affected department — the indicator's responsible officer, the department's submitters and the department head: “Reporting period open — submissions due <date>” (in-app + email, per the administrator's notification matrix).
System A period whose start date has arrived opens on its own at the daily run, so the monthly cycle needs no intervention. Opening one by hand is still available and behaves identically.
5.2 · Entering results — Data Focal
Editable only while the submission is draft or returned, and only by someone entitled to it under the rule above. The results table names the responsible officer on every row, so it is always visible who owes each number. The value field matches the indicator’s type; the explanation and challenges are required alongside the value — a figure with no narrative cannot be saved — plus a “corrective action required” flag.
System instantly computes achievement %, variance and RAG from the target and shows them beside the value.
Excel, Word, PDF, scanned PDF, images, CSV — stored in the private evidence vault, linked to the exact result row. The upload field sits inside Enter value: the figure and the document that proves it are captured together, and a result with a value but no evidence cannot be saved. Files already attached are listed, so editing a result does not ask for the document again.
AI Evidence verification starts automatically in the background the moment the upload completes (chapter 07). The officer does not wait for it.
The guarded procedure moves the submission to submitted and stamps who and when. From here the department can no longer edit values.
System notifies the first-stage reviewer — the department head for first-line review — “Submission awaiting your review” (in-app + immediate email).
5.3 · Review & approval chain — DMD, then each configured stage
Moves it to under review. The reviewer sees every value with its computed RAG, the narrative, the evidence — and each file’s AI verification result (score, discrepancies, relevance) in an AI flagged result column on the results table, so attention goes to the flagged rows first. Selecting a badge opens the full verification: the deterministic checks, the figures the model found in the document with the sheet, page or row it found them on, and the reviewer decision.
On any decision, the affected people are notified immediately (in-app + email): submitter on return/approval, next-stage holders on advance.
The submission’s life ends at approved.
Approved figures immediately count in dashboards, department performance, reports and the AI analyst. If an approved result lands red, the responsible officer and department head are alerted “Indicator off track”; amber alerts the officer “Indicator at risk”. Red results and “corrective action required” flags feed chapter 08. Evidence verification decisions (chapter 07) remain open until an M&E officer closes them.
5.4 · Exceptions
The only path back from approved: a guarded administrative procedure requiring a written reason, returning the submission to returned for correction and re-approval. The reopen, its reason and its actor are recorded in the event history and audit trail.
A manual RAG override (e.g. amber → red for context the numbers miss) requires a reason; the computed status is preserved alongside the override, both visible, both audited.
Departments still in draft or returned when the due date approaches or passes enter the submission escalation ladder (chapter 12): reminders at 7 and 3 days before, on the day, then escalation to the department head at +3 days and to head + administrators at +7 days.
Period set to closed; closing user and time recorded. Late entry is no longer possible without an administrative reopen.
Evidence & AI verification
Adding, re-pointing or removing evidence for an indicator and period whose departmental report has been approved is refused by the database, not merely hidden in the UI. An open reporting period is not enough to allow it — the gate is the department's report, not the period. To change the evidence behind an approved number, the report must first be reopened (see chapter 06).
Evidence is treated as structured data, not an attachment. Every uploaded file is read, cross-referenced against the submitted value, scored deterministically, and queued for a human decision. The AI never decides.
6.1 · Automatic verification — runs on every upload
Excel is read cell-by-cell with sheet and row references; CSV and text line-numbered; Word paragraph-numbered; PDF text page-labeled. Scanned PDFs and photographs go to the vision model as whole files (up to 8 MB).
The model receives the indicator’s definition, unit, data source, collection method, calculation method and verification method, the reporting period dates, and the submitted value — then reports, strictly from the document: candidate values with exact quotes and source references, relevance (supported / partial / unrelated / unknown), period fit, terminology presence, and — where a calculation method exists — whether the underlying figures reproduce the submitted number.
Five weighted checks: value confirmed (40), relevance (25), period (15), source identifiable (10), terminology (10). A value within 0.1 % passes; within 5 % warns as a minor discrepancy with the exact difference; beyond that, fails. The score and status are arithmetic over the checks:
The result appears on the verification dashboard, the evidence register, the AI flagged result column of the submission's results table, and inside the review screen — reviewers work the flagged and red rows first.
Selecting any row of the evidence register opens that file's own page: what it is, who uploaded it and when, the result and report it was filed against, and the full verification — checks, the figures found in the document with their sheet, page or row, and the reviewer decision.
6.2 · The human decision — KPI Business Focal (review permission)
Sees the score, every check with its detail, each found value with its quote and source reference, the AI summary labeled “first-level check only”, and the variance.
The database physically blocks any other path to these fields — the decision can only be recorded through the guarded procedure, with the officer’s name, time and note.
With the recorded decision.
The uploader is notified of the decision (in-app + email). The full matrix — indicator → submitted → evidence value → source → variance → AI finding → reviewer decision — persists permanently as the verification audit trail.
Corrective actions & escalation
Where under-performance turns into managed work. Actions link back to the indicator, result, project or evaluation recommendation that caused them — the traceability chain never breaks.
Title, reason, the linked source (red indicator result, project, or an evaluation recommendation), owner, department, priority (low → critical) and due date. Red approved results and “corrective action required” flags from the reporting cycle are the usual entry points.
System The daily sweep walks the escalation ladder below for every open action with a due date.
completed with completion time (or cancelled). Either state stops all reminders.
The action remains linked to its source for evaluations and audits: “red result → action → resolution” is a queryable chain.
7.1 · The default notification rules — editable per organization in Administration → Notifications
Submissions run on a stage-aware engine: every workflow stage carries its own SLA clock in working days (weekends and configured holidays never count), and the rules below follow whoever currently has the ball — the data focal person during entry, the reviewing manager at the review stage, the M&E officer at approval. Each rule names its recipients from a multi-select of roles — Data Focal, KPI Business Focal, Approver (DMD), Head of Institution (MD), Departmental M&E Officer, or Nobody — with a matching copy list for visibility; role recipients are resolved on the item’s own branch of the org chart. The engine sends at most one notice per item per day — the furthest applicable rung wins — stops the moment the action completes or moves stage, and records every rung it has fired so a re-run never duplicates.
| Stage | Rules (working days vs the stage deadline) |
|---|---|
| Data submission (period due date) | −5, −2, −1, 0, +1 → focal person (M&E officer copied) · +3 → supervisor L1 · +5 → supervisor’s supervisor L2 · +7 → head of institution L3 FINAL |
| Returned work (resubmission SLA, default 2 wd) | −1, 0, +1 → focal person · +3 → supervisor L1 · +5 → supervisor’s supervisor L2 |
| Reviewer stage (review SLA, default 2 wd) | −1, 0, +1 → reviewer · +3 → supervisor L1 · +5 → supervisor’s supervisor L2 |
| Approval stage (approval SLA, default 2 wd) | −1, 0, +1 → approver · +3 → supervisor L1 · +5 → head of institution L3 FINAL |
Corrective actions keep their calendar ladder (−7, −3, 0, +3 head, +7 head + administrators); milestones remind at −7, −3 and 0; evaluations remind their lead at −7 and −1. The head of institution receives only final escalations and the weekly summary — never routine reminders. M&E officers additionally get a daily digest every working morning (their departments’ outstanding, overdue and escalated items) and management a weekly completion summary. Every message lands in the record’s communication history, the admin delivery log, and retries up to three times on transient failure. SLAs, rules, holidays, escalation targets and digest days are all editable without code changes.
Risks & issues
Forward-looking exposure (risks) and materialized problems (issues), both department-owned and visible on the dashboard when they demand attention.
Title, category, owner, department, probability (1–5) and impact (1–5). The system computes the risk score as probability × impact.
At closed or realized; issues end at closed after resolution.
Evaluations & recommendations
Formal learning: baseline, process, mid-term, end-line, outcome, impact or thematic evaluations, each closing the loop from findings back into corrective work.
Type, scope (program or project), lead, dates, methodology, budget.
System reminds the lead 7 days and 1 day before the start date.
Findings are recorded against the evaluation; each finding can carry recommendations.
Evaluation at completed; each recommendation at implemented or rejected.
Evaluation follow-up is queryable — every recommendation shows whether the organization actually acted on what it learned.
Reports & the AI analyst
Two ways to consume approved results: fixed snapshots for the record, and conversational analysis for questions.
10.1 · Generating a report
Status generating while the system assembles a frozen snapshot of the approved data — the report never silently changes after the fact.
At generated — a permanent, dated snapshot.
10.2 · Asking the AI analyst
AI answers from a context built exclusively of approved, RLS-scoped data — it sees only what the asking user could see, cites indicator and project codes, shows its arithmetic, and says plainly when the data cannot answer. It has no tools and no write access; it can inform decisions, never make them.
Notifications & reminders
The engine that makes the system actively manage the M&E cycle. Every notification is delivered in-app and by email, governed solely by the organization-level matrix that administrators manage — individual users cannot opt out.
11.1 · What fires, and to whom
| Event | Recipients | Timing |
|---|---|---|
| Reporting period opened | Submitters in affected departments | Immediate |
| Submission awaiting review / approval | Department head, then each stage’s permission holders | Immediate |
| Submission returned / approved | Submitter | Immediate |
| Submission due / overdue | Escalation ladder (ch. 08 table) | Daily sweep |
| Indicator at risk / off track | Responsible officer (+ head when red) | On approval |
| High risk identified (score ≥ 15) | Risk owner + department head | Immediate |
| Corrective action due / overdue | Escalation ladder | Daily sweep |
| Milestone approaching / overdue | Owner, then owner + head | Daily sweep |
| Evaluation starting soon | Evaluation lead | Daily sweep (−7, −1) |
| Evidence verification decided | Evidence uploader | Immediate |
| System announcement | As addressed | Immediate |
11.2 · How a notification travels
Workflow events fire instantly from database triggers. The sweep runs every morning (06:00 in-database, with a 06:30 cloud follow-up that also sends the emails) and walks every due date against the escalation ladders. Deduplication guarantees at most one reminder per person per record per day.
One gate only: the organization’s settings matrix (per type: email on/off, in-app on/off), managed under Administration → Notification rules. No row recorded means both channels on. Individual users cannot switch notifications off.
Every email’s journey ends in a terminal state visible in the delivery history.
Administrators see the full history with stat tiles under Administration → Notifications, can edit templates with live preview, adjust the matrix and ladders, and run the engine on demand (“Run engine now”). Failed sends can be diagnosed from the recorded error.
Administration & audit trail
The configuration that shapes every workflow above, and the record that outlives all of them.
| Screen | Who | What it governs |
|---|---|---|
| Users & Roles | System Administrator | Invitations, activation, role grants — chapter 01 |
| Departments / Organization structure | System Administrator | Department tree, unit-to-department roll-up, department heads (who receive escalations and first-line reviews) |
| Workflows | System Administrator | The approval pipeline per entity type: ordered stages, each requiring a permission — this defines who approves at each stage of chapter 06. With no stages configured, first approval is final. A rejection at any stage returns to the submitter. |
| Reporting Periods | M&E Administrator | Create, open, close — the clock of chapter 06 |
| RAG Configuration | M&E Administrator | Threshold bands and per-indicator overrides; recomputes non-approved results only |
| Notifications | M&E / System Administrator | Settings matrix, escalation ladders, email templates, delivery history, run-now — chapter 12 |
| System Settings | System Administrator | Organization profile and platform options |
| Audit Trail | Auditor / System Administrator (read-only) | The immutable log below |
12.1 · The audit trail — where every process ends up
Every create, update and soft delete on governed records; every workflow event with its actor, stage and comment; every RAG override with its reason; every verification decision with its note; every administrative reopen. Audit rows cannot be edited or deleted — the database refuses. Evidence files are soft-deleted only: the record of what was uploaded, by whom, and what the AI and the reviewer concluded about it, is permanent.
It doesn’t. That is the point.