Claims, Not Facts: Building an Auditable Multi-Author Record for a House

Description and use

ML Systems builds an auditable house record where each claim is stored with source, evidence grade, and verification state. Conflicts are resolved by domain authority and evidence, and signatures are bound to the claim hash for auditability.

Problem

Traditional building record systems store facts as immutable truth, which fails when multiple parties (homeowners, assessors, AI agents, custodians) provide conflicting information about the same house.

Outcome

The system produces a single auditable record per house that preserves all claims, reconciles conflicts by domain authority and evidence, and maintains verifiable audit trails through bound signatures and lapsing.

Workflow

• Collect claims from all parties (homeowner, assessor, AI agents, staff, custodian).
• Assign each claim a source, evidence grade, and domain authority.
• Reconcile claims within each domain using evidence grade hierarchy.
• Determine reconciliation state (confirmed, reconciled, single-source, conflict, unverified).
• Stamp claims with independent verifications (homeowner, custodian).
• Bind each stamp to the claim’s hash to enforce auditability and trigger lapsing on edits.
• Generate review queue ordered by quarantine, lapsed, unverified, awaiting-stamp, unstamped, stamped.
• Present ledger record-first UI with verification glyphs and aggregated building envelope.
• Compress ledger into HomeGenome for compact collateral description.
• Use verified entries to support loan underwriting, salvage marketplace, and ontology licensing.

Evidence

The ledger’s job is not to pick a winner blindly. It is to reconcile by authority and evidence, and then record the outcome transparently — including the cases where reconciliation failed.

Source

Every verification stamp (VER:…) is bound to the content it signed, via an entryHash. Change the number and every signature on it lapses automatically.

Source