Tenant isolation
Enforced at the database layer, not in application logic.
Every tenant-scoped table has row-level security enabled, and each policy resolves the caller's organization from their authenticated session before a single row is returned. A query that omits an organization filter still cannot read another organization's rows — the database applies the constraint, so isolation does not depend on a frontend or API layer remembering to ask for it.
- Row-level security enabled on submissions, documents, evidence, and audit tables
- Policies resolve the organization from the verified session, never from client input
- Isolation holds for reads, writes, updates, and deletes alike
Complete, immutable audit trail
Every material action is logged with human vs. AI attribution.
Document uploads, extraction runs, verifications, rejections, superseded facts, and recorded decisions each write an audit record. Every record names its actor and distinguishes a human action from an AI-assisted one, and human actions capture the actor's name and email at write time so the trail stays readable even if the account is later changed or removed. Audit records are append-only: nothing in the application updates or deletes them.
- Uploads, extractions, reviews, and decisions all produce audit records
- Actor identity is snapshotted at write time, not resolved after the fact
- Append-only by design — no edit or delete path exists in the platform
Human authority preserved by design
The platform never binds, declines, or blocks a decision on its own.
There is no automated underwriting path. Appetite and guideline signals are advisory: they surface on the submission and in the exported risk file, and they never prevent an underwriter from proceeding. Bound, declined, and referred outcomes are recorded only by a named person, with a mandatory written rationale attached to the file.
- Appetite and guideline flags are advisory — they never block a decision
- Every outcome requires a named underwriter and a written rationale
- AI assists the file; the human records the decision
Evidence provenance
Every extracted fact links back to its exact source document.
Extraction stores each fact against the document it came from, together with the verbatim excerpt it was drawn from and the page it appeared on. Reviewers can read the underlying language next to the value before accepting it, and the same citations carry through to the exported risk file — so a fact can always be traced to the sentence that supports it.
- Facts carry the source document, verbatim excerpt, and page reference
- Citations are visible during review, not just stored
- Provenance is preserved in the exported risk file
Binding authority limits
Configurable per role and enforced at the database level.
Each user carries an authority limit. When a bound outcome is recorded, the database compares the submission's total insured value against that limit and rejects the write when it exceeds it — the guard is not a disabled button that a crafted request could bypass. The applicable limit is shown to the underwriter at the point of decision and captured in the audit record.
- Limits are attributes of the user, configurable by administrators
- Over-limit bind attempts are rejected by a database guard
- The limit in force is recorded alongside the decision
No fabricated data
The system is designed never to invent facts it cannot find.
Extraction is constrained to what the submitted documents actually say. When a required fact is absent, it is reported as missing rather than inferred, estimated, or filled from a plausible default — and a missing fact lowers the file's completeness and coverage scores instead of quietly disappearing. Conflicting statements across documents are surfaced as contradictions for a human to resolve, not silently reconciled into one answer.
- Absent facts are reported as missing, never inferred or estimated
- Missing facts reduce completeness and coverage, keeping gaps visible
- Contradictions between documents are raised for human resolution