The Scope Document: Data & Model Audit

This document sets the scope of the engagement and the standard the work is measured against. Both are fixed as of the start date. Neither side may change them while the engagement runs.

1. The system under audit

The audit covers one system, named in the signed copy: what it does, where its code lives, which datastores and pipelines it reads and writes, and which outputs depend on it. Named precisely enough that a third party could tell whether a given component is inside or outside the boundary.

Anything not named there is out of scope. If the work uncovers a defect in an adjacent system, we tell you it exists, in writing. It does not count as a delivered finding and we do not investigate it under this engagement.

2. What you receive

A data lineage map of the named system, produced in week one.
A written report of findings, each meeting the standard in section 3, each rated under section 4, each carrying the evidence in section 7.
An ROI-ranked roadmap: what to fix, in what order, and what each fix protects or earns.
A walkthrough call on delivery.

The report is yours to keep, use, and act on, whether or not we work together afterward.

3. What counts as a qualified finding

A finding counts toward the commitment in section 5 only if it passes all four tests:

In scope. It concerns the system named in section 1.
Reproducible. You can re-run it yourself, against your own data, and get the same result. Evidence that cannot be re-run is not a finding.
Consequential. It names what the defect costs you: a number that cannot be re-derived, a claim the data does not support, a failure your monitoring will not catch. Preferences about how we would have built it are not findings.
Actionable. It carries a severity rating under section 4 and a specific recommended fix, positioned in the roadmap.

4. Severity rubric

Severity describes consequence, not how hard the fix is. A defect that takes an hour to correct can be High. A rewrite can be Low.

Rating	Any one of
HIGH	A number already shown to a customer, an investor, a regulator, or a counterparty is wrong, or cannot be supported by the underlying data. The system produces a materially wrong output under conditions that occur in normal operation. A control that is relied on (a check, a reconciliation job, an alert) does not do what it is believed to do.
MEDIUM	A number used internally for decisions is wrong or unsupportable, but has not left the company. A defect produces wrong output only under conditions that are possible but not routine. A failure mode is currently undetectable: it has not occurred, and nothing in place would catch it if it did.
LOW	The output is correct today, but the practice that produced it will not stay correct: no point-in-time discipline, an undocumented assumption, a silent dependency. Correctness is not at issue. Cost, latency, or maintainability is.

Rantum assigns severity against this rubric. The rubric does not change during the engagement. Disagreement about a rating is not one of the rejection grounds in section 8: if you disagree with a rating, tell us in writing and your objection is appended to the finding in the delivered report, unedited.

5. How many findings

This engagement commits to five qualified findings.

A clean system is a real result and we will not manufacture findings to reach a number. If fewer than five qualified findings are delivered, you choose one: a $3,000 rebate, or a fourth week against a second system you name, at no additional fee. That remedy exists so that padding the report is never the cheaper option for us.

Findings beyond the fifth are delivered at no additional cost. There is no cap.

6. What we will not do to reach the number

Splitting one defect into several findings, reporting the same root cause in several places, and reporting known-good behavior as a risk all fail section 3 and do not count. If you believe a finding was manufactured this way, ground 1 in section 8 is what to reject it on.

7. Evidence each finding carries

The query, script, or check that produces it, runnable by your team.
The output of that run, dated.
The exact input it ran against: table, snapshot, date range.
What a passing result looks like, so your team can verify the fix without us.

8. Rejecting a finding

You may reject a finding in writing within ten business days of report delivery, on these grounds and only these:

Out of scope. It concerns a system other than the one named in section 1.
Not reproducible. You run the supplied evidence against the named input and do not get the reported result.
Wrong. The system does not behave as described, and you can show it.
Already documented. It was recorded in your issue tracker or your documentation before the start date, and you can link it.

A rejected finding does not count toward the five, and we replace it at no charge within ten business days.

That list is exhaustive. A finding cannot be rejected for being unwelcome, for confirming something you had suspected but never written down, or for reaching a conclusion you would rather it did not. The criteria in sections 3, 4 and 8 are set before the work starts and do not move while it runs: we cannot loosen them to inflate the count, and they cannot be tightened to shrink it.

9. Access and dependencies

The three-week schedule assumes these are in place on the start date: read access to the source repositories and to the datastores the system reads and writes (production or a faithful replica), access to existing documentation, dashboards and monitoring, and a named technical contact who can answer questions within one business day.

Each business day any of those is outstanding after the start date moves the delivery date by one business day. Nothing else changes: the fee, the scope, and the commitment in section 5 all stand. If access is still outstanding ten business days after the start date, either side may pause the engagement and we agree a new start date in writing.

We do not require write access to production.

10. Out of scope

Systems other than the one named in section 1. Implementing the fixes we recommend, which is a separate engagement this one carries no obligation toward. Security or penetration testing. Legal or regulatory opinions. Ongoing monitoring after delivery.

11. Confidentiality

Your code, your data, and the findings are yours and are treated as confidential. We will not name you as a client, quote any figure from your system, or publish anything identifying the engagement without your written permission.

We may reuse generalized, non-identifying lessons: a class of defect, a method, a category of failure, with the client, the product, the sector detail, and all figures removed. If you would prefer we not do even that, the signed copy has a box to say so.

12. Fee and payment

$12,000, fixed, covering everything in section 2. There are no hourly overages, and no additional charge for findings beyond the fifth.

50% on signature, 50% on delivery of the report. Any rebate owed under section 5 is netted against the final payment, which at these terms always covers it.

The Scope Document