[SYSTEM]Builder's Log Active//Mar 5-11, 2026SIGNAL OK

From POC to Pattern

How I took Patrick's proof of concept and built something defensible, compliant, and traceable. The weighting problem? Solved. The "haters and naysayers"? Handled. The "then what?" gap? Closed.

6 days
16 commits
5 dead ends
2 key insights
// STACK: FastAPI + Next.js 15 + PostgreSQL + PyMuPDF + LangGraph + LLM
THE SEED

"It's not a system that makes decisions for you or tells you what to buy. It's a decision making aid. I am not trying to put anyone out of a job, but I am trying to make a job a lot easier."

— Patrick, from the original POC

[TRANSMISSION LOG]

// click to expand
// THE CORE CONTRIBUTIONS

[TWO KEY INSIGHTS]

HITL is Architectural, Not Optional

INSIGHT 1

The POC treated human review as nice-to-have. M-25-21 compliance made it non-negotiable. But here's the insight: Human-in-the-loop isn't a constraint — it's the product. The workflow literally pauses. Nothing moves without human sign-off.

// UNLOCKED: M-25-21 compliance by design, not by retrofit

The Loop Must Close

INSIGHT 2

Patrick's POC was: Upload → Extract → Compare → ???. The insight: Traceability is the whole game, but the loop isn't closed. What happens after comparison? Someone decides. Where's that captured? Was the decision right?

// UNLOCKED: The outcomes table tracks decision correctness. The system learns.

// SUPPORTING LESSONS

[PATTERN RECOGNITION]

Traceability is everything

If you can't click a value and see its source, it's not trustworthy. Every extraction has document_id, page_number, and bbox.

MCDA gives defensible decisions

"This scored higher" vs "here's the math, the weights, and why." The score_breakdown JSON shows every calculation.

Visual > spreadsheets

Patrick mentioned decision-makers don't want "nerd shit over their heads." Radar charts and comparison matrices beat data dumps every time.

[HINTL 2.0]Human-Informed Nested Trust Layers

Standard HITL is binary: human reviews AI output. RayRay adds role-based nesting — each tier sees different data, has different authority, and creates different claims. Humans in their lanes.

┌──────────────────────────────────────────────────────────────────────────┐
│                         HITL vs HINTL 2.0                                 │
├──────────────────────────────────────────────────────────────────────────┤
│  Standard HITL              │  HINTL 2.0 (RayRay)                         │
├──────────────────────────────────────────────────────────────────────────┤
│  One approval step          │  Observer → Analyst → Reviewer → Admin     │
│  Binary (approved/rejected) │  Confidence scores + rationale capture     │
│  No role context            │  Role determines visibility & authority    │
│  Audit = afterthought       │  Audit = the whole architecture            │
└──────────────────────────────────────────────────────────────────────────┘

// The "N" = Nested. Each layer adds context, authority, and auditability.

[THE -RAY FAMILY]

Same architecture. Different schemas. The pattern is portable.

RayRay

PRODUCTION

Radar

Detection range, frequency, PRF, cost

SoRay

DESIGNED

Sonar

Depth rating, frequency, beam width

DroneRay

DESIGNED

UAVs

Endurance, payload, range, ceiling

[TRANSMISSION COMPLETE]

Patrick's POC showed “Here's how it could work.”
I made it “defensible, compliant, and traceable.”

// The weighting problem?

AHP-inspired weighted sum

// The skeptics?

Click-to-source traceability

// Compliance?

M-25-21 checkpoints

// The "then what?" gap?

Close the Loop

// The seed was good. This grew from it.