Architecture — Four Pillars

The extraction engine doesn't use hardcoded prompts. It resolves constraints from a database, layered by scope. Adding a new extraction field or changing how a field is extracted requires zero code changes — only a row in prompt_specifications.

The Three-Tier Resolution

Every extraction prompt is assembled at runtime from constraints stored in the prompt_specifications table. Constraints resolve in a strict hierarchy:

GLOBAL constraints        ← Platform-wide defaults (every tenant gets these)
  ↓ override / extend / disable
INDUSTRY constraints      ← Vertical-specific (construction, financial, CRM)
  ↓ override / extend / disable
TENANT constraints        ← Per-customer customization (PAD's specific fields)
  ↓
RESOLVED CONSTRAINT SET   → Passed to buildPromptFromConstraints()
  ↓                        → Generates Claude Vision API prompt
EXTRACTION RESULT         → Structured JSON matching the resolved fields

Each constraint row defines a field with its group (component, group, page, keying), data type, extraction instructions, validation rules, and sort order. Higher scopes can replace individual fields, add new ones, or disable inherited ones.

Implementation: resolveConstraints()

Located at hardware-schedule-extractor.js:2871. The function:

1. Loads all scope_level = 'global' constraints from prompt_specifications
2. Resolves industry_id from the tenant (if not explicitly provided)
3. Applies scope_level = 'industry' overrides — merge, replace, or delete fields
4. Applies scope_level = 'tenant' overrides — same merge logic
5. Sorts by field_group and sort_order
6. Returns the resolved constraint set with spec_version, scope_chain, and resolved_at

The resolved set is then passed to buildPromptFromConstraints() (:2983), which generates the Claude Vision API prompt. Every extraction is audited in constraint_executions with the prompt hash and input/output hashes for reproducibility.

The Schema: prompt_specifications

id TEXT PRIMARY KEY
spec_version TEXT NOT NULL         -- Schema version for backward compat
scope_level TEXT NOT NULL           -- 'global' | 'industry' | 'tenant'
  DEFAULT 'global'
industry_id TEXT                    -- NULL for global, industry code for industry scope
tenant_id TEXT                      -- NULL for global/industry, tenant ID for tenant scope
field_group TEXT NOT NULL           -- 'component' | 'group' | 'page' | 'keying'
field_name TEXT NOT NULL            -- e.g., 'manufacturer', 'fire_rating', 'panic'
field_type TEXT DEFAULT 'string'    -- Data type hint for extraction
extraction_instruction TEXT         -- Natural language instruction for the AI
validation_rule TEXT                -- Optional validation regex/rule
sort_order INTEGER DEFAULT 0        -- Ordering within group
active INTEGER DEFAULT 1            -- Soft delete
field_aliases TEXT                   -- Alternative names (migration 033)

SCHEDULE_TYPE_REGISTRY

The constraint architecture extends to schedule type routing. SCHEDULE_TYPE_REGISTRY in hardware-schedule-extractor.js maps detected document types to extraction functions, target tables, and constraint scopes. Adding a new document type is one registry entry plus the constraint rows for its fields.

Zero-Code Extensibility in Practice

The core innovation is the affirmation boundary. Nothing enters production data until a human consents. Every consent is immutably logged with entity snapshots, user identity, and timestamps. The audit log is the product.

The Affirmation Boundary

AI extraction is probabilistic. Hardware schedules are messy. OCR makes mistakes. The system handles this with a simple rule: AI proposes, humans affirm. Data lives in staging tables (hardware_page_extractions) until explicitly approved. Only then does it materialize into production tables (hardware_sets, hardware_components).

PDF Upload
  ↓
AI Extraction (Claude Vision API)
  ↓
hardware_page_extractions            ← STAGING (AI output lives here)
  ↓
Human Review & Correction           ← Frontend card-by-card review
  ↓
Affirm (click)                       ← BOUNDARY CROSSING
  ↓
affirm_audit_log                     ← WHO affirmed WHAT, WHEN, with SNAPSHOT
  ↓
hardware_sets + hardware_components  ← PRODUCTION (only affirmed data)
  ↓
takeoff_line_items                   ← Auto-materialized from affirmed sets
  ↓
takeoff_quotes                       ← Immutable quote snapshots

Seven Affirm Levels

The affirmation system operates at seven granularity levels, each independently logged:

Smart Reset

If affirmed data changes after affirmation (e.g., a re-extraction updates the underlying data), the affirm status resets automatically. No stale sign-offs. The dual-card interlock (ticket 26L) preserves the old extraction alongside the new one until the user explicitly chooses.

User Sovereignty Schema (Planned)

The affirmation boundary operates at the data level. The sovereignty schema (ticket CH-2026-0129-SOVEREIGNTY-001) extends consent to the access level:

Three proposed tables establish the foundation:

Default denial pattern: no grant = no access. Payment as consent mechanism (Stripe contract_reference). Revocable, time-bounded, auditable.

Mutual Consent & Shared Spaces

From the Platform Architecture Spec v2.0: all cross-organization data sharing requires bilateral agreement. Three visibility layers:

PRIVATE SPACE             Only users within the owning tenant
  ↓ (explicit share offer + acceptance)
MUTUAL SPACE              Two+ tenants with bilateral consent
  ↓ (public flag, rare)                 Neither sees the other's PRIVATE content
PUBLIC SPACE              Anyone with link (no consent required)

Shared spaces (shared_spaces + shared_space_members) track bilateral consent with full lifecycle: pending → accepted → active, or declined/withdrawn. Either party can withdraw without destroying the other's data.

MHS operates a B2B platform serving businesses across verticals. SubmittalExpress is the first product, skinned for construction. Consenta is the second, skinned for CRM/ERP. The platform underneath is the same — and it's 70% domain-agnostic.

Corporate Structure

MHS (Holding Company)
├── WeylandAI (Construction Vertical)
│   ├── SubmittalExpress (Product — PAD customer)
│   └── TakeoffExpress (Product — quoting engine)
│
├── Consenta (CRM/ERP — Agreement Lifecycle)
│   ├── Consenta Docs ("Upload anything. Extract everything. Trust what matters.")
│   ├── Consenta Flow ("Approval workflows that remember everything.")
│   ├── Consenta Forge ("Beautiful documents from messy data.")
│   └── Consenta CRM ("The CRM that reads your documents.")
│
└── Quanticfork (RIA/Financial Vertical — future)

The Platform Audit: 70/15/15

An audit of weyland-worker.js (~14K lines) revealed the portability split:

Consenta: The Fork in Practice

Consenta (consenta.cc) is a 1:1 fork of Weyland with the construction skin replaced. Phase 1 (generic rename) is COMPLETE. Phase 2 (registry swap) is COMPLETE.

Viral Growth Model

The freemium sub-tenant model creates network effects:

PAD (paying)  ——shares submittal——>  Smith GC (freemium sub-tenant)
                                            ↓
                                     experiences value
                                            ↓
                                       CONVERTS to paying
                                            ↓
Smith GC (paying) —shares submittal—> Jones Masonry (freemium sub-tenant)
                                            ↓
                                        [repeats]

Sub-tenants convert to peer clients with operational continuity — shared spaces and consent records persist across conversion. The business relationship encoded in data survives the commercial relationship change.

10 CRM Document Types (Consenta Phase 2)

The SCHEDULE_TYPE_REGISTRY pattern extends from 3 construction types to 10 CRM document types with zero extraction engine changes:

Each type uses the same constraint-driven extraction via extractWithConstraints, with 87 prompt_specifications rows defining the fields per document type. The extraction engine, affirmation boundary, materialization bridge, and document assembly pipeline are all reused without modification.

"We built a telescope lens by lens, but never assembled the tube — the light never reaches the eyepiece." The pipeline works. The plumbing works. The critical path is connecting the data flows end-to-end for a customer demo.

What's Deployed Today

The Pipeline End-to-End

UPLOAD              User uploads hardware schedule PDF
  ↓
DETECT              System detects schedule pages, creates extraction session
  ↓                (auto-links to project if name matches)
EXTRACT             Claude Vision API extracts per-page data using resolved constraints
  ↓
REVIEW              Frontend shows card-by-card extraction results
  ↓                (re-extract individual cards if needed — 26M)
AFFIRM              User affirms groups → materializes to hardware_sets/components
  ↓                (audit logged with entity snapshots)
DISCOVER            CPS catalogue + web search finds cut sheet PDFs
  ↓                (user affirms or rejects matches)
PRICE               Auto-pricing from CPS catalogue, user overrides, per-set pricing
  ↓
QUOTE               Generate branded HTML quote → headless Chrome → PDF
  ↓                (shareable link with access token — 26O)
ASSEMBLE            Submittal package: cover + TOC + schedule + set pages + cut sheets
  ↓
DELIVER             R2-stored PDF, download endpoint, quote history

Revenue Context

Production Data Status

What Ships Next

Infrastructure