Mighty Andy | System Architecture

Chambered agentic pipeline for bid-readiness triage

A multi-room AI pipeline that reads raw tender and evidence packs, extracts requirements, matches evidence, identifies gaps, applies structured judgment, and produces a client-facing diagnostic report.

12
Processing rooms
6
Quality gates
1
Judgment chamber
6
Verdict states

Each room is a bounded reasoning unit with scoped inputs. Each gate freezes a promoted surface for downstream use. No room reads more than it needs.

00Core principle
Centralized doctrine, localized enactment
Each worker receives only the minimum relevant context. The judgment spec is centralized, but each room gets only the subset it needs.
This reduces context size, hallucination risk, token cost, and agentic overstep. Validated independently by three AI systems.
Two-bookend chambered architecture
High-context entry and exit, low-context workers between. Only the tender diagnosis (entry) and verdict synthesis (exit) operate at full context.
Workers in between are scoped, deterministic, and cheap. The expensive reasoning happens exactly twice.
00bWhat this solves
Four common LLM failure modes, each addressed by a specific architectural decision.
Context sprawl
Problem: LLM workers see too much, hallucinate from irrelevant context.
Solution: Room-local inputs and promoted gate surfaces. Each worker reads only what it needs.
Reasoning drift
Problem: Multi-step chains lose coherence. Each step reinterprets the last.
Solution: Doctrine-localized rooms with a dedicated judgment chamber. Workers don't judge; they extract, classify, and match.
Debug opacity
Problem: AI pipelines produce final output with no inspectable intermediate state.
Solution: Every room writes a manifest. Every gate writes an index. Every run has a diagnostic corridor.
Prose leakage
Problem: Internal AI reasoning text leaks into client-facing output.
Solution: Report contract with copy-composition layer. Word limits, forbidden-language stripping, template fallbacks.
01Tender intake
Read the buyer's pack. Extract structure, requirements, and a tender imprint.
T1 Surface
Inventories every file in the tender pack. Classifies document types, identifies roles, flags junk.
pack_inventory.json
pack_roles.json
T2 Structure
Maps the procurement structure: lots, stages, evaluation criteria, timeline, framework shape.
structure_map.json
requirement_families.json
T3 Imprint
Produces the tender's "fingerprint": character, risk profile, buyer posture, downstream seed for matching.
imprint.json
downstream_seed.json
◆
Gate 01 | Tender intake
Validates completeness. Promotes surfaces to downstream consumers. Aggregates ambiguities.
Promotes: imprint, structure,
inventory, families, seed
02Client intake
Read the client's evidence pack. Classify, deduplicate, and assess relevance.
C0 Source freeze
Immutable snapshot. Once frozen, source files are never modified. Cardinal safety rule: failure = no deletion.
00_source_frozen/
C1 Surface
Inventories every client file. Identifies document types, flags junk (game installers, DLLs, personal photos).
client_inventory.json
C2 Classify
Deep-classifies each file: evidence type, currency, validity signal, domain tag.
client_classifications.json
C3 Relevance
Maps client evidence against the tender's requirement families. Produces relevance clusters.
client_relevance.json
relevance_clusters.json
◆
Gate 02 | Client intake
Validates classifications. Promotes evidence surfaces. Source freeze integrity check.
Promotes: classifications,
relevance, clusters
03Requirement extraction
Extract individual requirements. Tag each with decisiveness, operative stage, and collapse key.
R1 Extract
Extracts atomic requirements from the tender pack. Each requirement tagged with: force class (hard gate / mandatory / core / scored), domain, decisiveness tier, operative stage (admission / call-off / post-award), and collapse key for cluster grouping.
requirements.json
requirement_groups.json
◆
Gate 03 | Requirements
Validates requirement extraction. Promotes requirements and groups for matching.
Promotes: requirements,
groups, grid seed
04Evidence matching
Match client evidence to tender requirements. Assess proof state and recency.
M1 Match
Maps each requirement to its best available evidence. Each match tagged with: proof state (current pass / current fail / historical only / missing / suggestive risk) and evidence recency (current / expired / undated / historical).
evidence_matches.json
evidence_index.json
◆
Gate 04 | Matching
Validates match quality. Promotes evidence index for gap analysis.
Promotes: matches,
evidence index
05Gap analysis
Identify where the evidence doesn't cover the requirements. Surface the readiness picture.
G1 Gap analysis
Cross-references matched evidence against all requirements. Produces the readiness surface: what's covered, what's missing, what's weak, what's expired.
gap_register.json
readiness_summary.json
◆
Gate 05 | Gaps
Validates gap register. Promotes readiness surface for judgment.
Promotes: gap register,
readiness summary
06Judgment
The second bookend. Full-context reasoning over all upstream surfaces.
Judgment chamber
J1 Adjudicate
The only room that operates at full context. Reads the complete upstream surface: imprint, requirements, evidence matches, gaps, ambiguities. Applies the structural judgment spec: 10 laws, four core states, weighted verdict aggregation, suppression rules for conduct and post-award obligations.
Core states
4
proven qualified, proven disqualified, critical unknown, unlikely achievable
Verdict states
6
Weighted aggregation, not simple veto
Prohibited inferences
8
Missing evidence ≠ proven failure
Evidence conditions
6
Two-axis surfacing per finding
Key principle: Unknowns do not automatically dominate verified evidence. They dominate only when decisive, numerous, unbounded, or impossible to resolve.
◆
Gate 06 | Report ready
Promotes the adjudication surface as the primary renderer input. No legacy flat-requirement path.
Promotes: adjudication_
surface.json
07Report rendering
Three-layer copy architecture. The renderer never writes prose.
Render layer
D1 Render
Converts structured judgment atoms into the client-facing HTML/PDF report. Three layers: J1 judges, the adapter compresses into client-safe sentence modules, the renderer arranges and enforces word limits, forbidden-language stripping, and fallback templates.
adjudication_surface.json → Copy adapter → Template composer → HTML renderer → triage_report.html → PDF export
08Verdict states
Six states, each with a distinct Andy voice, colour, and client meaning.
proceed
Looks ready to run
Core evidence in place. Only ordinary submission hygiene remains.
proceed_with_checks
Worth a run but gaps need closing
Positive read, but named gaps must be closed before filing.
check_first
Close these first
Plausible, but do not invest heavily until listed checks are resolved.
insufficient_evidence
Too little here to call it
Not enough material to form a useful read. Not negative, but insufficient.
likely_not_worth
Looks like a poor fit
Andy's judgment: probably not worth pursuing. Not a proven disqualifier.
do_not_proceed
Hard stop found
Proven structural disqualifier. Current, affirmative evidence of failure.
09Operational controls
Data controls
Failure = no deletion. Across all destructive operations.
Source immutability. 00_source/ is never modified after freeze.
Dual-source UTC verification for time-sensitive operations.
Judgment controls
Missing evidence ≠ proven failure. Absence of evidence is not evidence of absence.
Expired ≠ current. An expired certificate is informative, not equivalent to no certificate.
"Intentionally preserved" is a valid terminal state. Not all ambiguity must be resolved.
Render controls
Never render raw basis. Client copy is composed from templates, not inherited from reasoning.
Word limits enforced. Ledger notes max 20 words. Action labels max 8 words.
Forbidden language stripped. Internal terms automatically replaced with client-safe equivalents.
10What I built
Architecture: Folder-driven AI pipeline with cloned run directories, room manifests, gate indices, JSON surfaces, and a diagnostic corridor. Designed for deterministic replay and cost inspection.
Judgment layer: Structural judgment specification with 10 laws, four core states, eight prohibited inferences, six evidence conditions, and weighted verdict aggregation. Validated across three AI systems (Claude, GPT, DeepSeek) as a deliberate multi-model methodology.
Report engine: HTML-first renderer with a three-layer copy architecture (judgment, adapter, renderer), template-based composition, word limits, and forbidden-language stripping. Produces branded client-facing diagnostics from structured JSON.
Execution: End-to-end pipeline tested on real tender packs (YPO DPS for grounds maintenance, 34-file evidence corpus). Multiple validated runs from source freeze through rendered report.
Design: Report template designed through iterative multi-AI critique (16 design versions). Visual identity, verdict colour system, section grammar, and information hierarchy developed from scratch.