AI analysis a committee can check.

A fund house that invests in other managers’ funds receives marketing documents: pitch decks, offering memoranda, fact sheets. An analyst reads each one and decides whether the manager deserves further diligence. This is a working prototype of a system for that first screening. It is not a client deployment.

The operation, and what it has to control

The premise of the design is that screening is limited by reading time: documents arrive faster than they can be evaluated consistently, and the quality of a screening decision depends on which analyst happened to read the deck.

A language model can read a deck and write a memo in minutes. That does not help a committee unless each sentence can be checked: where a quote came from, which rule produced a finding, and what the document did not say. What has to be controlled is not the reading. It is the evidence behind every statement, and the rules the fund was judged by.

What we built

There are two parts. The analysis engine takes a document and a set of criteria and produces a scored, twelve-section memo with its evidence. The management system, built on Phlo, holds the documents, the criteria, the runs, the memos and the decisions. A worker passes jobs between them and reports each finished stage back as an event.

What is prototype, plainly. The engine works and has been run on its own on a real fund document. The management system’s backend is built and can record every step as an event, but no real document has yet been recorded passing through it from start to finish. Its screens are mostly read-only: an analyst can read a memo, follow a run and see a criteria set. Recording a triage decision is the only action wired in the browser. Uploading, promoting a document to a deal, authoring and activating criteria, marking sections reviewed, overriding a finding and exporting are not yet available in the browser. The register lookups are partly built. A loop for answering the memo’s open questions and comparing versions is designed, not built.

How a document moves through it

1. Intake. A document is stored under the hash of its contents, so the same deck arriving twice is recognised. Promoting a document to a deal is always a person’s decision.
2. Claim. A worker claims the queued run. The criteria set handed to the engine is recorded with its hash.
3. Five stages. Classification, extraction, diligence, scoring and memo. Each finished stage is an event on the deal, so a run is followed stage by stage.
4. Review. The analyst reads the memo, with each finding attributed to the rule that produced it.
5. Decision. The analyst records pursue, hold or pass, with a written rationale. A hold needs a revisit date and a condition.

What the first build described

A prototype is still a first build in one respect: it had to describe the screening operation before anything could be scored. The description below is what the management system’s events are made of. Most of these events exist in the backend only. Recording a triage decision is the one action wired in the browser.

• The things tracked. The document. The deal, which is the fund being evaluated, created when a person promotes a document. The criteria set, with its vetoes, red flags and green flags. The analysis run. The memo and its twelve sections. The finding, tied to the criterion that produced it. The quote, tied to the page it cites. The decision.
• What can happen at intake. A document is uploaded, recognised as a duplicate, or rejected. A deal is submitted.
• What can happen to the rules. A criteria set is created, a criterion is added or updated, and the set is activated or archived. Each time a set is handed to the engine, that is recorded too.
• What can happen in a run. It is started. The deal is classified, extracted, taken through diligence and scored, and the memo is generated. Each is its own event on the deal.
• What can happen after the memo. The deal is triaged, and that decision is an event with its rationale.
• Exception: the same deck twice. The backend records the second copy as a duplicate and starts no new run.
• Exception: a run that fails. The backend has events for a run that fails, for requeuing it, and for reclaiming a run whose worker stopped part way, so none of these disappears from the history.
• Exception: a quote that cannot be found. It is kept and flagged as unverified, not dropped.
• Exception: the evidence can be read two ways. Each criterion is scored twice, once leniently and once strictly. Where the readings disagree, the finding is marked contested and both are printed.
• Exception: a register cannot be reached. A veto that could not be checked is reported as unevaluated. It is never scored against the manager and never shown as clear.
• Exception: the document does not say. “What we could not determine” is a section of every memo. It cannot be removed or collapsed.

The rules it holds

Every quote is verified in code. Each quoted passage is compared with the text of the page it cites.

The recommendation is arithmetic. It is computed from the scorecard. The model does not write it, so the memo cannot contradict its own scores. A figure in the memo must match an extracted value, or the run fails.

Funds are scored against the institution’s own criteria set, and each criterion carries written guidance on how to detect it. A person must review and activate a set before any deal is scored. Once active, a set cannot be edited. A change is a new version.

What the record makes possible

A deal’s events read as its analytical history: which document, which version of the rules, what each stage found, and what the analyst decided. The system computes whether the person agreed with the memo. The person cannot set that value.

One measurement exists, and it is from a single test document. The engine verified 121 of 124 quotes against their pages. The three that failed stayed in the output, flagged.

What the foundation carries forward

The parts of this prototype that are not specific to funds are the framework’s: accounts and permissions, and the event record.

The parts that are specific are the model above. Completing the prototype means building the remaining screens on events that already exist, and building the designed evidence loop, whose engine support and events are specified but not yet written. It does not mean starting again. That is the same position any first build leaves an operation in.