One decision, walked

The pages before this one describe the record. This page walks a single determination through it, end to end, so you can see what the schema enforces at each step. Every value is fabricated and labeled; this is the record shape the kernel refuses to accept anything less than — a worked example of the governing model, not a product demo, becausethe review layer that would produce it does not yet exist.

The question

A post-close QC reperformance determination on a synthetic refinance file: does the income documentation in the file support the qualifying income the underwriter used?One concrete operational question — the kind a QC analyst answers dozens of times a day, and the kind an examiner asks about months later.

The source material

The schema refuses an extraction that cannot say which document and page it read (EXTRACTION_UNANCHORED) and evidence with no recorded inference behind it (EXTRACTION_UNATTRIBUTED). Source material is not a folder of files; it is the set of anchors every later claim must point back into.

What was observed

A conclusion never overwrites an observation. When sources disagree, both claims persist — which is what makes the eventual conclusion checkable instead of merely assertable.

What rule applied

In plain language: when policy changes later, this determination is still explainable under the rule that existed when it was made. The database refuses a verdict citing a rule version that does not exist, and a rule can retire but never change.

What was concluded

Uncertainty is visible, not hidden: an exception is a first-class state in the record, not a silent override.

Who approved it

The same person — or agent — cannot both make and approve the decision. That is a schema property the database enforces, not a policy anyone follows.

What survives

Months later, reconstructing this decision does not require reopening and re-reading the file. The evidence pack is the answer — built for the asker to recompute, not to take on trust.