FieldLedger, the first portfolio audit.

FieldLedger is a Startvest LLC product. Operations and compliance tooling for federal contractors and construction businesses — DCAA cost accounting, Davis-Bacon certified payroll, FAR 31.2 indirect rates, ICE I-9 tracking, audit log. Tier-priced subscriptions. Customers pay for the tooling; third parties (DCAA, DOL, prime contractors, IPAs) verify outputs. FieldLedger does not issue any third-party certifications.

Audit conducted 2026-04-28. Methodology: a qualitative pass by Claude Code against FieldLedger's code, INTEGRITY.md, and methodology page; a mechanical pass by integrity-cli (base manifest) against the public repo. The two passes are cross-checked: where the CLI flagged a finding, the qualitative pass verified it against the actual code. Where the qualitative pass flagged a finding, the CLI was checked for whether it should have caught it.

Layer 1 is fully clean — six pre-build vetoes pass without exception. Layer 2 has three open items, two of them pre-Plus-tier (auditor-readonly role, 7-year DCAA retention policy) and one pre-launch (UI badging on customer-attested fields). Layer 3 has two needs-update items (refund clause, formal whistleblower channel) plus one honestly-deferred item (annual third-party audit, funding-blocked).

The FieldLedger team's self-assessment was honest. The audit confirmed the INTEGRITY.md as written; no surprises in the product. The interesting findings were elsewhere.

The most important outcome of this audit was not a product finding. It was two findings against the framework's own rule set.

The first integrity-cli run flagged three failures. Two of them — the most important ones — were false negatives in the rules, not gaps in the product. They tripped because the base manifest's filename-based globs targeted a hypothetical layered architecture that didn't match FieldLedger's actual code layout (libraries that compute output, with persistence and markers attached at the schema and route layers).

A rule that produces a false negative is silent-pass at the meta level — exactly the failure mode the framework prohibits at the product level.

So the rules were revised, not the product. The fix: a new content-based co-occurrence check kind that looks for required markers anywhere in the corpus, rather than requiring them to appear in specific filename patterns. Two manifest revisions, each with a changelog entry that points back to this audit.

The third initial finding — INFO-FL-TRUST-PRINCIPLES-LINK — was a real Layer 3 discoverability gap on the FieldLedger privacy page. Not a rule issue. Tracked as a P2 remediation ticket.

The framework was calibrated against zero real products. First contact with reality found two filename-based blind spots. They are now closed in base manifest v1.4.0, and the lesson carries forward to every subsequent product audit.

The audit produced a remediation backlog. Eight items, three priorities:

All items are tracked in the FieldLedger repo under the tif-compliance label. The matrix at audits/tif-compliance.md cross-references every item to the specific code path or contract clause that closes it.

1. The framework adapts when reality finds a gap. Two manifest revisions in one audit cycle, both pointing back to this case study, is not the framework failing. It's the framework working — failure transparency applied to itself.
2. Filename-based rules don't survive first contact. The original Layer 2 rules assumed a particular code layout. Real products have other layouts. The new co-occurrence pattern is more robust because it asks “does the marker exist anywhere in the corpus that needs it” instead of “does the marker exist in this specific filename pattern.”
3. Honest self-assessment + qualitative + mechanical is the right combination. FieldLedger's INTEGRITY.md was honest before the audit. The qualitative pass verified it. The mechanical pass found two cases where the rule set was wrong. Any one of those three alone would have missed the rule-set bug. Together they caught it.
4. The remaining open items are the kind a framework should produce. MSA refund clause, 7-year retention policy, UI badging, formal whistleblower SLA, annual third-party audit funding. None of them are technically heroic; all of them are the kind of work that gets put off without a forcing function. The framework IS the forcing function.

• 2026-04-28 — v1.0. Initial publication. Second case study under The Integrity Framework v1.0. First internal portfolio audit.