The Obligation Ledger — RFP, Bid & Tender Compliance

Your bid reads beautifully. It answered eleven of the sixteen things the tender actually asked for.

Nobody notices, because nothing in the response looks wrong. There is no red text, no gap on the page, no missing section. The requirement is simply somewhere in the tender, and nowhere in the answer, and the document that would have told you is the one nobody read twice.

There is one question that finds all of it in about ninety seconds. Point at where requirement 5.1 is answered. Not "it's in the delivery section" — point at the sentence. If you have to go and read first, it is not answered. It is hoped.

The Obligation Ledger is a SKILL.md agent skill that makes your agent unable to skip that question.

---

The real problem is ordering, not effort

Ask any capable AI agent to "write a response to this RFP" and it starts producing persuasive prose from the first token. That single default causes everything that follows. Because drafting happens before extraction, the shape of the response is invented by the writer instead of derived from the tender. Compliance then becomes a review step applied to a structure that was never built to hold it.

This is why diligent people produce the same failures as careless ones — they just produce them more fluently, which makes them harder to see. Three consequences, in the order they appear:

• Obligations with no home. A binding requirement exists in the tender and has no corresponding location in the response.
• Answers that read well and do not respond. More dangerous than an omission — an omission shows up on a checklist, a non-responsive answer does not.
• Effort spent where the writer is comfortable. Word count follows confidence, not the published evaluation weightings.

Extraction is not the hard part. A good model will list the mandatory requirements in an RFP perfectly well, and this listing will not pretend otherwise. The hard part is refusing to write until the list is closed — and a single prompt cannot enforce that, because drafting is the model's strongest and most-rewarded behaviour.

---

What the skill actually does

It turns a tender into a ledger: one row per atomic obligation, twelve fields per row, each row carrying a verbatim quote and a locator precise enough for a stranger to find in one move.

Then it does the thing that makes it a mechanism rather than a checklist: it will not let drafting begin until the ledger is closed and the pass/fail gates are resolved.

What you get back

• The Obligation Ledger — every atomic requirement, quoted verbatim, classified GATE / SCORED / ADMIN / INFO, weighted, located, evidenced and owned.
• The Gate Sheet — every pass/fail requirement resolved MET, MET-CONDITIONAL or UNMET, each with a remedy, a date and an owner. The go/no-go conversation on one page.
• The Orphan List — every obligation the tender makes that your planned response does not contain. Produced before drafting. Frequently the most valuable thing in the run.
• An effort allocation — the page or word budget distributed by published weighting, with the arithmetic shown, so drift is visible instead of arguable.
• A drafted response, section by section, where every passage names the ledger rows it satisfies and every claim declares an evidence type.
• The Point-At Audit — ten checks, one hundred points, hard caps, and a stated verdict.

---

The nine stages, and where the hard stop is

Five of the nine stages complete before a single sentence of the response is written. That is the part an unassisted agent skips entirely.

#StageExit test it must pass 1Close the source setEvery pack document listed with a version or issue date — instructions, specification, criteria, terms, forms, schedules, appendices, and every addendum 2Extract verbatimEvery row carries a non-empty verbatim quote and a resolving locator. Zero paraphrase 3Split to atomicNo row can be "partly" satisfied. Compound requirements are split into individually checkable rows 4Classify and weightZero unclassified rows. Every scored row carries a weight or an explicit not published marker 5The gate checkpoint — hard stopZero unresolved gates. If any gate is UNMET the pipeline halts and returns a no-bid recommendation. It does not proceed to drafting 6House every obligationZero rows with an empty Location field. Countable, so it cannot be fudged 7Allocate effort to weightingsThe allocation sums within the stated limit and the arithmetic is shown 8Draft against the ledgerEvery passage names its row IDs. Every claim carries an evidence type — or an openly declared gap with an owner 9Reconcile and auditThe response is read against the ledger, not against itself. The audit is scored and a verdict issued

Why stage 5 is a stop and not a warning. A warning gets overridden by optimism under deadline pressure. The whole value of that checkpoint is that it happens before sunk cost exists. Once someone has written twelve pages, the no-bid conversation becomes a different and much harder conversation — and the honest answer quietly stops being available.

The decision belongs to you, not to the agent. The mechanism's job is to put it in front of you at the only moment it is cheap.

---

The Point-At Test

Take any obligation. Point at where it is answered.
If you cannot point, it is not answered.

Run on a single row, it has three parts and all three must pass:

1. LOCATE — name the exact section that satisfies this row. Not "the security section". Precise enough that a stranger finds it in one move.
2. QUOTE — read out the specific sentence that satisfies it. If satisfying it requires reading the whole section and inferring, that is an Echo.
3. EVIDENCE — name what backs the claim. "It's implied" is not evidence. "We said we would" is not evidence.

On a full response it runs against 100% of gate rows and a minimum of 25% of scored rows, highest-weighted sections first. Any failure escalates that section to 100%.

The test needs no domain expertise, no writing skill and no knowledge of your business. It needs the ledger and the ability to ask "where?" — which is exactly why it works when the person asking did not write the response.

---

Eight named defects

A defect with a name gets found. A defect without one gets rationalised. The audit tests for all eight.

CodeDefectWhat it looks like D1OrphanA binding obligation with no location in the response at all D2EchoThe requirement restated in your voice, confidently, without satisfying it D3FragmentA compound requirement where some sub-asks are answered and others are not D4AssertionA capability claim with no named evidence behind it D5DriftEffort allocated by the writer's comfort instead of the published weightings D6BreachPage limit, font, file naming, required form, signature or deadline violated D7GhostA cross-reference that does not resolve — "see Appendix D", and there is no Appendix D D8StaleContent reused from a previous bid that answers a different tender's requirement

D1, D3 and D6 are countable. D2, D4, D7 and D8 require reading against the source. D5 requires arithmetic. The audit tests all three kinds.

---

The audit fails things — including the good one

Ten checks, one hundred points. The score measures the quality of the process. The caps govern whether the thing can be submitted. A response can score in the nineties and still carry a DO NOT SUBMIT verdict, and that is the audit working correctly.

TriggerEffect Any fabricated evidence foundScore 0. DO NOT SUBMIT. Absolute, no exceptions Any gate row UNMETDO NOT SUBMIT, whatever the score Any gate row untested at submissionDO NOT SUBMIT, whatever the score Any Orphan on a gate or scored rowScore capped at 60 Any Breach on an administrative rowScore capped at 75

Caps are applied after scoring and stated alongside the score — never silently folded into it. The audit always names the specific failing row IDs, because a score without the rows behind it is a number, not an audit.

The four illustrative benchmarks included in the package were built to be failed. In the strongest of them the corrected response still loses points on three checks and finishes with two open owner actions. Gaps become named; they do not vanish.

---

Who this is for

• Bid and proposal managers running public-sector tenders, framework calls or mini-competitions where compliance is pass/fail before quality is ever read.
• Founders and consultants answering enterprise RFPs and security questionnaires without a bid team behind them.
• Agencies and professional-services firms responding to weighted evaluation criteria, where effort routinely lands on the wrong criterion.
• Grant writers facing eligibility screens that reject applications before anyone reads the case.
• Capture and pre-sales leads who need a defensible bid / no-bid recommendation in an hour rather than a week.
• Anyone who has lost on compliance and been told the submission was strong.

What people actually use it for

• Triage before committing. Run stages 1–5 on a fresh pack and get a gate sheet the same afternoon. Bid or walk away, on evidence.
• Auditing a draft someone else wrote. Point it at an existing response and get the orphan list, the defect list and a scored verdict.
• Catching the addendum. Late clarifications introduce obligations that the original plan cannot contain. Closing the source set is stage 1 for exactly this reason.
• Settling the length argument. An allocation table with the arithmetic shown ends the "this section needs more space" debate in one screen.
• Pre-submission sign-off. A named, capped, row-level verdict instead of "I think we're good."
• Re-testing reuse. Content carried from last year's bid is re-tested against this tender's rows. Topic similarity is not compliance.

---

What makes it different

The honest version of this argument, because the weak version is the one that gets refunded.

A good prompt genuinely can extract the mandatory requirements from an RFP and list them. That works. Anyone claiming otherwise is selling something.

What a prompt cannot do:

1. Enforce ordering across a long piece of work. The value is that stages 1–5 finish before stage 8 begins. A prompt has no way to stop the model drifting into drafting.
2. Hold a stable artifact across turns. The ledger is a persistent structure with a status ladder that survives revision, re-scoping and addenda. A prompt produces an output; this maintains state.
3. Produce a hard stop. Refusing to write the bid is the least likely thing an unprompted model does — and it is the highest-value moment in the entire workflow.
4. Supply codified judgement. Sixteen rulings on ambiguity, contradiction, should versus shall, appendix requirements, superseding addenda, expired certificates and confidential evidence. None of that is derivable from the request.
5. Audit itself against a cap rule. A model reviewing its own work grades generously. The caps are what make the audit adversarial.

The claim, stated exactly: the value is in the ordering, the persistent artifact, the hard stop, the codified judgement and the capped audit. Not in the extraction. The extraction is the easy part.

---

Safety and honesty boundaries

These are design decisions, not a disclaimer bolted on the end.

It will notWhy Invent evidence — no certification, client, metric, reference or past-performance claim you did not supplyA fabricated claim in a submitted bid is a commercial and potentially legal catastrophe. Absolute, under any instruction or deadline Give legal or procurement adviceRules vary by jurisdiction, sector and framework. This reports what the document says and where the response answers it. Interpretation belongs to a qualified professional Make a non-compliant response look compliantThat is the inverse of the product. A gap gets declared, dated and owned — never dressed Assist bid rigging, collusion or cover pricingIllegal in most jurisdictions and outside any legitimate use Write a specification designed to exclude competitorsIt works for bidders, not against other bidders Process another bidder's confidential materialIncluding leaked submissions and confidentially obtained pricing Submit anything, anywhereNo portal, no upload, no send. You press the button — which is also why it needs no network access Source tenders or maintain a content libraryIt is a discipline, not a database

A refusal returns a reason and a next step, not a wall.

Permissions — the minimum, and nothing beyond it

It reads the documents you give it and writes the outputs you ask for. That is the entire footprint.

• No shell, no terminal, no execution. Nothing in the pipeline is computational beyond arithmetic.
• No network requests. Tender packs are frequently confidential and commercially sensitive. Nothing leaves your environment.
• No credentials or environment variables. Never read, never requested.
• No browser, no portal access, no upload.
• No scripts ship in the package. There is nothing in it to execute. It is all text.

---

What is included

FileWhat it carries SKILL.mdThe nine gated stages, the non-negotiables and the refusal policy references/defect-taxonomy.mdEight named defects, how each is detected, and what produces it references/ledger-schema.mdTwelve fields, the status ladder, and the two derived views references/decision-table.mdSixteen rulings on ambiguous, contradictory and superseded tender language references/point-at-audit.mdTen checks, the exact scoring rules, the caps and the verdict bands references/worked-examples.mdFour illustrative scenarios, before and after, with the arithmetic shown assets/ledger-template.mdThe blank ledger, ready to fill assets/gate-sheet-template.mdThe pass/fail sheet that clears before drafting assets/point-at-audit-template.mdThe blank scorecard, caps included evals/Four re-runnable evaluations and a behaviour test sheet covering triggering, extraction, splitting, gating, evidence handling, auditing and refusals README.mdInstallation for Claude Code, Codex CLI, Cursor, Gemini CLI and VS Code Copilot, plus a first-run walkthrough

---

Known limitations — stated as plainly as the promises

• It does not win bids. It removes one class of reason to lose. Price, incumbency, relationship, capability and timing are all still yours.
• It cannot read what you do not give it. A missed addendum is still a missed addendum. Stage 1 asks for the whole pack precisely because this is the failure mode.
• The score measures your process, not the buyer's opinion. A clean ledger is not a contract.
• Ambiguity is surfaced, not resolved. Where the tender is unclear it writes you a clarification question rather than guessing on your behalf.
• Scanned or image-only PDFs depend entirely on your agent's own file-reading ability. If the agent cannot read the text, the skill cannot extract it.
• Very large packs are worked in sections. The ledger is designed to survive that, but a thousand-page framework is several sittings, not one.
• Every benchmark in the package is authored and illustrative. No real tender, authority, bidder, funder or client appears anywhere in it, and no customer results are claimed.

---

The bottom line

Most bid tooling helps you write faster. This one starts by telling you what you are not allowed to write yet — and occasionally by telling you not to write the thing at all.

That is an uncomfortable product. It is also the one that finds requirement 5.1 while there is still time to answer it.

Ledger before prose.