The workflow
What happens when a submission goes through the platform
Eight stages, from the documents a broker sends to a locked, evidence-backed risk file. The platform reads, cites, checks, and flags. Your underwriters verify the facts and record the decision — that order never reverses.
Currently configured for commercial property. The fact schema is data-driven, so additional lines are a configuration exercise rather than a rebuild.
- 01
Intake
The submission becomes a file, inside your organization only.
An underwriter creates the submission and uploads the documents that came with it — the application, loss runs, property schedules, inspection reports. Documents are held in private storage and are readable only by members of the organization that owns the file.
- Applications, loss runs, property schedules, inspection reports
- Private storage — documents are never publicly addressable
- Every file is scoped to one organization at the database layer
- 02
Evidence extraction
Named facts, each tied to the sentence it came from.
The platform reads each document and extracts the specific facts the line of business requires. For commercial property those are construction type, roof age, square footage, occupancy type, year built, and sprinkler status. Each extracted value is stored with the document it came from, the verbatim excerpt it was drawn from, and the page that excerpt appeared on.
- Six required property facts, defined by your fact schema rather than hard-coded
- Every fact carries its source document, verbatim excerpt, and page reference
- If a fact is not in the document, the system does not guess or invent a value — it reports it as missing
- 03
Contradiction detection
Disagreements are surfaced, not silently resolved.
When the same fact appears differently across documents — the application implies one roof age, the inspection report states another — the conflicting values are grouped together and marked as conflicted. The platform does not choose a winner. An underwriter reads both excerpts side by side and decides which one the file will rely on.
- Conflicting values for the same fact are linked as one conflict group
- Both source excerpts stay visible for comparison
- Only one value in a conflict group can end up verified, enforced in the database
- 04
Missing information detection
Gaps show up before the review, not during it.
The file is continuously checked against what a complete submission requires: the required facts for the line of business, and the required document types. Anything absent is listed as a gap on the submission, so the missing loss run or the unanswered sprinkler question is visible up front instead of being discovered halfway through a review.
- Required facts and required document types both checked
- Completeness and evidence coverage are computed from verified facts only
- Gaps are listed explicitly on the file, not implied by an empty field
- 05
Human review
Nothing is confirmed until an underwriter confirms it.
Extracted facts arrive as pending review. An underwriter verifies or rejects each one, reading the source excerpt next to the value. A rejection requires a written reason. The platform never marks its own output as verified, and a fact that has not been verified by a person is never treated as confirmed anywhere in the file, its scores, or its export.
- Facts enter as pending review and are verified or rejected by a named person
- Rejections require a written reason, recorded on the fact
- Review queue supports saved filters and batch verify or reject for volume
- 06
Appetite guidelines (advisory)
Your rules, surfaced for awareness — never as a gate.
Administrators define the organization's own appetite rules against the facts on a file. When a rule matches, the file carries a flag that appears in the workspace and in the exported risk file. Flags are advisory only: they never block an action, never change a status, and never decide anything.
- Rules are defined by your organization, not shipped as someone else's appetite
- Matches are flagged in the workspace and carried into the export
- A flag never blocks, auto-declines, or auto-refers a submission
- 07
Decision and binding authority
A person decides, within the authority they actually hold.
The underwriter records one outcome — bind, decline, or refer — with a required written rationale. Binding is permitted only within that underwriter's configured authority limit: the database compares the submission's total insured value against the limit and rejects an over-limit bind, so the control is not a disabled button in the interface. Declining and referring are never limited by authority. Once a decision is recorded, the file locks: no further uploads, extraction, or review.
- Bind, decline, or refer — always by a named underwriter, always with a rationale
- Over-limit binds are rejected by a database guard, not just hidden in the UI
- Recording a decision locks the file against further changes
- 08
Audit trail and export
The whole path is on the record, and it leaves the platform intact.
Uploads, extraction runs, verifications, rejections, superseded facts, and the decision itself each write an audit record naming the actor and distinguishing human action from AI-assisted action. At any point the file can be exported: a PDF risk file carrying the decision, the verified evidence with its citations, any conflicts and how they were resolved, and outstanding gaps — or a CSV of the evidence for your own analysis.
- Every material action is logged with human vs. AI attribution
- Audit records are append-only — the platform has no edit or delete path
- PDF risk file and CSV evidence export, available at any point in the file's life
What the platform does not do
The boundaries are as specific as the features
No autonomous underwriting
The platform never binds, declines, or refers on its own. Every outcome is recorded by a named underwriter.
No invented facts
A fact that is not stated in a document is reported as missing rather than inferred or estimated.
No silent conflict resolution
Contradictions between documents are raised for a person to resolve, never reconciled behind the scenes.
No self-verification
Extracted facts stay pending until a licensed underwriter verifies or rejects them.
No blocking guidelines
Appetite flags inform the underwriter. They never gate an action or change a status.
No interface-only controls
Authority limits, decision locking, and tenant isolation are enforced in the database.
Walk one of your own submissions through it
Bring a real property submission and we will take it end to end in the product: extraction with citations, a contradiction being resolved, the review step, and a decision recorded against an authority limit.
Request a Demo