Mathematician / Auditor / Data Scientist – Exact, Auditable Calculation Engines (NDA required)
Budget / SalaryC$3,000–5,000
TypeFreelance project
LocationRemote
Posted2 hours ago
In short: we need calculation engines built from published rulebooks, where an external auditor can follow every number, formula and assumption from source document to final figure, line by line, without ambiguity.
Start your bid with the word LEDGER.
ABOUT THE WORK
We turn published technical standards into executable calculation engines. Each engine is proved by reproducing, to the last unit, figures an independent auditor has already signed off. The standards come from several standard-setting bodies, each with many versions and rules of its own. We also want a toolkit for building future engines. Please do not ask about the industry; details follow the NDA.
WHAT YOU WILL BUILD
1. Rules to code
- Read each standard in full: every version, annex, table, equation and footnote, plus the body's own procedures.
- One engine per standard per body that applies it: a standard used by two bodies needs two engines, each with its own body's rules and thresholds; never two engines for one standard under one body; a case reviewed under two standards needs an engine for each.
- A version history: when each rule was introduced, changed or retired, and transition rules for older cases.
2. Gates (each break-tested to show it fails when it should)
In the engine, every run:
- Document: every source file listed with its hash; a missing or changed file halts the run.
- Quote: each rule quotes its passage, found in that version's text at its hash before the rule runs.
- Applicability: every condition answered, units checked, each refusal quoting the standard; fails closed.
- Version: only the current version executes; earlier versions a case used are separately named functions, never a switch, with a record of which case used which.
- Rounding: as the documents do it, the order proven against an audited figure, the rule quoted from the body's text.
Before delivery:
- Citation: every constant cited to a document in the package that contains it, or derived with the derivation shown.
- Suite: tests fail with the engine stubbed and with source texts or case files hidden; no typed-in figures; every survivor of a stubbed engine explained.
- Mutation: run at the final engine's hash; every survivor killed by a test that reads a document or shown to change no result; a crash is not a kill.
- Falsifiability: for every claim the engine makes, what would prove it wrong, and a test.
- Order: where operations do not commute (a floor against a deduction, a percentage, a rounding step), a test proves the order or the gap is stated.
- Clean-room: no code shared with the engine it replaces.
- Count: findings from each auditor report match its own count table.
- Hostile self-audit from an empty folder: tests and gates pass, hashes recompute, scripts re-run byte for byte, no tolerance in the code, every reported figure in a script output.
3. Exact reproduction
- Rebuild at least one real, independently audited case per engine from its published documents: every intermediate and final figure exact, zero tolerance. If a case cannot be rebuilt, the engine is not kept.
- Exact decimal arithmetic throughout; no binary floating point, so no pandas or NumPy for calculations.
- Round and truncate where and how the documents do, line by line or on totals, recording the rule and the reason beside each rounded figure; the rule is found in the body's texts, never assumed.
- No difference is accepted until four questions are answered with arithmetic: same basis and period? same unit and scale? derived by a stated rule? explained by the document? Never fit or invent a value.
- Floors, caps and thresholds are immutable state across periods: a carried-forward shortfall survives separate runs, restarts and out-of-order processing.
4. Evidence and integrity
- Every constant and rule carries document, version, page, paragraph/table/equation, verbatim quote and file hash; a citation whose text is not in the package does not count.
- A tamper-evident ledger: inputs hashed, every value traced to its inputs and rule, a seal over all state, no undetected change after ingestion, no runtime overrides.
- An audit log of every intermediate step, so a reviewer can retrace source to final figure line by line.
- Faithful extraction from PDF and Word (footnotes, tables, equations) and from .xlsx and .xls: formulas, shared and array formulas and cached values kept apart from an independent recalculation; comments, hidden sheets, named ranges, external references; stored precision apart from display; error values flagged. Decimal commas, thousands separators, superscripts and units handled correctly. Every value points back to its file and cell, or page and line.
5. Insight layer (per case, tied to its engine, stages kept apart)
- Auditor findings verbatim, dates stripped from the finding text, in one shape across cases.
- Insights in a fixed layout: the client's question, a one-line answer, facts with figures, when it must be told, source and code.
- Peer-range benchmarking.
- Case status history (rejections, withdrawals, cancellations, returns): what happened, why, and the calculated cost and time.
- Nothing the documents do not print; leave the field blank.
6. Scale: hundreds of standards, thousands of documents, side-by-side options for the same activity, and live sensor data as an input.
7. Toolkit for future engines
- The shared core built and tested once: ledger, readers, gates, test and mutation runners, workbook builder.
- A generator writing each new engine as a single file from that core, recording the core's hash.
- A scaffold that extracts a new standard's candidate constants, equations, tables and rounding instructions, with page and quote, for a qualified person to confirm.
- A version comparer, a step-by-step build procedure with exit tests, and record templates.
DELIVERABLES (each engine)
- The engine file (Python, standard library only) and its source documents with hashes.
- A workbook built by a delivered script: every step a live formula, inputs traced to page or cell, printed figures in blue beside computed ones with an agreement cell, recalculated in a second spreadsheet program.
- An evidence index, the audit log, and test, gate and mutation results.
- A README (setup, assumptions, how to extend), a handover note, and updates to our tracker in its fixed format.
Reports show proof (counts and diffs), not narration.
Toolkit: source, tests and documentation owned by us, the build procedure, and a handover session.
ACCEPTANCE
1. Every figure reproduces the audited case exactly.
2. Every test and gate passes from the package in an empty folder, standard library only.
3. The same inputs give identical outputs and audit log on every run.
4. Our edge and benchmark cases pass; every mutant is killed or explained.
5. The toolkit is accepted when someone other than its author builds an engine with it that passes every gate.
WHO WE ARE LOOKING FOR
One person or a small team (a mathematician, an auditor and a Python developer can bid together).
Past work (at least two; details after the NDA):
- Rebuilt another party's figures from source documents and raised findings that changed a reported number.
- Built a rules engine from a versioned rulebook (tax, tariff, actuarial, regulatory capital) that matched official figures exactly.
- Audited spreadsheet models: traced formulas, compared stored and recalculated values.
- Extracted data from thousands of documents with every value traced to its source.
- Mutation or property-based testing, a tamper-evident audit trail, or sensor data validation.
Must have: strong mathematics (exact arithmetic, rounding, floating-point pitfalls, statistics); an auditing background (financial, forensic, internal, quality or model audit); the patience to read long documents in full and stop at the first number that disagrees; strong, well-tested Python; document data extraction.
Nice to have: an accredited audit, inspection, certification or model-validation role (ISO 19011, ISO/IEC 17020, 17021, 17025, 17065, SR 11-7, GxP); engineering or physical science; event sourcing and hashing.
HOW WE WILL WORK
1. Screening on your answers; no domain details yet.
2. NDA and IP assignment: all work product belongs to us.
3. A paid pilot: one engine, accepted only against the criteria above.
4. A milestone contract, one engine at a time; each delivery is audited independently and paid on acceptance.
CONFIDENTIALITY
Specification, sample documents and benchmark cases are shared only after the NDA and IP assignment. Our materials stay in agreed systems, go to no third party or external service without written approval, and are returned or deleted at the end.
IN YOUR BID
LEDGER first, then a few lines on each:
1. Ten printed yearly figures add to 4,512,608; the printed total is 4,512,603. What do you do, and what would you never do?
2. Show where binary floating point and exact decimal arithmetic round differently, and how you prevent it.
3. A shortfall must be recovered before any later surplus counts. How does that survive separate runs, restarts and out-of-order processing?
4. Version 4 changes a factor, but older periods must still be checked under version 3. How do you structure the code?
5. How do you prove your tests catch a dropped term, and why does a test that fails only by crashing not count?
6. How do you prove a table, a footnote and a spreadsheet formula with its cached value were extracted faithfully?
7. Two documents print different values for the same parameter and period. What does the engine use?
8. Your audit experience: the kind, your role, how many engagements, and one finding that changed a figure.
If you live and breathe numbers and love proving your work, we look forward to hearing from you.
Start your bid with the word LEDGER.
ABOUT THE WORK
We turn published technical standards into executable calculation engines. Each engine is proved by reproducing, to the last unit, figures an independent auditor has already signed off. The standards come from several standard-setting bodies, each with many versions and rules of its own. We also want a toolkit for building future engines. Please do not ask about the industry; details follow the NDA.
WHAT YOU WILL BUILD
1. Rules to code
- Read each standard in full: every version, annex, table, equation and footnote, plus the body's own procedures.
- One engine per standard per body that applies it: a standard used by two bodies needs two engines, each with its own body's rules and thresholds; never two engines for one standard under one body; a case reviewed under two standards needs an engine for each.
- A version history: when each rule was introduced, changed or retired, and transition rules for older cases.
2. Gates (each break-tested to show it fails when it should)
In the engine, every run:
- Document: every source file listed with its hash; a missing or changed file halts the run.
- Quote: each rule quotes its passage, found in that version's text at its hash before the rule runs.
- Applicability: every condition answered, units checked, each refusal quoting the standard; fails closed.
- Version: only the current version executes; earlier versions a case used are separately named functions, never a switch, with a record of which case used which.
- Rounding: as the documents do it, the order proven against an audited figure, the rule quoted from the body's text.
Before delivery:
- Citation: every constant cited to a document in the package that contains it, or derived with the derivation shown.
- Suite: tests fail with the engine stubbed and with source texts or case files hidden; no typed-in figures; every survivor of a stubbed engine explained.
- Mutation: run at the final engine's hash; every survivor killed by a test that reads a document or shown to change no result; a crash is not a kill.
- Falsifiability: for every claim the engine makes, what would prove it wrong, and a test.
- Order: where operations do not commute (a floor against a deduction, a percentage, a rounding step), a test proves the order or the gap is stated.
- Clean-room: no code shared with the engine it replaces.
- Count: findings from each auditor report match its own count table.
- Hostile self-audit from an empty folder: tests and gates pass, hashes recompute, scripts re-run byte for byte, no tolerance in the code, every reported figure in a script output.
3. Exact reproduction
- Rebuild at least one real, independently audited case per engine from its published documents: every intermediate and final figure exact, zero tolerance. If a case cannot be rebuilt, the engine is not kept.
- Exact decimal arithmetic throughout; no binary floating point, so no pandas or NumPy for calculations.
- Round and truncate where and how the documents do, line by line or on totals, recording the rule and the reason beside each rounded figure; the rule is found in the body's texts, never assumed.
- No difference is accepted until four questions are answered with arithmetic: same basis and period? same unit and scale? derived by a stated rule? explained by the document? Never fit or invent a value.
- Floors, caps and thresholds are immutable state across periods: a carried-forward shortfall survives separate runs, restarts and out-of-order processing.
4. Evidence and integrity
- Every constant and rule carries document, version, page, paragraph/table/equation, verbatim quote and file hash; a citation whose text is not in the package does not count.
- A tamper-evident ledger: inputs hashed, every value traced to its inputs and rule, a seal over all state, no undetected change after ingestion, no runtime overrides.
- An audit log of every intermediate step, so a reviewer can retrace source to final figure line by line.
- Faithful extraction from PDF and Word (footnotes, tables, equations) and from .xlsx and .xls: formulas, shared and array formulas and cached values kept apart from an independent recalculation; comments, hidden sheets, named ranges, external references; stored precision apart from display; error values flagged. Decimal commas, thousands separators, superscripts and units handled correctly. Every value points back to its file and cell, or page and line.
5. Insight layer (per case, tied to its engine, stages kept apart)
- Auditor findings verbatim, dates stripped from the finding text, in one shape across cases.
- Insights in a fixed layout: the client's question, a one-line answer, facts with figures, when it must be told, source and code.
- Peer-range benchmarking.
- Case status history (rejections, withdrawals, cancellations, returns): what happened, why, and the calculated cost and time.
- Nothing the documents do not print; leave the field blank.
6. Scale: hundreds of standards, thousands of documents, side-by-side options for the same activity, and live sensor data as an input.
7. Toolkit for future engines
- The shared core built and tested once: ledger, readers, gates, test and mutation runners, workbook builder.
- A generator writing each new engine as a single file from that core, recording the core's hash.
- A scaffold that extracts a new standard's candidate constants, equations, tables and rounding instructions, with page and quote, for a qualified person to confirm.
- A version comparer, a step-by-step build procedure with exit tests, and record templates.
DELIVERABLES (each engine)
- The engine file (Python, standard library only) and its source documents with hashes.
- A workbook built by a delivered script: every step a live formula, inputs traced to page or cell, printed figures in blue beside computed ones with an agreement cell, recalculated in a second spreadsheet program.
- An evidence index, the audit log, and test, gate and mutation results.
- A README (setup, assumptions, how to extend), a handover note, and updates to our tracker in its fixed format.
Reports show proof (counts and diffs), not narration.
Toolkit: source, tests and documentation owned by us, the build procedure, and a handover session.
ACCEPTANCE
1. Every figure reproduces the audited case exactly.
2. Every test and gate passes from the package in an empty folder, standard library only.
3. The same inputs give identical outputs and audit log on every run.
4. Our edge and benchmark cases pass; every mutant is killed or explained.
5. The toolkit is accepted when someone other than its author builds an engine with it that passes every gate.
WHO WE ARE LOOKING FOR
One person or a small team (a mathematician, an auditor and a Python developer can bid together).
Past work (at least two; details after the NDA):
- Rebuilt another party's figures from source documents and raised findings that changed a reported number.
- Built a rules engine from a versioned rulebook (tax, tariff, actuarial, regulatory capital) that matched official figures exactly.
- Audited spreadsheet models: traced formulas, compared stored and recalculated values.
- Extracted data from thousands of documents with every value traced to its source.
- Mutation or property-based testing, a tamper-evident audit trail, or sensor data validation.
Must have: strong mathematics (exact arithmetic, rounding, floating-point pitfalls, statistics); an auditing background (financial, forensic, internal, quality or model audit); the patience to read long documents in full and stop at the first number that disagrees; strong, well-tested Python; document data extraction.
Nice to have: an accredited audit, inspection, certification or model-validation role (ISO 19011, ISO/IEC 17020, 17021, 17025, 17065, SR 11-7, GxP); engineering or physical science; event sourcing and hashing.
HOW WE WILL WORK
1. Screening on your answers; no domain details yet.
2. NDA and IP assignment: all work product belongs to us.
3. A paid pilot: one engine, accepted only against the criteria above.
4. A milestone contract, one engine at a time; each delivery is audited independently and paid on acceptance.
CONFIDENTIALITY
Specification, sample documents and benchmark cases are shared only after the NDA and IP assignment. Our materials stay in agreed systems, go to no third party or external service without written approval, and are returned or deleted at the end.
IN YOUR BID
LEDGER first, then a few lines on each:
1. Ten printed yearly figures add to 4,512,608; the printed total is 4,512,603. What do you do, and what would you never do?
2. Show where binary floating point and exact decimal arithmetic round differently, and how you prevent it.
3. A shortfall must be recovered before any later surplus counts. How does that survive separate runs, restarts and out-of-order processing?
4. Version 4 changes a factor, but older periods must still be checked under version 3. How do you structure the code?
5. How do you prove your tests catch a dropped term, and why does a test that fails only by crashing not count?
6. How do you prove a table, a footnote and a spreadsheet formula with its cached value were extracted faithfully?
7. Two documents print different values for the same parameter and period. What does the engine use?
8. Your audit experience: the kind, your role, how many engagements, and one finding that changed a figure.
If you live and breathe numbers and love proving your work, we look forward to hearing from you.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.