Audit Integrity & Human Review

What “audit” means here

We use the word “audit” in its everyday business sense — a rigorous look at how a company operates and where money leaks out of it — and we are explicit about that so there is no confusion with a regulated financial audit.

How a finding is produced

Every finding travels the same path, from the data you provide to a number on your dashboard. The stages are deliberately ordered so that a human review always sits between machine analysis and anything a client sees.

1. 1Source dataThe documents, operational and financial data, and intake answers you provide. Stored privately and validated on upload — never itself a client-facing number.
2. 2Deterministic, automated analysisServer-side validation and our versioned analysis engine compute metrics and candidate findings from your data using fixed rules and a sourced knowledge base. No AI model runs in this step.
3. 3AI-assisted contextual analysisAI assists on minimized metadata — helping structure inputs, surface patterns, and prioritize candidates for review. It cannot publish, and it does not set the numbers a client sees.
4. 4Human reviewThe audit team reviews candidate findings, applies conservative estimation, and decides which are sound enough to release. Weak or contested items are set aside.
5. 5Published findingsOnly after a staff member publishes does a finding — and its dollar range — become visible to the client, and only within that client’s own organization. Publishing is a logged, server-side action.

Evidence-based assessment

An audit is assembled from several kinds of input, brought together rather than taken on trust from any single source:

• the documents and operational or financial data you upload;
• your answers to our intake checklist (the questionnaire);
• metrics computed from that data;
• the structured analysis produced by our engine;
• the observations and judgement of our audit team.

Uploaded documents are validated on the server before they are analysed, and the outcome of that check is recorded. Our analysis engine (alpha_engine) is a versioned, tested software package with a fixed schema for every finding — not a generic chatbot wrapped around a prompt.

The engine draws on a maintained knowledge base of industry benchmarks, remediation playbooks, and precedence rules to inform its analysis. The knowledge base enforces its own sourcing: an entry with no real source, reference, and date is rejected, so benchmarks used in analysis trace back to a citable origin.

Human validation

Findings are produced and scored per zone by the engine — the “lever” readings shown on your dashboard — and are then held behind a publish gate. In the database, a finding that has not been published is invisible to the client by design: access rules return only published findings, and only for the client’s own organization.

No dollar figure and no lever score appears on your dashboard until a member of our audit team publishes it. Until then the dashboard shows a locked or preview state — never a placeholder amount, never a sample dial position.

Every score and range is presented as the audit team’s conservative estimate — not a verified-final figure and not a guarantee. Our internal impact math is conservative by construction: it leans on the low end of each estimated range, and lower-confidence items are set aside as “areas to investigate” rather than counted as recoverable dollars.

Traceability

Every finding is filed under exactly one of seven operational zones — pricing, job costing, billable hours, memberships, dispatch, collections, and payments — which drive the levers on your dashboard.

Where implemented, each finding carries typed evidence references back to the metrics, data rows, or source files it rests on, and each dollar impact names the calculation formula used to produce it. Canonical data rows retain a pointer to the exact file and row or cell they were parsed from, so a figure can be re-derived rather than taken on faith.

Platform activity is recorded in an append-only event log — an activity trail that is only ever added to, never edited in place — so there is a record of what happened and when.

Conflict handling

Because a single dollar could plausibly be claimed by more than one zone, the engine enforces a one-dollar-one-zone precedence matrix. When two findings cite overlapping data, a fixed rule names which zone owns the dollar; the other finding must be dropped or re-scoped before the analysis is assembled. This prevents the same money being counted twice.

Findings also move through an explicit review lifecycle — a finding can be verified, bounced back for rework, approved, or killed — so weak or contested items do not reach a client.

Where inputs are genuinely ambiguous or appear to conflict beyond what these automated checks resolve, our process is to escalate them for human review rather than settle them silently. (This escalation is a design principle of how we run engagements; the exact routing is handled by our audit team.)

Final report integrity

Three responsibilities are kept separate — by design, and where noted by code:

This separation is enforced, not just intended. Findings can only be written by a trusted server-side process; the privileges to insert or change them are revoked from every ordinary and staff browser session outright. Publishing is deliberately kept behind a server-side step that also records the event, so the single act that puts a number in front of a client is controlled and logged.

Our in-product AI assistant is a status-and-process helper only. It is explicitly barred from producing findings, dollar amounts, or benchmark numbers — any number you see comes from a published finding, never from the assistant. It also operates on minimized data: it works from metadata such as file names and statuses, not the contents of your uploaded documents or your financials. Our AI-assisted features use Anthropic’s Claude (Haiku 4.5).

In short: AI-assisted analysis, reviewed and published by the audit team.