About this demonstration
Testero is a portfolio product concept: an AI-native origination orchestration layer for home equity investments. This page is the context a reviewer would otherwise have to reconstruct from the interface.
The problem
Processing a home equity investment means reconciling a CRM record, a worksheet, document buckets, email threads, calls, e-signature envelopes, internal guidance, calculators, title portals, appraisal portals, flood data, public records, payoff channels and informal notes. The operator becomes the integration layer between all of them.
The failure modes follow from that: underwriting rework when a file arrives without clean evidence; false urgency when a date was never entered; duplicate requests to the homeowner because two teams hold different pictures of the file; and inconsistent decisions when training notes, habits and current policy disagree.
The product thesis
AI proposes. Deterministic logic evaluates. Authorised humans approve material outcomes.
A file should be a living, evidence-backed state machine rather than a pile of documents someone re-reads. Testero answers four questions on every case: what do we know and where did it come from; what rule applies and what is the decision state; what is the next best action, who owns it and what does it unblock; and what must an authorised human decide.
What this demonstration implements
A narrow, deep vertical slice — one synthetic case carried from messy evidence to a verified, auditable decision state.
- 6 synthetic source documents at intake — 8 across the full scenario — each with page-level block geometry, so every extracted value can be highlighted where it was read
- 31 evidence assertions extracted at intake, of which 29 stay live once duplicate representations are superseded
- 10 deterministic rules in rule set 2026.07, with versions, owners, source authority and test coverage
- Contradiction and duplicate detection that hold both sides rather than picking one
- A dependency-aware action planner ranked by what each action unblocks
- An append-only event log that grows through the demo and never rewrites
- A bounded copilot and template-driven communication drafting, both grounded in case state
- An unresolved policy conflict (CRED-INQ-006) that disables automation for the affected decision
- One contradiction and one duplicate held open rather than resolved away
Deliberately out of scope: servicing, production closing, real bureau, title, valuation or e-signature integrations, real borrower communication, adverse action, and the full 44-page platform described in the source brief. Where breadth mattered it is represented; where depth mattered it is built.
The decision boundary
| AI may | Deterministic logic must | Humans must |
|---|---|---|
| Classify documents, extract fields, compare sources, detect contradictions, summarise, draft communications, explain a rule output, recommend an action. | Evaluate readiness, calculate gate status, enforce dependencies and SLA maths, apply the effective policy version, and detect unresolved rule conflicts. | Verify material evidence, approve exceptions, make underwriting, pricing, legal and adverse-action decisions, and approve sensitive communication. |
This is enforced by construction rather than convention. The rule engine reads an EvaluationContext built only from CaseState; copilot answers and drafted communications live outside it and are structurally unable to reach a rule. The test suite asserts it: injecting a communication whose body claims every rule passes leaves the decisions byte-identical.
A related decision, visible throughout: a contradicted field has no resolved value. Ask the context for ownership_vesting while the application and the deed disagree and it returns nothing, forcing a rule to handle every side explicitly. That is how “the system never silently picks a source” becomes code rather than a promise.
The demonstration in numbers
- Rules evaluated
- 10
- Blockers at intake
- 2
- Blockers when ready
- 0
- Trailing dependencies
- 3
- Events at intake
- 24
- Unresolved conflicts
- 1
Still tracked when ready
Grows to 44
Automation disabled
Synthetic data
Jordan Lee does not exist. The property, parcel number, recording number, account numbers, balances, credit report, vendors, firms and staff names are all fabricated for this demonstration. No real homeowner data of any kind is present, and no material was copied from any company’s systems.
Testero is an independent, synthetic portfolio product concept. It is not a Splitero product, policy, or authorised representation. No real homeowner data is included. Rules, workflows, documents, and case data shown in the demonstration are synthetic and are not intended as legal, compliance, credit, underwriting, or investment guidance.
Colophon
Designed and built by Stefen Ewers as an independent product and engineering case study. The research base was a supplied operating pack of process documentation, abstracted into product patterns — no names, contact details, live borrower information, internal links or credentials were carried across.
Architecture
The domain layer is framework-free TypeScript with no I/O: domain/types, domain/evidence, domain/rules, domain/policy, domain/actions and a single project() function.
CaseState holds only recorded facts — documents, evidence assertions, vendor orders and the event log. Readiness, the decision rail, next actions and the verification queue are all derived by project() on every render. A demo step appends documents and assertions; it never writes a readiness label. That is why one change propagates to every surface at once.
The event timeline is generated from the engine rather than hand-written: for each step the case is projected before and after, the blocker sets are diffed, and the resulting rule_evaluated, blocker_cleared and readiness_changed events are recorded. The audit history cannot drift from the decisions it describes.
Next.js App Router, React and Tailwind. No database: the case is deterministic seed data plus pure functions, which makes the deployment a static build with two server routes and makes every rule outcome reproducible. Model calls happen only on the server.
AI: Classify and split
01Source documents
Application, credit report, deed, statements, notes
AI: Extract, compare, detect contradictions
02Evidence assertions
Value, source document, page, block, confidence
Human: Verify material facts at source
- 03
Case state
Recorded facts only — documents, assertions, orders, events
Human: Record corrections
AI: Structurally excluded
04project()
One pure derivation over recorded facts
AI: Explain a result, draft a request
05Decisions · Readiness · Actions · History
Everything the operator sees as a judgement
Human: Approve exceptions, underwrite, decide