Extraction runs as many narrowly-scoped passes — the single biggest lever on hallucination, because a small extractor asked for one table on known pages has very little room to invent. Twenty-one extractor modules cover the structures that matter: RMBS, CRT and CLO priority-of-payments, tranches, triggers, coverage tests, pool composition, annex stratifications, expenses and WAL tables.

Extraction turns a document into fields. Assembly turns fields into a deal. Keeping them separate makes a tie-out break diagnosable — an extraction failure is a reading problem, an assembly failure is a mechanical one, and the pipeline can tell you which occurred.

Every answer includes page-level citations pointing back to the source document. Click through to the exact passage that supports the response, and to the per-field confidence the extractor recorded.

Both stages write into the same artifact: a profile per document, versioned, page-cited and org-scoped. You cannot run an analytic across two hundred PDFs, but you can run one across two hundred profiles.

Profiles for a CRT deal, a non-QM shelf and a CLO are not shaped alike — each extractor files its fields under the domain they belong to. Paths support recursive descent, so $..threshold_pct finds that leaf wherever it was filed. You do not need to hold three extraction schemas in your head to ask a question that spans them.

Twelve deals matched means nothing until you know whether that was twelve of twelve or twelve of two hundred. The sweep returns documents in scope, documents actually searched, and names every unprofiled or unreadable file — because a store that returns nothing for a document it has no profile for and a store that returns nothing because the read threw produce the identical empty answer.

A field holding 4.2 for a threshold means 4.2 percent. Deciding that > .05 meant five percent rather than five basis points is a guess, on a corpus where both scales genuinely occur — so the predicate runs exactly as you wrote it, and the sweep warns when the values the corpus actually holds at that path disagree with its shape.

Credit enhancement by vintage across a shelf, every deal carrying a structural feature you care about, trigger thresholds compared across issuers. Each row carries citations back to the page in its source document, so any number in the chart can be walked back to the paragraph it came from.

Filter by FICO range, vintage, originator, term, and rate band. Graam matches the current pool against rating-agency vintage cohorts (Freddie Mac SFLLD for resi) and EDGAR shelf filings, and pulls period-by-period CDR, VPR, DQ60, DQ90, and CNL straight from the source.

Overlay performance curves across vintages and issuers to identify relative value and emerging trends. Compare CDR, severity, and CNL trajectories side by side.

Extract cumulative net loss, default rate, and severity milestones at 12, 24, 36, 48, and 60 months of seasoning. Use these benchmarks to calibrate forward projections.

Apply stress multipliers to base empirical curves to produce bull, base, and bear scenarios. Compare projected performance across assumptions to size credit enhancement.

Period-by-period CDR, VPR, DQ60, DQ90, and CNL from shelf filings. Filter by issuer, vintage, and deal to build custom benchmarks and track performance over time.

Loan-level performance data from Freddie Mac's Single Family Loan-Level Dataset. Analyze default and prepayment behavior by origination vintage, FICO band, LTV bucket, and geography.

Prepayment rates by refinancing incentive bucket. Visualize the classic S-curve relationship between rate incentive and voluntary prepayment speed across vintages and loan types.

Query performance at the sponsor or shelf level. Compare how different issuers' deals have performed across market cycles and identify platform-specific risk factors.

Every uploaded loan tape and historical performance file is pre-loaded as a pandas DataFrame in a sandboxed Python environment. Ask Graam to weight CDR by FICO bucket, build a custom severity vector, splice cohorts at month 24, plot loss timing — it writes the code, runs it on your data, and renders charts and tables inline.

Generated code does not run as free-form scripting over a raw file. It executes in a constrained REPL seeded with typed primitives: pool metrics, stratifications, delinquency roll rates, performance curves, empirical CPR and CDR histories, loss projection. The agent composes those primitives rather than reimplementing them per query — which is what makes two runs of the same question agree.

Start with empirical data: "Pull the 2022 non-QM vintage loss curves." Adjust: "Stress severity to 90% for the first 24 months." Splice: "Use the stressed curve through year 2, then revert to the issuer's base case." Compare: "Run the deal with both curves and show me the breakeven." Each step lands in the same projection state — no rebuilding, no reuploading.

Disagree with the empirical multiplier? Override it. Want to swap the waterfall convention? Swap it. Graam re-runs the entire chain — collateral projection, waterfall, bond analytics — and shows you what changed. The leverage isn't automation; it's a partner that ships work in a fraction of the time.

Custom Python code calls the same bridges the engine uses — graam.store_curve, graam.get_deal, graam.chart, graam.empirical_severity. Any analysis can flow directly into a projection, waterfall, or bond-analytics run. No exports, no copy-paste between tools.

Define the columns and conventions you want once, as a reusable skill, and every subsequent run returns in that shape without re-prompting.

A result becomes visible only by being sealed. A computation that ran but was never sealed does not silently appear in a report — the absence is the safe failure.

Graam segments the tape into cohorts based on FICO, LTV, term, and geography. Each cohort is matched against historical performance data to calibrate default probabilities.

Train generalized additive models (GAMs) for nonlinear feature relationships or logistic regression for interpretable coefficient-based models. Both produce loan-level default probabilities.

Every model is validated on an out-of-sample holdout. Models below the 0.65 AUC threshold are flagged, and Graam surfaces the validation metrics so you can assess discriminatory power.

Convert loan-level default probabilities into aggregate CDR vectors that feed directly into the cashflow engine. Bridge the gap between statistical models and waterfall execution.

S&P runs the loan-level frequency-of-foreclosure computation against the archetypal pool, combined with loss severity. Fitch runs its Origination PD model and loss-severity framework — PD × LS = expected loss, balance-weighted and floored to the rating case's pool loss floor. Each produces the credit-enhancement level a class needs to carry its rating.

Without a tape, the skill answers factual questions directly from the transcribed methodology — a documentation adjustment factor, an occupancy or property-type factor, a credit-enhancement floor. With a tape, it runs the loan-level computation through the canonical engine function against your actual pool.

Both paths read the same criteria YAML. The factors quoted back to you in a fact lookup are rendered from the same file the engine computes against, so the number you are told and the number that gets applied cannot diverge.

The skill declares which function is permitted to produce the foreclosure-frequency ladder, and the reporting layer rejects any deliverable that states that ladder without a figure minted by it. A plausible ladder written in text, with the canonical function never called, is the most dangerous possible output — because it is the one nobody checks — so it is made impossible to ship.

Asked to estimate required credit enhancement for a pool described only by stated composition, the system builds a representative tape from that composition and runs the real engine over it, rather than hand-authoring a ladder that looks right.

Where a criteria model's continuous coefficients are proprietary and the published document prints only "varies," the encoded approximation is marked as such with its basis noted, and calibrated to reproduce the published categorical impacts. The faithful published values and the disclosed approximations are never mixed together silently.

Parses the prospectus to extract the capital stack, tranche definitions, coupon types, subordination levels, and structural triggers into a validated deal model. Supports sequential, pro-rata, and hybrid structures.

The starting point is a deal already modeled from its own offering document and reconciled against its published tables — its waterfall, triggers, exchangeables and coupon conventions are known-good. Cloning that and changing one thing is a far shorter path to an answer than authoring a structure from nothing, and it is how the deals on a shelf actually get made.

Swap the tape and the deal keeps its structural grammar — the priority of payments, the trigger definitions, the class conventions — while the pool underneath it changes. That is the difference between re-modeling a deal and re-running one: everything the offering document established stays put, and only the collateral moves.

An edit returns a new in-memory deal and writes nothing; persistence is a separate, explicit verb. Vary a parameter across dozens of candidates, project and price each one, and commit only the winner — at no database cost for the ones you discarded. Each edit carries a change log recording what moved and from what to what, and an edit that could not be applied comes back flagged as an error rather than as a silent no-op.

Every structure is submitted to the cashflow engine for validation. The agent checks WAL ranges, payment priority, trigger fire-points, and cashflow conservation. If validation fails, it diagnoses the issue, modifies the deal model, and re-runs until the structure passes — or surfaces the discrepancy for review.

Price — the maximum collateral price an existing deal supports — and credit, the default rate at which a given class first takes a loss. Proceeds come from the typed sources-and-uses, never a hand-sum of the rows, so reported proceeds can never exceed what the structure actually raised.

The maximum cash purchase price is what the rated bonds raise, and it does not move with the note rate — criteria-sized balances at spread-priced coupons are independent of it. The economic value adds the retained strip, and it does move, because that is where the coupon lives. A desk comparing bids wants the first; a desk pricing its own origination wants the second.

The same chain runs in the other direction: sell the rated classes at par, retain the residual and first-loss, and root-find the collateral price at which the retained piece earns a target IRR. The purchase price is wired into the day-one equity outflow — equity is what you paid less what the sold bonds raised — so the retained IRR genuinely moves as price moves.

A vertical retention slice and deal fees enter the sources-and-uses explicitly, so a risk-retention structure prices as one rather than as a footnote.

The whole chain runs as a single procedure with every step bound to the function that must produce it: the ladder from the criteria engine, the deal from the assembler, the proceeds from the typed sources-and-uses. The steps that are easy to skip when a chain is assembled by hand cannot be skipped, because there is no hand-assembled version to skip them in.

A cell on the sheet is not a lookup. Each is a representative loan with that cell's attributes, run through the full reverse-structuring chain — criteria-sized stack, stated spreads, retained strip — so a price adjustment for a 680 FICO at 85 LTV is the difference in what that loan is worth once securitized, not an assumption about what it should cost.

Base price is priced along the note-rate axis at the best-case borrower, and the FICO × LTV adjustments are priced at a reference rate, so a full sheet costs a few dozen structures rather than the full cross-product. Any loan's price reconstructs as base price plus adjustments, to the sheet's rounding grain.

The base price keys on the loan's total economic value — rated proceeds plus the retained excess-spread strip. The cash price the rated bonds raise does not change with the note rate, so a sheet keyed on it would print the same price at every rate. The value of a higher note rate lives in the strip, and the sheet has to price the strip to show it.

Documentation program, occupancy, property type, loan purpose and DTI each become an adjustment column by the same method: hold the borrower fixed, vary one attribute, take the price difference. Those factors are the rating-criteria tables themselves — a bank-statement program or an investor property is priced through the criteria engine's own multiplier, not a house guess.

Note rate, FICO, LTV and the categorical attributes, against a named sheet: base price plus each adjustment, itemized. Bands are tiers, not nearest grid points — a 720 FICO prices in the 700 tier, an 82 LTV in the 85.

Every loan on a tape quoted off the sheet, rolled up to total balance, weighted net price and total proceeds, with loan-level detail retained. Pass several sheets and the tape is priced across them — a yield sweep in one table.

A five-tab Excel file — rate sheet, adjustments, capital stack, assumptions, and a loan pricer whose formulas are live, so a desk can quote from the workbook without Graam in the loop.

The spread ladder you state is compared, basis point for basis point, against the ladder the built stack actually carries. A transcription slip surfaces as a named discrepancy rather than a slightly wrong sheet.

Not just the constructor: __init__, model_copy() and model_construct() all check the same flag. Copying a legitimate result and editing the number in it fails the same way as fabricating one outright. Generated analysis code cannot access or override that guard.

A number in a Graam deliverable can be traced to the function that produced it. A model cannot compute a figure in its head, write it into prose, and have it carry the authority of an engine result — the type it would need in order to do so is one it cannot construct.

DERIVED is soft. Runtime compositions are tracked and reviewed but not structurally proven, which is why the tier exists as a separate name rather than being quietly folded in with the other two.

A skill can declare what it must produce and which function is permitted to produce it — a canonical foreclosure-frequency ladder, minted only by the criteria engine function. The reporting layer then rejects any deliverable that states that ladder without a figure minted by that function.

Decomposition is a fixed sequence of isolated calls, not a reasoning loop — resolve referents, classify, select methodology, check sufficiency, refuse on a false premise, extract typed assumptions. Each stage fails safe: an error degrades to a smaller result, never to a wrong one.

The writer is a pure function: given a spec and the history, it returns the next cell. It sees the result of the previous cell before writing the next, so it inspects real column names, shapes and values rather than guessing at them. It signals that it believes the work is done by populating a findings variable. It does not get to act on that belief.

An assessor response the system cannot validate is treated as repair-and-rethink, never as done. The ambiguous case fails toward more work, not toward shipping.

A cell that raises is rolled back and its traceback becomes the next observation — so the writer's next cell is the fix, written against the actual error rather than a summary of it.

Executed cells are capped, assessor bounces are capped separately, and a writer that returns prose without runnable code repeatedly fails closed on a stall detector well before either bound.

Cells that execute nothing are not charged against the execution budget — a response carrying no runnable code is re-asked without cost, up to a limit.

Those printed tables are the output of the three-way tie-out performed at issuance between the issuer, the accounting firm and the lead bank. Reconciling to them is a comparison against three parties with no interest in Graam being right — independent verification, not a self-graded exercise.

The output is a per-scenario workbook with an explicit pass or fail on every row. A scenario that does not reconcile is reported as a break. Nothing is smoothed, and nothing is omitted for not agreeing.

A validation report that always comes back clean is telling you less than one that shows you its breaks. The correct question is not does it tie out, but show me what it does when it doesn't.