- Problem
- Clerks hold invoices the purchase order cannot explain, and spend the hours finding the clause in the signed contract.
- Decision
- Rules clear the record defects. A model inside the tenant may cite the clause, code checks the price, and a person releases every such payment.
- Outcome
- Fewer days on hold, the search hours returned, and no payment that cannot be tied to an order line or a cited clause.
The problem: invoices the order cannot explain
A supplier invoice arrives at a shared-service accounts payable desk. The ERP already holds the purchase order and the goods receipt, and runs a three-way match: order, receipt, and invoice must agree on quantity and price. When they agree, the payment posts on the ordinary run. When they do not, the invoice is held, and a clerk goes looking for the reason.
Most holds are defects in the record: a receipt never entered, an order number a character out, a price the buyer changed and never updated, a missing tax code. A reason code, a corrected order, or a chase to the plant clears them. No model is needed to notice that two numbers differ.
The holds that consume the desk are the other kind. The invoice differs from the order, up or down, because of a term in the signed contract that was never typed onto the order: indexation, a rebate, a volume break, freight, or an accepted substitution. Figure 1 shows one.
I will use two terms throughout. The passage is the exact sentence in the contract that explains the difference, clause 7.2 here. A clause type is a family of such terms: indexation, rebates, freight. The controller will not release the payment until the clerk has found the passage and can defend it.
The scenario assumes a multi-entity industrial manufacturer with one finance centre and ordinary audit obligations. It processes 200,000 supplier invoices a year, and 12 percent are held: about 24,000. About two thirds, 16,000, are record defects. About one third, 8,000, need a passage. At a median of 30 minutes each, finding passages takes about 4,000 hours a year: roughly 180,000 in the group’s reporting currency at an assumed fully loaded rate of 45 an hour. Record defects, at an assumed 15 minutes each, cost another 4,000 hours and another 180,000. These are planning figures, not measurements.
The outcome that would count is cost and risk: fewer days on hold, search hours returned, and no rise in payments the controller cannot defend. Money recovered from rebates the desk currently misses is not assumed. A pilot would have to count it.
Who decides, and who can stop it
Sponsors. The controller decides what may be released. The commercial director decides how a clause may be read. A design that satisfies only the queue will be stopped by one of them later.
Operators. Exception clerks work the hold queue. They need each item to say why it is held, and a citation that opens on the page it names. A senior clerk takes the uncertain items, so that queue has to stay small enough to be read properly. Suppliers feel the days on hold. Buyers feel the chase when their own order was wrong.
Can block. Internal audit, if a payment posts without a trail. Security, if a contract leaves the region or reaches a tool the group has not approved. Procurement, if the proposal skips putting new terms on the order.
Where they conflict. Accounts payable wants the queue to move. Audit wants a citation it can open next year. Commercial wants the meaning of a rebate to stay with the people who negotiated it. Procurement believes cleaner orders would make a model unnecessary. When speed conflicts with audit or security, audit and security win: an undefended payment or a leaked contract costs more than another day on hold. Commercial wins on disputes. Procurement wins on every contract not yet signed, and loses on the ones already filed.
What the desk must be able to do
Functions. Every hold says which kind it is. A record defect carries a reason code and a route back to the order, the receipt, or the supplier record. A clause hold carries the contract in force for that supplier and date, the cited passage, and a price that code has recomputed. The clerk can approve, edit, reject, or escalate to commercial. Clean matches keep posting exactly as they do today.
Controls. A payment posts only from the ERP, under the existing payment-run controls. Every payment that depends on reading a clause is released by a person. Contract text is processed only in the region where the contract store sits. Users sign in with the corporate directory. If the assistant is down on a payment-run day, the queue waits; it never falls through to an unreviewed post. The citation and the clerk’s action are kept as long as the financial record, because they are part of why the payment exists.
What stays. The ERP and the directory stay. A model gets no posting rights. New commercial terms are stored as data on the order or a contract schedule, so the same clause is not re-read every month.
Data. Invoice, order, and receipt lines are finance data, confidential, and needed for the check. The contract is commercial’s document, confidential, and needed only for a clause hold. Bank details and tax identifiers are needed for the payment run, not to explain a price, so a model never sees them. Mail may hold the history of a dispute. The clerk may open it; the model is not given it.
Does this need a model at all?
Five candidates sit in front of this desk: do nothing; a supplier portal with structured terms on new orders and reason codes for defects, with no model; more clerks or an outsourcer; the portal and rules plus a clause assistant on the remaining clause holds; and a model that releases payments on its own under a threshold.
Each is scored from 1 to 5. The column headings say which end is good. I do not add the columns up: a high value score does not cancel a risk the controller will not carry.
| Candidate | Value (5 = most) | Complexity (5 = hardest) | Data ready (5 = ready) | Risk (5 = worst) | Fit (5 = best) |
|---|---|---|---|---|---|
| Do nothing | 1 | 1 | 3 | 4 | 1 |
| Portal, terms on orders, reason codes | 3 | 3 | 2 | 2 | 5 |
| More clerks, or an outsourcer | 2 | 2 | 4 | 3 | 2 |
| Rules, plus a clause assistant | 5 | 4 | 3 | 3 | 5 |
| The model releases the payment | 3 | 4 | 3 | 5 | 1 |
Doing nothing keeps the hours, the undefended release, and the clauses pasted into a public tool. The portal is the best fit, because a term that can be typed onto an order should be, but it does not read contracts already signed, so its value is middling. Its data readiness follows the weaker half: new terms can be structured, the filed PDFs cannot. More people can read the file share today, which is why their data score is high, but an outsourcer also takes a copy of every contract. The combined path covers both kinds of hold; its cost is the contract corpus, the gateway, and the evaluation. Letting a model release payments turns a held item into money that has already moved.
So the model has one narrow job. Matching an invoice, chasing a receipt, and storing a term on a new order need no model. Keyword search does not answer the rest either: the clause is often a formula spread across a schedule, worded differently for each supplier. A model earns its place in finding the passage and reading its variables: which index, which dates. It has no place in the payment run, in a dispute about what a rebate means, or anywhere near a bank account.
A model that pays an invoice has answered a different question from the one the controller asked.
The desk today
The group is not a blank sheet, and the match is not the broken part. The ERP performs the three-way match and posts what clears it. Everyone signs in through the corporate directory. There is no approved service that reads a contract.
Contracts. Signed contracts are PDFs on a file share owned by commercial. A renewal, an amendment, and a scanned schedule for one supplier can sit in three folders, sometimes under the buyer’s name. Validity is a date inside the file, not a field anyone can filter on.
Mail and notes. A buyer confirms a substitution in a thread that never reaches the hold. When the clerk escalates, the answer comes back as a sentence with no page, pasted into a free-text reason. Each clerk keeps a note of how a frequent supplier’s indexation “actually” works. That note is the desk’s only shared definition, and it leaves when the clerk does.
Unsanctioned tools. Some clerks paste a long schedule into a public chat tool to get a summary. Nobody approved it, and nobody can say afterwards what text left the building.
Three things are missing: a split between the two kinds of hold, an owner who treats contracts as data rather than folders, and a stored citation. Until a month of holds is classified, the 16,000 and 8,000 in the opening remain a planning split, not a count.
The desk after the change
The target changes each gap above and leaves the match alone.
| Today | After |
|---|---|
| One queue of 24,000 holds | Every hold is classified; defects get a reason code and never reach a model |
| Contracts are folders | Commercial owns them as data; each is linked to its supplier and validity dates |
| The answer is a free-text sentence | The passage and the recomputed price are stored with the payment |
| Private notes define indexation | The cited clause is the definition, invoice by invoice |
| Clauses pasted into public tools | One route to a model, through the gateway, inside the hold queue |
| Release on a sentence | Approve stays off until the clerk has opened the passage |
Owners. The controller owns release. The commercial director owns what a clause means, and the contract data. Security owns what may pass through the gateway. The shared service runs the queue. The integration team runs the gateway and the recomputation, on a runbook the controller can read.
The gateway. The gateway is the only route to the model. For each hold it builds the packet: the invoice, order, and receipt lines, and the one contract in force for that supplier and date. Nothing else goes in. A clerk sees holds only for the entities they already post for, and the packet is built within that scope. The model runs inside the group’s own cloud tenant, and its service account cannot post, read bank details, or open mail.
Measures. Days on hold, the share of releases where the passage was opened, and the rate of wrong-contract proposals are reported separately for the two kinds of hold. Model calls are costed per clause hold, against the search hours those holds used to take.
Four ways to read the clause
The portal and reason codes are already chosen for defects and new terms. What remains is how to read the contracts already signed. Four options were real. Each is priced against the 8,000 clause holds, not against all 200,000 invoices.
| Option | Cost | Risk | Data | Lock-in |
|---|---|---|---|---|
| Wider tolerances in the ERP | Configuration only | Pays differences no clause supports | Stays in the ERP; the PDF is never read | The match engine, which cannot cite a page |
| A specialist accounts-payable suite | A second integration; a subscription on all invoices | A second ledger, with a vendor in the payment path | In the vendor’s cloud unless it runs in the tenant | Queue, extraction, and workflow leave together |
| A narrow assistant beside the ERP | A gateway, a review panel, model calls | A wrong citation, caught before release | Tenant only; bank details removed | The model is swappable; the corpus and citations stay |
| The model posts under a threshold | The same, plus posting rights and reversals | A wrong answer becomes a paid invoice | The model’s identity touches the payment run | Turning it off admits unreviewed payments |
Wider tolerances in the ERP
The ERP can treat any difference under a percentage as close enough. It is cheap, the contract never moves, and clerks stay on the screen they know. But a tolerance cannot tell indexation from a duplicate charge. Set wide, it pays differences no contract supports; set narrow, the 8,000 holds remain. I would allow a small tolerance for rounding, and nothing more.
A specialist accounts-payable suite
In this scenario, the products a sponsor is shown extract contract terms and bring their own exception queue. The build is the integration back to the ERP. The objection is the pricing base assumed in the offer: a subscription on 200,000 invoices to solve 8,000. That is an assumption about the offer, not a surveyed price, so a real quote comes before anyone rejects it on cost. The same offer reads contracts in the vendor’s cloud, which fails residency unless the product runs in the group’s tenant, in region, with a bar on training. I would reopen this only for a tenant deployment priced on the clause holds, with posting still in the ERP.
A narrow assistant beside the ERP
This is the path in Figure 3. The gateway builds the packet, the model returns the passage and the variables it read, and code recomputes the price, exactly as in Figure 1. The clerk sees all three on the hold they already open, and the ERP posts only after they approve. The build, as a planning assumption, is two engineers for a quarter plus commercial’s time to link the indexation contracts. At an assumed 2 currency units a call, 8,000 holds cost about 16,000 a year, against about 180,000 of search on the same holds; neither figure is the pilot’s payback, because the pilot covers only part of that book. A quote replaces the unit price before approval. A wrong passage is caught by the recomputation, the trap tests, and the person who releases.
The model posts under a threshold
The same assistant can be given posting rights, so a confident item under a set amount pays itself. The model’s service account can now move money, and the controller will want every such payment sampled, which recreates the desk under another name. Switching it off later means admitting a period of payments went out unreviewed. A sponsor will be offered this option. The failure the controller fears is its ordinary bad day.
The decisions that are expensive to reverse
Decision 1: The ERP remains the only system that posts
| Context | Holds exist so a difference is explained before money moves, and audit will sample that explanation. |
|---|---|
| Decision | The ERP remains the only system that posts a payment. The assistant never posts. |
| Options considered | All four options above. |
| Deciding trade-off | An audit trail in the system that already holds financial control outweighs the speed of a tool that would become a second ledger. |
| Consequences | Release stays a step clerks already understand. The assistant is a new component to own, back up, and evaluate. Any vendor that insists on sitting in the payment path is out. |
A suite that posts creates a second place where “paid” can be true. Reversing that a year later means working out which ledger was right.
Decision 2: New terms go on the order; the model reads only signed contracts
| Context | Most future differences between order and invoice are terms someone could have typed onto the order. |
|---|---|
| Decision | New commercial terms are stored as data on the order or a contract schedule. The model reads only contracts already signed, and only clause types that cannot yet be structured. |
| Options considered | The portal without a model, a model without the portal, and both. |
| Deciding trade-off | Procurement’s simpler fix is taken where it works. Pretending it clears PDFs already filed would leave the 8,000 holds in place. |
| Consequences | Commercial and procurement owe a change to how new contracts are coded. The model’s workload should shrink as that change lands. |
If new indexation still arrives as a PDF in five years, the assistant has become a permanent clerk. The measure I would put in front of the sponsor is a falling share of holds that need a citation, not a rising count of model calls.
Decision 3: The model runs in the tenant, on a narrow packet
| Context | The text that explains a price is the text the group can least afford to lose: contracts, prices, quantities. |
|---|---|
| Decision | The model runs in the group’s tenant, on the invoice lines and the one contract in force. Bank details, tax identifiers, and correspondence stay out. |
| Options considered | A vendor’s cloud, the tenant assistant, and the public chat tool clerks already use. |
| Deciding trade-off | A data boundary is expensive to tighten once clerks depend on a tool that was allowed to see too much. |
| Consequences | The gateway becomes a control with an owner for its packet definition. Model choice is limited to endpoints that run in the region. Pasting into a public tool becomes a policy breach, not a grey area. |
I would delay the pilot rather than use an endpoint that keeps prompts or trains on them. Anything in a prompt beyond the packet is a defect in the gateway.
Decision 4: A person releases every clause-based payment
| Context | The controller’s standard is a payment they can tie to an order line or to a clause they can open. |
|---|---|
| Decision | A person releases every clause-based payment by approving, editing, rejecting, or escalating. A confidence score only sorts the queue. |
| Options considered | Human release, and automatic release under a threshold. |
| Deciding trade-off | The hours worth saving are search hours. The minutes spent judging were never the waste; they are the control. |
| Consequences | Approve is disabled until the passage has been opened. Low confidence, a failed recomputation, or no passage found goes to a senior clerk, who has to be staffed. A dispute goes to commercial. |
A confident answer on the wrong contract is the failure that hurts. A hesitant one left with a senior clerk costs minutes. The design spends the minutes.
A pattern for holds a document explains
The pattern is for any operation that already matches a transaction to a record but still holds a remainder, because the reason lives in a document the system of record does not store. Invoice against order is this case. The same shape appears wherever a clerk leaves the system to find a clause, a tariff, a policy wording, or a side letter, then types a sentence back into a free-text field.
It is the wrong pattern when the match itself does not work, when most holds are record defects, or when the organisation wants the model to post, approve, or decline. Fix the record first. A small, stable remainder needs a person and a template. A document that is already structured should simply be stored as fields.
Data flow. The system of record raises the hold (step 1). Rules classify it (step 2); a record defect is fixed where it lives and never builds a packet. A document hold goes to the gateway, which builds the packet from the transaction lines and the single document in force for that party and date (step 3). The model cites a passage and reads its variables (step 4). Code recomputes the figure (step 5). A person opens the passage and decides (step 6). The system of record posts and keeps the passage, the figures, and the decision for as long as the financial record (step 7).
Identity. Only someone who may already release a transaction can invoke the assistant for it, within the same entity scope, from the directory already in use. The model’s service account reads only the packet. It cannot post, read payment details, or browse the document store.
Sensitive data. Bank details, tax identifiers, and correspondence are removed before the call; none of them changes the arithmetic. Packet logs are kept in the same class as the contract. Public tools are not a route, and a vendor cloud is acceptable only if it runs in the same region.
Model and cost. One general-purpose model sits behind the gateway and can be swapped. Fine-tuning waits until confirmed citations exist and a clause type has failed the general model. Run cost is the calls on document holds only, replaced by a quote before anyone relies on it. The expensive part of the build is linking each document to its party and validity dates.
Trade-offs and conditions. The pattern accepts a slower release than an automatic post, a permanent human step on the document path, and upfront work on the documents. Use it when clean transactions already flow, a document explains the rest, and a wrong automatic release is unacceptable. A few hundred document holds a year calls for a senior clerk and a naming standard for the files instead.
The same pattern, on the platform chosen
Figure 5 builds it on Azure and Microsoft Foundry, with the step numbers of Figure 4. The ERP, the payment run, and the contracts stay in the finance centre. Azure is where the packet is built and the passage is cited.
The finance centre and the door. The ERP publishes the hold, the invoice, the order, and the receipt, and it accepts the release back. It does not publish the payment run or a bank file. A self-hosted integration runtime copies the contracts in force, one clause type at a time, each night. Clerks reach the panel only from the finance network. All of it crosses one site-to-site VPN into a hub with Azure Firewall and no route to the internet. At about 8,000 clause holds a year, ExpressRoute would cost more than it carries, unless the group already runs one.
The spoke. The review panel runs on App Service behind a private endpoint, with public access off and Entra ID as the only sign-in. API Management is the single front door to the ERP. It can read a hold and write the release. It has no payment operation. The orchestrator, on Azure Functions, builds the packet, asks the model to cite the passage, recomputes the price in code, and writes the decision back. A call that fails waits. It does not post.
AI and data. Document Intelligence turns each contract, scans included, into pages and positions, so the citation can open on the page. AI Search indexes only the contracts in force, by supplier and validity, which is how the gateway chooses the one document. The model deployment in Foundry receives that document and no other, does no arithmetic, and is not trained on the packet. The evidence store keeps a copy for the monthly sample. The record a controller defends stays on the ERP. Prompts are not retained for training.
Cost. The VPN gateway, the firewall, the search service, and the panel bill every hour of the year. The model runs on the clause holds, about 8,000 times on the planning figures and fewer in the pilot. The quote has to price both. A shared hub, if the group already has one, removes the largest of those standing costs.
What is funded first
Value arrives twice: once for record defects, before any model is switched on, and once for indexation, in the pilot, after the test has been passed. Figure 6 shows the sequence and the two points where the programme may stop.
| Phase | Scope | Depends on | Risk | Value |
|---|---|---|---|---|
| Foundation | Classify a month of holds. Baseline days and hours. Name a contract owner. Stop the public paste. | Controller and commercial director agree the two kinds of hold | The planning split of 16,000 and 8,000 is wrong | A real count. No model. |
| Rules and portal | Reason codes, a correction route for defects, structured terms on new orders | The baseline; a way to store reason codes without waiting for an ERP release | Clerks ignore the codes | Fewer days on defect holds: the first business value |
| Corpus and build | Indexation contracts for one entity, linked to supplier and dates; the gateway and review panel | A commercial owner for the contracts | Amendments and scans missing, so the corpus looks complete when it is not | None yet. This phase ends at a gate. |
| Pilot | Indexation, one entity, a person releases, twenty confirmations sampled a month | The test set passed, including the traps | Clerks approve without reading; the disabled button has to be tested | Fewer days and search hours on indexation holds |
| Scale | Rebates, volume breaks, freight, substitutions, one at a time | Each clause type passes its own test | A failing type is forced live because the programme has momentum | Only for the types that passed |
Indexation goes first because its arithmetic can be checked in code, as in Figure 1. A rebate written as a negotiation waits; commercial would be on the escalation path from day one. If the foundation count shows only a few hundred clause holds, stop after the rules and the portal.
What may be read, and who still releases
Who may use what. Clerks may use the assistant inside the hold queue, and only on clause holds. Commercial managers may open the citation on an item escalated to them; they do not get a window onto the whole contract store. No one may paste contract text, invoices, or supplier data into a public tool.
What may enter the model. The invoice, order, and receipt lines that explain the difference, and the one contract in force. Never a bank account, a tax identifier, a mail thread, or a second supplier’s contract. Nothing trains a public model, and prompt retention is off.
Where a person decides. Approve: the clerk has opened the passage and accepts a price code has already recomputed; the button stays disabled until the passage is opened. Edit: the clerk corrects the passage or a variable, the change is stored, and the price is recomputed before approval. Reject: not payable on this clause; the invoice stays unposted, and it is not written off. Escalate: commercial owns the meaning. The model never closes a dispute or drafts the reply to the supplier.
A confidence score sorts the queue. It does not release the payment.
Testing and monitoring. A clause type goes live only after passing the evaluation below. After that, the controller reviews twenty confirmations a month against the cited passage, with scanned schedules and several suppliers in every sample. Security reviews the packet definition twice a year and after any change. Audit can open, for any clause-based payment, what was shown, what was edited, and who approved it.
Bias. The model does not rank people, suppliers, or countries, so a review of personal traits would have nothing to examine. The real risk is a systematic miss on image-only schedules: one supplier’s invoices stay held while an unstratified sample looks fine. If misses concentrate on scans, that clause type stays with the clerk until the documents are fixed. The controller owns this check.
| Document | What it rules |
|---|---|
| Acceptable use | The hold queue is the only place a contract may be summarised; named public tools are forbidden |
| Approval procedure | Clause-based release is a human action in the ERP; confidence only sorts the queue |
| Human-in-the-loop standard | What approve, edit, reject, and escalate mean, and the disabled approve button |
| Security baseline | The packet, the region, the service account, log retention |
| Model evaluation standard | The test set, the traps, and the stop rule |
What a model must pass before it runs
The evaluation is for the indexation assistant, against the requirements above, not against a public leaderboard. It has three stages: eligibility, hard gates, then weighted scoring among the candidates that survive.
| Candidate | Runs in tenant and region | Stays out of the payment path | Eligible now |
|---|---|---|---|
| General-purpose model behind the group’s gateway | Yes | Yes | Yes |
| Specialist accounts-payable suite | Only with a tenant deployment | No, in the usual product | No |
| Model fine-tuned on the group’s clauses | Possible | Yes | No: the confirmed passages it would learn from do not exist yet |
The suite fails because posting stays in the ERP and no tenant deployment is assumed. The fine-tune fails because confirmed passages are an output of the pilot, not something to build by hand first. It remains an option later, for a clause type the general model keeps missing.
The test set. Being eligible does not switch a candidate on. It has to pass a set built from this desk’s own holds.
| Items | Count | Passing means |
|---|---|---|
| Past indexation holds, passage marked by a senior clerk | 300, of which 30 are scanned | At least 85 percent found, and the scans pass too |
| Holds where no clause applies | 40 | “Not found”; one invented clause fails the candidate |
| Planted: the wrong supplier’s contract in the packet | 20 | Refused, every time |
| Planted: the only schedule has expired | 20 | Refused, every time |
Hard gates. Any citation from a planted trap, or any invented clause, disqualifies the candidate. So does a pass rate that holds on digital pages but fails on scans: an average would hide the supplier whose schedules are images. A missed passage that leaves the invoice held is acceptable; it costs the clerk the search the system was meant to shorten.
Weights. Among candidates that clear the gates: the correct passage in the contract in force, 40; variables read correctly (which index, which dates), 30; cost per hold, 15; fit to the existing queue and a clean exit, 15. The model is not scored on arithmetic, because code does the arithmetic. A cheap candidate that fails a gate never reaches the weights.
After go-live. Every clause-based item still reaches a person. More than one wrong-contract proposal in a month, or any that a clerk approves, switches that clause type off until the documents or the gateway are fixed. A model that tries to settle a dispute is a defect. Viability means an endpoint in the region, a contractual bar on training, and an exit that changes the endpoint without moving the stored citations.
What a sponsor can fund
Recommendation. Fund the classification and the rules now. Fund an indexation pilot only after one entity’s contracts are linked and the test set has been passed. Do not fund a model that posts payments.
The cost of today. On the planning assumptions, clause holds take about 4,000 hours a year, near 180,000 at the assumed rate, and record defects another 180,000 that a model will not touch. The exposure is payments supported by a free-text note, and contract text already leaving through a public tool. No rebate recovery is claimed; if the pilot finds money the current reading missed, it is reported when counted.
What is bought. Reason codes and a correction route; structured terms on new orders; and, for indexation, a gateway in the tenant that cites the passage while code recomputes the price. A clerk releases; the ERP posts. The investment is configuration and a commercial process change first, then two engineers for a quarter, commercial time to link one entity’s contracts, a monthly sample of twenty, and model calls at a price confirmed by quote.
Return. Defect hours fall in the rules phase with no model at all. Clause hours fall only as search avoided, on the piloted clause type and entity, and a person still opens every passage. I would not quote a payback for the assistant until the foundation count replaces the assumed 8,000 holds and 30 minutes. If that count is a few hundred, stop after the rules and the portal.
| Risk | Mitigation |
|---|---|
| Clerks approve without reading | Approve stays off until the passage is opened; twenty confirmations sampled a month |
| The wrong contract is linked | Planted traps in the test; one live wrong-contract proposal in a month switches the clause type off |
| A reading is disputed | Escalated to commercial; the model does not settle it |
| New terms still arrive as PDFs | Counted as a miss for the portal, not as demand for more model |
| The senior clerk role is not staffed | Staffing is a condition of the pilot approval |
People. Clerks stop keeping private notes and stop pasting clauses into public tools. They do not stop releasing payments.
Measures. Days on hold and search hours, reported separately for defects and clause holds, plus the wrong-citation rate. Defect days move in the rules phase; indexation days move in the pilot. The decision in front of the sponsor is whether to fund that sequence, including the right to stop when the count does not justify the assistant.