Engineering documentreview before reliance.

Many AI failures arrive as fluent, professional work.

A model receives a board memo, investment case, technical proposal or operating plan. It returns a measured assessment. The cited paragraph exists. The math appears plausible. The recommendation sounds ready to use.

The answer may still rest on a condition lost during document conversion, an assumption presented as fact, two quantities that were never comparable, or a review stage that failed after producing only part of its work. Fluency hides these failures because a partial answer can read like a complete one.

Scout’s engine operates end to end on VALIS Staging. The supported customer product and interface have not yet been released. Within that environment, Scout tests claims, assumptions, evidence, calculations and reasoning against one source and one intended use. Software handles checks with fixed answers. Models perform the judgments that require interpretation. Independent review can disagree. If Scout Full cannot finish, the result is explicitly narrowed or the project stops.

Scout establishes what was reviewed, how it was reviewed and what the document can support for the stated use. Outside facts require their own evidence.

Every Scout project begins with three commitments.

2.1 One source

Uploaded files first pass through VALIS Readback. Readback produces the representation downstream AI will receive and records how closely that representation can be defended against the original file.

The record distinguishes the original from the representation used for reasoning. It preserves their cryptographic identities, conversion method and any known limitation. Native text follows a simpler path: Scout freezes and hashes the supplied text directly.

Scout Full can treat an ordered set of Readback documents as one composed source. Every member keeps its own identity and location inside the set. Scout Rapid remains a one-document review.

A material source change creates a new review. It never silently changes an existing result.

2.2 One intended use

The same memo may be suitable for orientation and unsuitable for approving capital. Scout records what the reader intends to do, the consequence of getting it wrong and whether the work belongs in the Volume or Decision lane.

Volume work is provisional, reversible and less costly to correct. Decision work may move capital, rights, policy, safety, fiduciary duty, regulation or reputation. Scout Rapid can review either lane. Scout Full is required for Decision-lane consideration.

The intended use changes which omissions matter and which checks the review must complete. A result earned for one purpose does not become a universal rating of the document.

2.3 A complete process

Scout records the requested depth, required stages, participating review roles, process state and final result. Each required output must exist, satisfy its contract and refer to the same project identities.

A malformed response, unresolved source mismatch or missing challenge cannot become a completed Scout Full result. Scout either recovers the required work, returns a valid narrower result where the policy allows it, or stops with the reason recorded.

If a PDF says 412,000 and the representation says 812,000, every later conclusion begins from the wrong material. Readback addresses that failure before the reasoning stage.

Within its supported envelope, Readback extracts or transcribes the material, applies deterministic checks, compares the representation with the source where appropriate and records unresolved uncertainty. Its output contains the representation Scout will use and a Readback Record tying the source identity, checks, repairs, limitations and outcome together.

Readback supports PDF, Word, Excel, Markdown and text within format-specific limits. Supported text-layer PDFs can reach independent verification; scanned PDFs retain a same-family visual-check limitation; Word and Excel use direct file-level checks without full visual comparison; Markdown and text use byte identity.

Readback outcomes are independently verified, checked with limits, unresolved or refused. When a usable representation carries a material limitation, Scout receives that limitation with the source rather than as a detached note.

4.1 Admission before model work

Scout confirms that the source representation exists, the intended use is stated, the required processing authority has been recorded, and the requested retention and processing path can be enforced.

An accepted request freezes the source, use, policy and relevant version identity into one project contract. Repeating the same request with the same idempotency identity resolves to the existing project. Reusing that identity for materially different material is rejected.

4.2 Durable execution

The project enters a durable state machine. Work runs asynchronously, so a browser connection never owns the scan. A renewable, fenced lease assigns execution to one current worker. Heartbeats distinguish active work from an abandoned process, and recovery can reclaim stale execution without allowing competing results.

Completed review work is stored as it finishes. After process loss, Scout rehydrates that work and continues under the unchanged contract. If a required result cannot be recovered, the restart policy has clear limits.

4.3 Scout Rapid

Scout Rapid performs a structural review tied to the source using one model family. It separates the document into claims, identifies its argument and proposes findings for software verification.

Software confirms that quoted material resolves to a recorded location in the source and that required structures agree. It also runs fixed checks such as stated calculations, component-to-total relationships and exact conflicts between repeated quantities.

Some checks are hybrid. A model may first decide that two figures are presented as the same quantity; software then verifies the values, locations and calculations. Scout Rapid then tells the reader to continue developing the document, repair a material issue, find a better source or move to Scout Full.

4.4 Scout Full

Scout Full begins with a separate reading of the same source and use. It is not seeded with Scout Rapid's model judgments or Scout Rapid's description of the argument. That separation gives the second path a real opportunity to see the document differently.

Scout Full maps the claims on which the conclusion depends, tests their support, brings in more than one provider family and introduces adversarial challenge. The roles ask distinct questions:

• What does the document claim?
• Which premises does the conclusion require?
• What support appears in the source?
• Does the reasoning survive challenge?
• What evidence would be needed before reliance?

Provider separation reduces one source of shared failure. It is followed by source checks, evidence rules and resolution rather than a vote among models.

4.5 Ordered document sets

A packet presents a different problem from a long document. A statement can be true of the packet and false of one member. A ranking note may compare four candidates; an individual résumé does not become a four-candidate comparison because it arrived in the same upload.

Scout Full composes an ordered source from the Readback result for each member. Each member retains its identity, limits and location inside the composition. Order is part of the review because an amendment after an agreement carries different meaning from the same files in reverse.

Document-level readings remain tied to the member that supports them. Packet-level reasoning may compare members later without rewriting the subject of any individual document.

4.6 Resolving disagreement and publishing

Scout Rapid and Scout Full may disagree about the document's argument, material findings or next step. Scout compares their records, requires source support for any resolution and preserves important disagreement when the evidence does not settle it.

Scout Full also examines the whole document after claim-level review. Decomposition makes complex material tractable, but it can hide relationships that only appear across several claims. The whole-document pass restores that view before Scout derives the final result.

Scout then verifies stage completion, identities, result structure, resolved disagreements and applicable use conditions. The result and final project state are committed together. A reader never receives a candidate finding presented as the completed review.

A completed Scout Full review returns one result for the intended use: Decision Grade, Conditional or Not Yet. Refused and failed describe a review that did not finish and carry no result.

Consider a synthetic regional expansion memo that recommends approving a new operating hub. It states:

• the first-year cash requirement is $500,000;
• the listed components are $120,000 for the lease and setup, $150,000 for staffing and $90,000 for vehicles;
• operations will begin in September because permits usually take sixty days; and
• four months of expected contribution at $135,000 per month will cover the investment.

Software can establish that 120,000 + 150,000 + 90,000 = 360,000. That does not prove the $500,000 headline false; the memo may have omitted a legitimate $140,000 category. It does show that the cost basis is not constructed in the document.

The timing assumption creates a second dependency. Four months at $135,000 produces the stated $540,000. A one-month delay produces $405,000. Scout does not need to predict the permit date to identify the problem: the approval case depends on a September launch, and the memo offers no evidence or sensitivity analysis for that condition.

The useful finding is therefore larger than a math correction. The document presents break-even as established even though both sides of the comparison remain unstable. Repair requires a complete cost schedule, evidence for the launch timing and a recalculation across credible start dates.

Code computes the stated relationships. Model judgment reconstructs the dependency and explains why it matters to the approval decision. Outside evidence settles the permitting question.

Scout preserves the source identity, project contract, attempts, review records, resolved disagreements, process health and published result. Published analytical content is not revised in place. Hash-linked records make unrecorded mutation detectable. They protect the integrity of the record, not the truth of the underlying claim.

The current Scout API and Admin surface are internal Staging paths. Project access is tenant-scoped in the application, with database isolation controls on the established Scout tables. This is not a finished customer identity or security boundary.

Current deletion is limited to the Scout project path. It can purge governed project content while retaining a non-content tombstone and hashes; it does not establish whole-system erasure across Readback, providers, caches or backups.

The analytical record also gives operators a precise view of project state: current attempt, completed roles, process health, usage and terminal reason. Runtime metrics, logs, traces and alerts monitor the service around that record. Together they distinguish a document that could not support its intended use from an instrument that did not finish its own work.

This record lets a later reader inspect and challenge the judgment against the same frozen source, intended use and review record.

Scout's software behavior is tested through unit, contract, mutation-paired, transaction, database-policy, fencing, recovery, source-binding, composition, completion and result-integrity suites. These tests verify the engine and its client interface: identity rules, state transitions, failure handling and publication controls.

These engineering tests establish only that the named mechanisms follow their contracts under tested conditions. VALIS has not yet completed the representative, independently adjudicated product-use evidence needed to claim recall, false-positive rates, repeat stability, repair effectiveness or reader comprehension.