Analysis lifecycle
The ordered path from owner input to a position, signal, gap or refusal.
The owner starts with a business outcome in normal language. From there, one verified market generation supplies the candidates for a position, signal or gap.
1. Admissibility
The service checks the raw request before paid reasoning. It admits a business downside, a promotion idea or enough business context to ask a useful question; out-of-scope input receives a calm refusal as the product outcome.
2. Detect
Detect parses the business, owner intent and bounded exposures. Each one carries a stable reference plus its risk type, severity, harm direction, time window, origin and optional owner-stated amount.
Grounding comes first. Before the stage reaches the browser, it prevents a schema-valid model field from becoming owner truth and keeps suggested risks unconfirmed until the owner accepts that exact exposure.
3. Translate
The shortlist is closed. The application loads candidates from one market generation, then lets the reasoning model compare driver, side, timing, geography and market state only among those supplied instruments.
The server then re-derives the contract identity, strike, dates and paid-side price from the generation. A fabricated or stale instrument cannot survive this join.
4. Construct
Application code turns a selected contract-side pair into an advisory quantity. Owner exposure, budget and coverage target can bind size; market thinness cannot. A numerical audit then checks cost, gross payout, coverage and remaining exposure.
5. Brief
The final stage renders the selected move, rejected alternatives, uncovered gaps and concise reasoning. Internal stage names and raw chain-of-thought do not appear in the owner experience.
How the guarantees hold
The separation between "the model interprets" and "the application owns the numbers" is not a convention the prompt asks the model to respect. It is enforced by the shape of the data on each side of the model call, so a model error has nowhere to express itself as a wrong price, a wrong contract, or a wrong side.
Direction is withheld, not requested
The reasoning model never receives which side of a contract pays. The candidate records projected to it carry only the risk type, a coarse severity, the market title, a relationship-quality label, the deterministic economics shape and the time window. The contract's YES/NO side, its instrument identifier, its trigger wording and the harm direction are removed before the call. With no direction in and a non-directional vocabulary out, the model has no channel through which to author a payout direction: it can argue that a candidate is more or less relevant, but the side that pays is rendered afterward, from the engine's own trigger template.
Selection is verified by intersection
The model returns a shortlist of handles, not positions. The application intersects that shortlist with the set of positions the engine actually constructed for this run. A handle the model invented, or one carried over from a stale generation, is not in that set and is dropped. What renders is the engine's own position record, byte for byte; the model cannot edit a price, a count, a date or a payout by returning a modified copy. If the reconciliation detects any tampering with the constructed plan, the run falls back to the unmodified engine plan.
Side correctness is checked adversarially
Before a funded recommendation renders, the selected side is submitted to an ensemble of independent skeptics: five by default, at least three. Each one is asked the same question from scratch: given only the business and the risk, what real-world outcome actually cuts this business's revenue or margin, and does the selected side pay in that world? Each reasons about whether the business is a buyer or a seller of the thing in question, since that inverts the correct side. A position survives only on a majority verdict that it pays when the business is hurt. This is what stops a plausible-but-inverted hedge: the failure mode where a position pays in the good world and silently doubles the loss in the bad one.
Streaming and replay
Live analysis streams ordered progress and stage-complete events, while keyless examples replay the same completed Detect, Translate, Construct and Brief shapes; if a stage fails, the stream closes with a bounded error object instead of inventing a result to reach the final screen.