Architecture Reference

How the System Works

Three isolated verticals — V1 procurement, V2 financial kernel, V5 MRO aviation — sharing one PostgreSQL database and connected by a proprietary cross-vertical event bus, with an autonomous AI agent pipeline running entirely inside Supabase.

Section 1

System Overview

V1 · Port 3000

Procurement Backbone

Requisitions + approvals

Purchase Orders (batched)

Goods Receipts

Invoices + 3-way match

Supplier management

AI agent fleet (14)

RFQ / Auctions / Telegram

🗄️

Supabase Postgres

proc_* · tsm_* · mro_*

pgvector · pg_net · RLS

90+ migrations

V2 · Port 3001

Financial Kernel

Treasury (5 compartments)

Buy-side state machine

Liquidity locks

GAAP/IFRS ledger

Marketplace API + API keys

LogiStack webshop

Sovereign dashboard

Cross-Vertical Event Bus

Typed tokens · immutable once emitted · causation-tracked · DB-native fan-out

V5 · Port 3004 · EASA Part-145

MRO Aviation Kernel

Work orders + tasks

Fleet registry (aircraft)

Receiving inspection

Component lifecycle

Life-limited parts (LLP)

Certificate of Release (CRS)

Part acceptance emits a typed token to V1 via the cross-vertical bus → MRO_PARTS_AVAILABLE task event

Section 2

Agent Handoff Network

Core P2P pipeline shown. 14 agents total — additional spawned agents handle RFQ orchestration, competitor price surveillance, pricing optimisation, entity viability monitoring, and SAP IDoc generation.

Section 3

Data Flow Table

Event Type	Trigger	Agent	DB Write	Treasury Effect
`REQUISITION_SUBMITTED`	Requisition created or webshop OOS	requisition-agent	proc_approvals, proc_task_events	—
`PO_DRAFT`	Catalog requisition approved	po-agent	proc_purchase_orders, proc_po_batch_queue	`tsm_lock_liquidity()`
`RFQ_INITIATE`	Off-catalog requisition approved	rfq-orchestrator	proc_rfps, proc_rfp_lines, proc_rfp_invitations	—
`RFQ_EVALUATE`	Hourly deadline check	rfq-orchestrator	proc_rfp_responses (award), proc_purchase_orders	`tsm_lock_liquidity()`
`PO_CONFIRMED`	PO issued	idoc-architect	proc_idoc_queue	—
`INVOICE_MATCH`	Invoice uploaded / OCR	invoice-matcher	proc_three_way_matches, proc_payment_advices	—
`Invoice approved`	PATCH /api/invoices/[id]	(API route)	proc_invoices	`tsm_record_po_settlement()`
`ARCHITECT_ANALYSIS`	Weekly cron	architect-agent	proc_agent_proposals	—
`MARKET_SCOUT_RUN`	Weekly cron	market-scout	tsm_market_intelligence	—
`PRICE_OPTIMIZE_RUN`	Scheduled trigger	price-optimizer	tsm_offerings (unit_price)	—
`ENTITY_VIABILITY_CHECK`	Monthly cron	viability-monitor	tsm_entity_snapshots	—
`MRO_PARTS_AVAILABLE`	V5 part acceptance → cross-vertical bus	spawned_agent	proc_task_events (work-order notification)	—

Section 4

State Machine Registry

Every valid state transition is a row in proc_state_machines — a single source of truth for what state changes are allowed. Triggers validate against this table at write time; adding a new valid transition is a single SQL INSERT, no code deploy needed.

136 transitions across 17 entity types — live from DB.

clm_contract— 15 transitions

From	→	To	Terminal	Guard Function	Requires
`active`	→	`expiring_soon`	—	—	—
`active`	→	`terminated`	TERMINAL	—	—
`active`	→	`renewed`	TERMINAL	—	—
`approved`	→	`active`	—	—	—
`approved`	→	`terminated`	TERMINAL	—	—
`draft`	→	`review`	—	—	—
`draft`	→	`terminated`	TERMINAL	—	—
`expired`	→	`renewed`	TERMINAL	—	—
`expiring_soon`	→	`active`	—	—	—
`expiring_soon`	→	`expired`	TERMINAL	—	—
`expiring_soon`	→	`renewed`	TERMINAL	—	—
`expiring_soon`	→	`terminated`	TERMINAL	—	—
`review`	→	`approved`	—	—	—
`review`	→	`draft`	—	—	—
`review`	→	`terminated`	TERMINAL	—	—

ls_adverse_event— 8 transitions

From	→	To	Terminal	Guard Function	Requires
`escalated`	→	`regulatory_notified`	—	—	—
`escalated`	→	`closed`	TERMINAL	—	—
`received`	→	`triaged`	—	—	—
`regulatory_notified`	→	`closed`	TERMINAL	—	—
`triaged`	→	`under_investigation`	—	—	—
`triaged`	→	`regulatory_notified`	—	—	—
`under_investigation`	→	`regulatory_notified`	—	—	—
`under_investigation`	→	`escalated`	—	—	—

ls_clinical_trial— 10 transitions

From	→	To	Terminal	Guard Function	Requires
`active`	→	`completed`	—	—	—
`active`	→	`suspended`	—	—	—
`active`	→	`terminated`	TERMINAL	—	—
`completed`	→	`data_locked`	TERMINAL	—	—
`ethics_approved`	→	`regulatory_approved`	—	—	—
`protocol_submitted`	→	`ethics_approved`	—	—	—
`recruiting`	→	`active`	—	—	—
`regulatory_approved`	→	`recruiting`	—	—	—
`suspended`	→	`active`	—	—	—
`suspended`	→	`terminated`	TERMINAL	—	—

ls_document— 8 transitions

From	→	To	Terminal	Guard Function	Requires
`approved`	→	`effective`	—	—	—
`draft`	→	`under_review`	—	—	—
`effective`	→	`superseded`	TERMINAL	—	—
`effective`	→	`retired`	TERMINAL	—	—
`pending_approval`	→	`approved`	—	—	—
`pending_approval`	→	`rejected`	TERMINAL	—	—
`under_review`	→	`pending_approval`	—	—	—
`under_review`	→	`draft`	—	—	—

ls_document:sop— 9 transitions

From	→	To	Terminal	Guard Function	Requires
`approved`	→	`effective`	—	—	—
`draft`	→	`under_review`	—	—	—
`effective`	→	`superseded`	TERMINAL	—	—
`effective`	→	`retired`	TERMINAL	—	—
`pending_approval`	→	`approved`	—	—	—
`pending_approval`	→	`draft`	—	—	—
`rejected`	→	`draft`	—	—	—
`under_review`	→	`pending_approval`	—	—	—
`under_review`	→	`draft`	—	—	—

ls_workflow_task— 16 transitions

From	→	To	Terminal	Guard Function	Requires
`ai_draft_ready`	→	`pending_review`	—	—	—
`ai_draft_ready`	→	`in_progress`	—	—	—
`assigned`	→	`in_progress`	—	—	—
`assigned`	→	`cancelled`	TERMINAL	—	—
`escalated`	→	`in_progress`	—	—	—
`escalated`	→	`cancelled`	TERMINAL	—	—
`in_progress`	→	`ai_draft_ready`	—	—	—
`in_progress`	→	`pending_review`	—	—	—
`in_progress`	→	`pending_signature`	—	—	—
`in_progress`	→	`escalated`	—	—	—
`pending`	→	`assigned`	—	—	—
`pending`	→	`in_progress`	—	—	—
`pending`	→	`cancelled`	TERMINAL	—	—
`pending_review`	→	`completed`	TERMINAL	—	—
`pending_review`	→	`in_progress`	—	—	—
`pending_signature`	→	`completed`	TERMINAL	—	—

mro_aircraft— 5 transitions

From	→	To	Terminal	Guard Function	Requires
`active`	→	`maintenance`	—	—	—
`active`	→	`grounded`	—	—	—
`grounded`	→	`active`	—	—	—
`grounded`	→	`deregistered`	TERMINAL	—	—
`maintenance`	→	`active`	—	—	—

mro_crs— 4 transitions

From	→	To	Terminal	Guard Function	Requires
`draft`	→	`pending_review`	—	—	—
`endorsed`	→	`archived`	TERMINAL	—	—
`pending_review`	→	`signed`	—	—	—
`signed`	→	`endorsed`	—	—	—

mro_workflow_task— 5 transitions

From	→	To	Terminal	Guard Function	Requires
`assigned`	→	`in_progress`	—	—	—
`assigned`	→	`deferred`	—	—	—
`in_progress`	→	`completed`	TERMINAL	—	—
`pending`	→	`assigned`	—	—	—
`pending`	→	`cancelled`	TERMINAL	—	—

mro_work_order— 8 transitions

From	→	To	Terminal	Guard Function	Requires
`crs_pending`	→	`closed`	TERMINAL	—	—
`draft`	→	`open`	—	—	—
`in_progress`	→	`inspection`	—	—	—
`in_progress`	→	`on_hold`	—	—	—
`inspection`	→	`crs_pending`	—	—	—
`on_hold`	→	`in_progress`	—	—	—
`open`	→	`in_progress`	—	—	—
`open`	→	`cancelled`	TERMINAL	—	—

proc_dispute— 9 transitions

From	→	To	Terminal	Guard Function	Requires
`EVIDENCE_RECEIVED`	→	`PARTIAL_RELEASE`	—	—	—
`EVIDENCE_RECEIVED`	→	`RELEASED`	TERMINAL	—	—
`EVIDENCE_RECEIVED`	→	`SOVEREIGN_OVERRIDE`	TERMINAL	—	sovereign_override_token_hash + reason required
`EVIDENCE_REQUESTED`	→	`EVIDENCE_RECEIVED`	—	—	supplier_document_path must be set
`EVIDENCE_REQUESTED`	→	`SOVEREIGN_OVERRIDE`	TERMINAL	—	sovereign_override_token_hash + reason required
`OPEN`	→	`EVIDENCE_REQUESTED`	—	—	—
`OPEN`	→	`SOVEREIGN_OVERRIDE`	TERMINAL	—	sovereign_override_token_hash + reason required
`PARTIAL_RELEASE`	→	`RELEASED`	TERMINAL	—	—
`PARTIAL_RELEASE`	→	`SOVEREIGN_OVERRIDE`	TERMINAL	—	sovereign_override_token_hash + reason required

tem_dispute— 6 transitions

From	→	To	Terminal	Guard Function	Requires
`carrier_acknowledged`	→	`resolved`	—	—	—
`carrier_acknowledged`	→	`escalated`	—	—	—
`drafted`	→	`submitted`	—	—	—
`escalated`	→	`resolved`	—	—	—
`resolved`	→	`closed`	TERMINAL	—	—
`submitted`	→	`carrier_acknowledged`	—	—	—

tem_invoice— 7 transitions

From	→	To	Terminal	Guard Function	Requires
`approved`	→	`paid`	TERMINAL	—	—
`auditing`	→	`approved`	—	—	—
`auditing`	→	`disputed`	—	—	—
`disputed`	→	`resolved`	—	—	—
`extracting`	→	`auditing`	—	—	—
`received`	→	`extracting`	—	—	—
`resolved`	→	`approved`	—	—	—

tem_service_line— 6 transitions

From	→	To	Terminal	Guard Function	Requires
`active`	→	`flagged_inactive`	—	—	—
`active`	→	`suspended`	—	—	—
`deprovisioning`	→	`terminated`	TERMINAL	—	—
`flagged_inactive`	→	`deprovisioning`	—	—	—
`flagged_inactive`	→	`active`	—	—	—
`suspended`	→	`active`	—	—	—

tsm_entity— 5 transitions

From	→	To	Terminal	Guard Function	Requires
`active`	→	`underperforming`	—	—	—
`active`	→	`winding_down`	—	—	—
`underperforming`	→	`active`	—	—	—
`underperforming`	→	`winding_down`	—	—	—
`winding_down`	→	`terminal`	TERMINAL	—	—

tsm_order— 6 transitions

From	→	To	Terminal	Guard Function	Requires
`FULFILLMENT`	→	`REVENUE_RECOGNIZED`	—	`tsm_book_revenue`	—
`FULFILLMENT`	→	`CANCELLED`	TERMINAL	—	—
`ORDER_RECEIVED`	→	`FULFILLMENT`	—	—	—
`ORDER_RECEIVED`	→	`REVENUE_RECOGNIZED`	—	`tsm_book_revenue`	—
`ORDER_RECEIVED`	→	`CANCELLED`	TERMINAL	—	—
`REVENUE_RECOGNIZED`	→	`REFUNDED`	TERMINAL	`tsm_refund_order`	—

tsm_transaction— 9 transitions

From	→	To	Terminal	Guard Function	Requires
`COMMITMENT`	→	`EXECUTION`	—	—	—
`COMMITMENT`	→	`ABANDONED`	TERMINAL	—	—
`DISPUTED`	→	`SETTLEMENT`	TERMINAL	`tsm_record_po_settlement`	—
`EXECUTION`	→	`SETTLEMENT`	TERMINAL	`tsm_record_po_settlement`	—
`EXECUTION`	→	`DISPUTED`	—	—	—
`INTENT`	→	`NEGOTIATION`	—	—	—
`NEGOTIATION`	→	`COMMITMENT`	—	`tsm_guard_commitment`	—
`NEGOTIATION`	→	`ABANDONED`	TERMINAL	—	—
`NULL (initial)`	→	`INTENT`	—	—	—

Section 5

Database-Level Invariants

Critical business rules are enforced by PostgreSQL triggers — not application code. Rules are catalogued at 4 levels of progressively broader scope: attribute → tuple → table → database. Business logic lives in the database, not scattered across microservices.

19 constraints catalogued — live from proc_db_constraints.

attribute— 5 constraints

Table	Constraint	Description	Enforcement	Reversible
`proc_dispute_states`	`valid_dispute_type`	dispute_type must be one of: price_variance, qty_variance, missing_gr, sku_mismatch, multi — set at INSERT and semantically immutable	CHECK	no
`tsm_offerings`	`unit_price_positive`	unit_price must be greater than 0 — prevents zero-price listings that would corrupt revenue accounting	CHECK	yes
`tsm_transactions`	`valid_state_enum`	current_state must be one of: INTENT, NEGOTIATION, COMMITMENT, EXECUTION, SETTLEMENT, DISPUTED, ABANDONED	CHECK	yes
`tsm_transactions`	`exception_reason_required`	exception_reason must be set when current_state is DISPUTED or ABANDONED — enforced by CHECK constraint	CHECK	no
`tsm_treasury_accounts`	`balance_non_negative`	Treasury compartment balance cannot go below zero — enforced by tsm_guard_treasury_balance() BEFORE UPDATE trigger and CHECK (balance >= 0) constraint	TRIGGER	no

tuple— 4 constraints

Table	Constraint	Description	Enforcement	Reversible
`proc_dispute_states`	`financial_split_integrity`	undisputed_amount + disputed_amount must equal total_invoice_amount within 1 cent — enforced by proc_dispute_invariants() BEFORE INSERT OR UPDATE trigger (De Brock Ch 3: tuple-level constraint)	TRIGGER	no
`tsm_owner_parameters`	`single_current_version`	At most one row can have is_current=true — enforced by partial unique index idx_tsm_params_current; INSERT trigger tsm_rotate_owner_parameters() auto-deactivates previous current version	UNIQUE	yes
`tsm_transactions`	`commitment_requires_negotiation`	Transition to COMMITMENT state requires previous state to be NEGOTIATION — enforced by tsm_guard_commitment() BEFORE UPDATE trigger	TRIGGER	no
`tsm_transactions`	`approval_sig_when_approved`	owner_approval_sig must be set when owner_approved_at is not null — prevents approval records without cryptographic signature	CHECK	yes

table— 5 constraints

Table	Constraint	Description	Enforcement	Reversible
`proc_dispute_states`	`forward_only_state_machine`	Dispute states can only advance forward in the transition relation — backward transitions and invalid jumps rejected by proc_dispute_invariants() using proc_state_machines lookup table. De Brock Ch 5: Transition Relations	TRIGGER	no
`tsm_ledger_events`	`immutable_ledger`	Double-entry GAAP ledger entries cannot be updated or deleted — BEFORE UPDATE/DELETE trigger raises exception. amount_eur is a tamper-evident GENERATED column	TRIGGER	no
`tsm_order_transitions`	`immutable_order_audit`	Order state transition rows cannot be updated or deleted — BEFORE UPDATE/DELETE trigger raises exception	TRIGGER	no
`tsm_price_changes`	`immutable_price_history`	Pricing audit rows cannot be updated or deleted — tsm_log_price_change() AFTER UPDATE trigger writes entries that are immediately locked by BEFORE UPDATE/DELETE trigger	TRIGGER	no
`tsm_state_transitions`	`immutable_audit_log`	State transition rows cannot be updated or deleted — BEFORE UPDATE/DELETE trigger raises exception. 10-year retention enforced by retention_until generated column. De Brock Ch 5: irreversible transitions (Definition 5.2)	TRIGGER	no

database— 5 constraints

Table	Constraint	Description	Enforcement	Reversible
`proc_dispute_states`	`evidence_gated_transitions`	EVIDENCE_RECEIVED requires supplier_document_path; SOVEREIGN_OVERRIDE requires token_hash and override_reason; terminal states (RELEASED, SOVEREIGN_OVERRIDE) require resolved_at — all enforced cross-field by proc_dispute_invariants()	TRIGGER	no
`proc_gr_lines`	`webshop_fulfillment_trigger`	Every goods receipt line INSERT fires proc_fulfill_waiting_webshop_orders() which traces GR to PO to req to tsm_order chain, updates proc_inventory.qty_on_hand, sets procurement_status=FULFILLED, and updates tsm_orders.fulfillment_payload atomically	TRIGGER	no
`tsm_offerings`	`price_floor_enforcement`	Offering unit_price cannot drop below COGS x (1 + floor_margin) — tsm_validate_price_floor() BEFORE UPDATE trigger reads tsm_pricing_rules cross-table to compute the floor at write time	TRIGGER	no
`tsm_treasury_accounts`	`liquidity_guard`	COMMITMENT transitions require OPERATING balance >= committed_amount + min_reserve_balance — tsm_guard_commitment() checks tsm_available_liquidity() and tsm_owner_parameters cross-table in a single BEFORE UPDATE trigger	TRIGGER	no
`tsm_withdrawal_requests`	`withdrawal_from_profit_only`	Withdrawal requests must reference the PROFIT treasury compartment only — enforced by CHECK constraint on the account_type FK join	CHECK	no

Section 6

Workflow Invariants

Mathematical safety guarantees baked into the database. A place invariant is a conservation law — the weighted sum of tokens across a set of workflow states stays constant regardless of what sequence of operations fires. A transition invariant proves that every work item can reach a terminal state: no business process can get permanently stuck, and no capital is ever created or destroyed.

9 place invariants · 7 transition invariants — live from proc_net_place_invariants + proc_net_transition_invariants. Verified by proc_check_place_invariants().

Live token counts from proc_check_place_invariants() — actual_sum = current work in flight across each invariant's places. Expected 0 when system is idle; N > 0 = N active tokens (healthy live system). Negative values or unexpected spikes indicate structural anomalies.

0adverse event lifecycle conservation

3analysis cycle conservation

0capital deployment conservation

0document lifecycle conservation

0entity lifecycle conservation

0invoice lifecycle conservation

0invoice matching single active

0purchase order lifecycle conservation

9requisition lifecycle conservation

🔗

Hash chain integrity: 100% — all token movements cryptographically verified

1 chain links verified via proc_check_chain_integrity() · SHA-256 · FDA 21 CFR Part 11 §11.70

Place Invariants — Conservation Laws

Invariant	Places (weight vector)	Guarantee	Status
adverse event lifecycle conservation	`ae_closedae_triagedae_receivedae_escalatedae_regulatory_notifiedae_under_investigation`	Conservation law: no adverse event token is created or destroyed outside defined transitions.	0 active idle
analysis cycle conservation	`scout_runningscout_triggeredarchitect_analysingarchitect_triggered`	Proves analysis agents do not accumulate in-flight tokens — each analysis cycle completes cleanly.	3 active work in flight
capital deployment conservation	`satellite_capital_deployedsatellite_capital_returned`	Spawn debits core PROFIT; close credits core OPERATING. Net capital flow across full lifecycle sums to zero.	0 active idle
document lifecycle conservation	`doc_draftdoc_retireddoc_approveddoc_effectivedoc_supersededdoc_under_reviewdoc_pending_approval`	Every document reaches a terminal state (superseded, retired) or stays effective.	0 active idle
entity lifecycle conservation	`entity_activeentity_winding_downentity_underperforming`	Counts entities in non-terminal lifecycle states. Zero = idle; N > 0 = N active satellite businesses in operation.	0 active idle
invoice lifecycle conservation	`invoice_matchedinvoice_approvedinvoice_disputedinvoice_receivedinvoice_matching_activeinvoice_payment_scheduled`	Proves every invoice reaches either payment or dispute resolution — no invoice is silently abandoned.	0 active idle
invoice matching single active	`invoice_matching_active`	Mathematical proof that parallel invoice matching for the same PO is structurally impossible. The capacity=1 constraint and this invariant together guarantee serialisation.	0 active idle
purchase order lifecycle conservation	`po_sentpo_draftingpo_confirmedidoc_generating`	Proves every purchase order moves through the defined lifecycle without silent failures.	0 active idle
requisition lifecycle conservation	`requisition_approvedrequisition_rejectedrequisition_screeningrequisition_submittedrequisition_pending_approval`	Proves requisitions are neither created nor destroyed outside the defined transition relation. Each requisition has exactly one active token at any point.	9 active work in flight

Transition Invariants — Complete Cycles

Cycle	Transitions	Places Covered	Minimal
capa completion cycle Every CAPA action must either complete or be cancelled. No CAPA can be created and never resolved.	`capa_cancel_firescapa_create_firescapa_complete_fires`	`capa_pendingcapa_in_progresscapa_completedcapa_cancelled`	yes
market intelligence cycle Periodic analysis cycle: market scout fires (gathers competitor data) → architect fires (analyses data and writes proposals). Both source-to-sink flows complete independently.	`architect_firesmarket_scout_fires`	`scout_triggeredscout_runningarchitect_triggeredarchitect_analysing`	yes
requisition rejection cycle Cycle covering rejected requisitions: req_screener fires once and routes the token to the rejected sink. No PO is created. This is a valid complete cycle.	`req_screener_fires`	`requisition_submittedrequisition_screeningrequisition_pending_approvalrequisition_rejected`	yes
sop must reach terminal or effective Every SOP draft must eventually reach either effective or a terminal state. No SOP can be permanently stuck in review.	`sop_reject_firessop_submit_firessop_approve_fires`	`doc_draftdoc_under_reviewdoc_pending_approvaldoc_approveddoc_effective`	yes
spawn close cycle Every spawn_business transition must eventually be followed by proc_close_satellite or remain active — no entity stuck in spawning state	`spawn_business_firesproc_close_satellite_fires`	`entity_activeentity_terminal`	yes
standard procurement cycle The canonical happy-path cycle: requisition screened → PO drafted → invoice matched. All three AI-agent transitions fire once per procurement unit. Covers the full procure-to-pay workflow.	`po_drafter_firesreq_screener_firesinvoice_matcher_fires`	`requisition_submittedrequisition_screeningrequisition_approvedpo_draftingpo_sentpo_confirmed`+5 more	yes
susar 7day reporting cycle Every SUSAR must complete: received → triaged → regulatory_notified within 7 calendar days.	`ae_triage_firesae_receive_firesae_regulatory_notify_fires`	`ae_receivedae_triagedae_regulatory_notified`	yes

Section 7

Technology Stack

Next.js 16 (×3)

V1 :3000 · V2 :3001 · V5 :3004

Supabase Postgres

PostgreSQL 16 + RLS + pgvector

pgvector

HNSW 1536-dim agent memory

pg_net

Async HTTP from SQL triggers

OpenRouter LLM

claude-opus-4-6 · gemini-flash OCR

Edge Functions (14)

6 deployed · 8 via spawned_agent

Telegram Bot API

Employee requisition channel

SAP ORDERS05

IDoc XML via idoc-architect

Cross-Vertical Bus

Proprietary DB-native event isolation

GitHub Actions CI

Lint · build · pgTAP · smoke tests