SBS & Packet Templates

Canonical templates for the Section Build Specification (SBS) and Build Packet structure. The SBS is the machine-readable contract between the specification and the Code Factory. Patches P1–P19 applied (Gemini Audit Rounds 1 & 2). Patches P20–P38 applied (Round 4).

Loading compliance data...

The Build Chain: Section → SBS → Build Packets → Code

The HIRO system is specified across two documents. The Genesis Framework defines what HIRO does (87 sections). The Hilbert Factory defines how it gets built (51 sections). Every section in both documents ends with exactly one Section Build Specification (SBS) — a structured contract that the Code Factory uses to generate production code. When a section is too large for a single build task, the SBS is decomposed into multiple Build Packets through a defined process.

The Three Layers

Layer 1

Section

The full specification. Detailed prose covering purpose, architecture, algorithms, edge cases, interactions, and dashboard requirements. Written for humans to understand the system.

→

Layer 2

SBS

One per section. The machine-readable contract appended at the end of the section. Structured tables: Functionality, Code, Dashboards. Contains everything the section specifies in a buildable format.

→

Layer 3

Build Packets

One or more per SBS. Each packet targets one specific build task. Simple sections produce 1 packet carrying the full SBS. Complex sections are decomposed into multiple packets through a defined process.

Rule: One Section = One SBS

Every section has exactly one SBS appended at its end. The SBS covers the entire section — all functionality, all code, all dashboards defined in that section. It uses the same canonical format in both Genesis and Factory (see the SBS tab for the template).

The SBS is not a summary — it is a contract. If the SBS says Key Classes: PhaseGateController, PhaseActivator, GateProofGenerator, the Builder Agent creates exactly those classes. If the SBS says Storage: PostgreSQL: gate_evaluations, phase_transitions, the Builder Agent creates exactly those tables.

From One SBS to Multiple Build Packets

When a section's SBS describes more than one distinct buildable component, it must be decomposed into multiple Build Packets. This decomposition is governed by strict rules.

Rule 1: The Atomic Component Rule

An SBS is decomposed based on buildability. If a component (e.g., a database schema) can be deployed and health-checked independently of another (e.g., a dashboard panel), it must be its own packet.

Rule 2: The No-Overlap Rule (The Partition)

The decomposition must be a mathematical partition of the SBS. No shared classes or tables between packets — every item belongs to exactly one packet. The union of all packets equals the complete SBS — nothing is left behind.

Packet A ∩ Packet B = ∅ (no overlap)
∑ Packets = SBS (complete coverage)

P29 Ownership vs Access Clarification: "No overlap" means write ownership — each table, class, and resource has exactly one packet that CREATES and WRITES to it. Read access is unrestricted — any packet may READ from resources owned by upstream deps, provided: (a) the owning packet is in upstream_deps, (b) dependency_signatures include the schema or interface, (c) the reading packet does NOT modify the resource. A table owned by BP1 may be read by BP2 without violating Rule 2.

Rule 3: The Faithful Extraction Rule P4

The packet's sbs_content is extracted from the parent SBS with two modes:

a) STRUCTURAL VERBATIM: Headings, table structure, column names, and metadata are reproduced exactly. No rewording, no restructuring.

b) ROW-LEVEL PARTITIONING: For multi-item rows (Business Rules, Kill Conditions, Shared Parameters, Performance Targets, Key Classes, Data Structures, Numerical Constants), the packet receives ONLY the specific list items within its SBS Scope. Items are not reworded — either included verbatim or excluded entirely.

Forbidden: Paraphrasing, summarising, or rewording any SBS content. The only permitted operation is selection (include/exclude).

Rule 3 Addendum: Minimal Context Delivery P13

The packet's sbs_content SHALL contain ONLY:

The SBS Header metadata line (always included for traceability)
BROADCAST rows (Purpose, Language, Genesis References) — full content
PARTITION rows — only the specific items assigned to this packet
FILTERED rows — only the items relevant to this packet's scope
This packet's own row from the Packet Map

EXCLUDED from sbs_content:

Other packets' Packet Map rows
PARTITION items assigned to other packets
Empty rows — if a row has no items for this packet, omit the row entirely
The Changelog (available via source_sbs_link, not duplicated in every packet)

Verification: The Preflight SHALL check that no packet's sbs_content contains scope keys (CLASS:, TABLE:, RULE:, etc.) that are NOT in that packet's SBS Scope column.
Rationale: The Builder Agent's context window is finite. Every irrelevant token increases the probability of instruction confusion and hallucination.

Rule 4: The Inheritance Policy P12

When decomposing an SBS into packets, multi-item rows are distributed according to these explicit rules:

PARTITION rows (each item goes to exactly ONE packet):

Key Classes → assigned by CLASS:{name} in SBS Scope
Data Structures → assigned by DS:{name} in SBS Scope
Storage / Tables → assigned by TABLE:{name} in SBS Scope
Dashboard Panels → assigned by PANEL:{name} in SBS Scope
Business Rules → assigned by RULE:{id} in SBS Scope
Kill Conditions → assigned by KILL:{id} in SBS Scope
Numerical Constants → assigned by NC:{id} in SBS Scope

BROADCAST rows (every packet receives the full content):

Purpose → all packets inherit (context)
Language → all packets inherit
Genesis References → all packets inherit

FILTERED rows (packet receives only items it references):

Shared Parameters → packet receives only parameters where it owns a class/function that reads or writes that parameter
Performance Targets → packet receives only targets applicable to its component
Inputs / Outputs → packet receives only the I/O interfaces its classes produce or consume

Verification: The Preflight SHALL check: PARTITION items — union across all packets = full SBS set, no overlaps; BROADCAST items — every packet contains them identically; FILTERED items — every item appears in at least one packet.

Rule 5: Complexity Budget Rule P19

The total estimated_effort across all packets in an SBS has a soft ceiling of 15 Complexity Points.

Total Points	Status	Action
≤ 10	GREEN	Normal decomposition
11–15	AMBER	Review decomposition for further splits
> 15	RED	Mandatory re-decomposition required

Per-Packet Limit: No single packet may have estimated_effort = 5 (Critical) unless it has been explicitly reviewed and approved in the SBS changelog, the review documents WHY it cannot be further decomposed, and a complexity_justification field is populated in the packet metadata.
Rationale: Builder Agent reliability degrades with packet complexity. Packets rated 4–5 have the highest incidence of Key Classes truncation, fabricated routing, and missed event dependencies.

Rule 6: Dependency Order

Packets within an SBS must be buildable in a topological order. Circular dependencies within a single SBS are a decomposition error and must be resolved before the SBS can be verified.

Rule 7: Testability

Every packet must include a verification criterion that can be evaluated by the Verifier Agent without access to future packets. A packet whose correctness can only be determined after a downstream packet is built fails this rule.

Hard Gate: Completeness Check

The Preflight system sums the SBS Scope column across all packets in the Packet Map. If any Key Class, Storage table, or Dashboard panel from the parent SBS is missing from the Packet Map, the SBS fails verification and the build is blocked. If any item appears in more than one packet, the SBS fails the No-Overlap rule.

Decomposition Process

Step	Process	Output
1. Identify Components	Read the SBS Key Classes, Storage, and Dashboards rows. Each distinct class group, database schema, or dashboard panel that can be independently built and tested is a candidate component.	List of candidate components
2. Define Boundaries	For each component, define what it owns: which Key Classes, which Storage tables, which Dashboard panels. Apply Rule 2: no overlap, nothing unassigned. Use typed keys (CLASS:, TABLE:, PANEL:, RULE:, NC: etc.) — no free text.	Component boundary map
3. Determine Dependencies	Identify which components depend on which. If Component B reads from a table that Component A creates, then B depends on A. These become the packet's `upstream_deps`.	Dependency graph
4. Create Packets	For each component, create a Build Packet. Apply Rule 3: the packet's `sbs_content` contains verbatim extracted rows from the parent SBS — only the rows relevant to this component. No rewording. Apply Rule 3 Addendum: minimal context only.	One Build Packet per component
5. Build Packet Map	Append a Packet Map Table to the end of the parent SBS. This is the manifest that lists every packet, its typed-key scope, and its dependencies.	Packet Map Table in parent SBS
6. Verify Completeness	Machine check. Sum the "SBS Scope" column of the Packet Map. Every Key Class, Storage table, and Dashboard panel from the SBS must appear in exactly one packet row. If any item is missing or duplicated, the build is blocked.	Coverage verification (PASS/FAIL)

Packet Map — SBS Scope Format P5

Every packet's scope in the Packet Map is a structured list of typed keys drawn from the parent SBS rows. Free-text scope descriptions are rejected by the Preflight.

Prefix	Source Row	Example
CLASS:{ClassName}	Key Classes row	CLASS:PostgreSQLManager
DS:{StructureName}	Data Structures row	DS:OperatorSnapshot
TABLE:{table_name}	Storage row	TABLE:backup_config
PANEL:{PanelName}	Dashboards table	PANEL:BackupStatusPanel
RULE:{RuleID}	Business Rules row	RULE:B1, RULE:B3
PARAM:{param_name}	Shared Parameters row	PARAM:lambda_decay
TARGET:{TargetID}	Performance Targets row	TARGET:T1, TARGET:T2
KILL:{KillID}	Kill Conditions row	KILL:K1, KILL:K2
NC:{ConstantID} P9	Numerical Constants row	NC:NC2, NC:NC3
EVT:{EventID} P21	Events Emitted row	EVT:EVT_OPERATOR_PROMOTED

Example Scope

CLASS:PostgreSQLManager, CLASS:WALArchiver, TABLE:backup_config, TABLE:retention_policy, RULE:B1, RULE:B3, NC:NC2

Preflight rules: Every key MUST exist in parent SBS rows. Union of all packet scopes MUST equal the complete SBS key set. No key may appear in more than one packet. Free-text scope → error SCOPE_FORMAT_INVALID.

The Packet Map Table

Every SBS that produces more than one packet must include a Packet Map Table at the end. This is the "shipping manifest" — it defines exactly which packet owns which part of the SBS.

Rendered Example — Packet Map for FAC-SBS29

Packet Map

Packet ID	Component	SBS Scope	Upstream Deps
FAC-SBS29-BP1-13	PostgreSQL schema	`CLASS:PostgreSQLManager, CLASS:WALArchiver, TABLE:backup_config, TABLE:retention_policy, RULE:B1, RULE:B2`	None
FAC-SBS29-BP2-13	Redis configuration	`CLASS:RedisConfigManager, CLASS:CachePolicy, TABLE:cache_config, RULE:B3`	FAC-SBS29-BP1-13
FAC-SBS29-BP3-13	Systemd services	`CLASS:ServiceManager, CLASS:ProcessMonitor, RULE:B4`	FAC-SBS29-BP1-13
FAC-SBS29-BP4-13	Health check endpoint	`CLASS:HealthChecker, CLASS:StatusAggregator, TABLE:health_log, PANEL:SystemHealthPanel`	FAC-SBS29-BP1-13, FAC-SBS29-BP2-13
...BP5 through BP13 abbreviated for display. Production Packet Maps MUST list every row explicitly — no ellipsis permitted.

Single-Packet Sections

When an SBS produces only one packet (e.g., FAC-SBS37B-BP1-1), the Packet Map Table contains a single row and the packet's sbs_content is the full SBS content verbatim. No decomposition is needed. The Packet Map is still required — it confirms that the section has been assessed and deliberately assigned to one packet rather than accidentally left as a monolith.

The Build Flow

Step	What Happens	Input	Output
1. Specification	Genesis Framework and Hilbert Factory are written as detailed prose sections.	Domain knowledge, architecture decisions	87 Genesis sections + 51 Factory sections
2. SBS Authoring	Each section gets one SBS appended at its end — structured tables covering all functionality, code, and dashboards in that section. Source section content is MD5-hashed and stored as `source_hash`.	Full section content	One SBS per section
3. Integrity Monitoring P6	On every build cycle, the current MD5 hash of each parent section is compared to the stored `source_hash`. If they differ: SBS auto-flips to STALE, all child packets cascade to STALE, build queue is blocked, dashboard shows amber warning.	Live section content	CURRENT / STALE verdict per SBS
4. Decomposition	Each SBS is analysed to determine how many Build Packets it requires. Simple sections → 1 packet. Complex sections → multiple packets via the decomposition rules above.	SBS + component analysis	1–N Build Packets per section
5. Preflight	Validates all packets: correct SBS format, no duplicates, no broken dependencies, no scope overlap, typed-key format, path latency check, cycle detection, artefact path uniqueness.	All packets + all sections	READY / NEEDS ATTENTION verdict
6. Build	The Builder Agent receives one packet at a time. It reads the `sbs_content` (minimal context, P13) and `dependency_signatures` (P7) and generates production code implementing exactly what the SBS specifies.	One Build Packet	Production code files
7. Verification	The Verifier Agent (independent from the Builder) checks that generated code matches the SBS contract — correct classes, correct storage, correct business rules.	Generated code + packet SBS	Verification Proof Object (PASS/FAIL)
Build Abort Protocol P35	During any active build wave, if: (a) a packet's upstream dep flips to STALE, (b) a build fails verification, (c) a source SBS hash mismatches, or (d) Guardian issues BUILD_HALT — then: 1. ALL in-progress builds in the same wave are PAUSED. 2. The Factory evaluates blast radius (which downstream packets depend on the failed packet). 3. Affected packets → BLOCKED with reason. 4. Unaffected packets in the same wave may RESUME. 5. Compliance Status shows: BUILD WAVE ABORT: Wave N, Step N — Trigger, Blocked list, Unaffected list. Rule: No packet may proceed to build if any upstream dep is not in VERIFIED state. Checked CONTINUOUSLY during build, not just at queue entry.	Build integrity event	Partial wave completion + BLOCKED status on affected packets

Key Relationships P2

Relationship	Cardinality	Description
Section → SBS	1 : 1	Each section has exactly one SBS. The SBS covers the entire section's specification and tracks its `source_hash` for stale detection.
SBS → Build Packets	1 : N	Each SBS produces one or more packets. Simple SBS → 1 packet. Complex SBS → multiple packets via the decomposition process.
Build Packet → sbs_content	1 : 1	Each packet carries a minimal-context SBS subset in its `sbs_content` field. Content is verbatim-extracted from the parent SBS; only scope-relevant rows included (Rule 3 Addendum).
Packet → Packet	N : N	Packets reference other packets via `upstream_deps`. The `dependency_signatures` field carries the interface contracts exported by each upstream packet.
SBS → Global Parameter Registry P2	N : 1	Every Shared Parameter listed in an SBS MUST be registered in the Global Parameter Registry (Settings dashboard). The Registry is the single source of truth for cross-section parameter ownership and direction (PUBLISH / CONSUME).
SBS → Code	Contract	The SBS is the contract the Builder Agent implements. Key Classes become real class names. Storage becomes real tables. Dashboards become real UI panels.

Naming Convention P1

The naming convention is designed so that any identifier instantly tells you which document it belongs to, which section, and for packets — which build task and how many exist. IDs are regex-validated; the Preflight rejects any non-conforming identifier.

SBS Identifier

FAC-SBS29

Regex: ^(GEN|FAC)-SBS(\d+[A-Z]{0,3})$

FAC

Code Factory

SBS29

Section 29's SBS

Build Packet Identifier

FAC-SBS29-BP1-3

Regex: ^(GEN|FAC)-SBS(\d+[A-Z]{0,3})-BP(\d+)-(\d+)$

FAC

Code Factory

SBS29

Section 29

BP1

Packet 1

of 3 total

Collision Rule P1

No two sections may share the same numeric prefix unless distinguished by an alpha suffix (e.g. "37" vs "37A"). The Preflight SHALL reject any SBS ID that does not match the regex above.

Component	Values	Meaning
{Document}	GEN or FAC	GEN = Genesis Framework. FAC = Code Factory (Hilbert Factory). Identifies which specification document this belongs to.
SBS{section}	SBS + number or letter	Identifies the Section Build Specification. Matches the section ID in the source document. e.g. SBS29, SBS37B, SBSE
BP{n}	BP + packet number	Which Build Packet this is within the section. Only present on Build Packet identifiers.
{total}	Total packet count	How many Build Packets exist for this section. Tells you at a glance whether the SBS was decomposed.

Examples

Identifier	Type	Reading
GEN-SBS3	SBS	Genesis Framework, Section 3 (The Data Foundation)
FAC-SBS29	SBS	Code Factory, Section 29 (Operational Framework)
FAC-SBS29-BP1-13	Packet	Factory §29, Build Packet 1 of 13 (PostgreSQL factory schema)
FAC-SBS37B-BP1-1	Packet	Factory §37B (Private Key & Wallet Governance), single packet — SBS was not decomposed
GEN-SBS37A-BP1-1	Packet	Genesis §37A, single packet

Traceability

FAC-SBS29-BP1-13 (PostgreSQL factory schema)
  ↑ FAC = Factory document. SBS29 = Section 29. BP1-13 = packet 1 of 13.
  ↓ Source SBS
FAC-SBS29 — SBS appended at end of §29 in hilbert-factory.html
  ↓ Genesis References row in SBS
GEN-SBS29 — corresponding Genesis section (S29: Infrastructure & Operational Standards)

Current State

Metric	Expected	Actual
Genesis sections with SBS	87 of 87	84 of 87
Factory sections with SBS	51 of 51	58 (some subsections also have SBS)
Packets with proper SBS format	97 of 97	5 of 97
Packets with unique sbs_content	97 of 97	44 of 97 (53 are duplicates)
Factory SBS heading format	All use canonical format	58 use "BUILD SPECIFICATION KEY POINTS" instead of canonical format

Full Example — §1 Document Precedence Order (hilbert-factory.html)

Section Build Specification (SBS)

Build Specification Key Points

Section Build Specification (SBS). These key points are the machine-readable contract between this specification and the Code Factory.

FAC-SBS1: Document Precedence Order

Source: hilbert-factory.html#s1

Status: Verified

Packets: FAC-SBS1-BP1-1

v1 | 2026-02-10T09:00:00Z

Functionality

Aspect	Specification
Purpose	Document hierarchy enforcement with 8-tier precedence order. Conflict detection across 5 detection points. Resolution state machine (4 states). PrecedenceRule schema (12 fields).
Inputs	All governing documents (Genesis, Hilbert, Appendix A, Packets). Schema validation results. Gate evaluation results. Prompt construction output.
Outputs	Conflict detection events, resolution records, precedence rule entries in Knowledge Graph, auto-resolution actions
Business Rules	B1. Higher-tier document always prevails. B2. Tier 1–2 violations = HARD_HALT. B3. Auto-resolution target > 95%. B4. Same-tier conflicts escalated to Chief Engineer or Council.
Shared Parameters	auto_resolution_target \| S9, S25 \| PUBLISH. conflict_severity \| S9, S27 \| PUBLISH.
Genesis References	Appendix A (verification authority), all Genesis sections (subject to precedence enforcement)

Code

Aspect	Specification
Language	Python (precedence engine, conflict detection, resolution state machine)
Key Classes	PrecedenceResolver: determines winning document in any conflict. ConflictDetector: scans for cross-document conflicts at 5 detection points. ResolutionStateMachine: DETECTED→ANALYSED→AUTO_RESOLVED or ESCALATED→RESOLVED. PrecedenceRuleStore: CRUD for PrecedenceRule entities.
Data Structures	PrecedenceRule: 12-field schema (rule_id, source_document, source_tier, target_document, target_tier, conflict_type, conflict_detail, resolution, resolved_by, detection_point, timestamp, schema_version).
Storage	Knowledge Graph: precedence rules, conflict history. PostgreSQL: conflict_event_log.

Dashboards

Panel	Chart Type	Metrics	Refresh	Interactions
Active Conflicts	TABLE	All DETECTED and ESCALATED conflicts with source, target, type, detection point, age	On event	Click conflict → resolution detail
Precedence Hierarchy	TREE	8-tier document hierarchy with current conflict count per tier	On change	Click tier → filter conflicts by tier
Auto-Resolution Rate	GAUGE + TREND	Percentage auto-resolved vs escalated. 30-day trend. Target: > 95%	Hourly	Click → escalation breakdown

Packet Map

Packet ID	Component	SBS Scope	Upstream Deps
FAC-SBS1-BP1-1	Document Precedence Order	`CLASS:PrecedenceResolver, CLASS:ConflictDetector, CLASS:ResolutionStateMachine, CLASS:PrecedenceRuleStore, TABLE:conflict_event_log, PANEL:ActiveConflicts, PANEL:PrecedenceHierarchy, PANEL:AutoResolutionRate, RULE:B1, RULE:B2, RULE:B3, RULE:B4`	None

FULL EXAMPLE — L5 TRADING INTELLIGENCE (GENESIS.HTML) — SHOWS ALGORITHMS, NUMERICAL CONSTANTS & PERFORMANCE TARGETS

This example demonstrates the conditional rows (Algorithms, Numerical Constants, Performance Targets) that are REQUIRED for L4–L6 sections. Compare with the FAC-SBS1 example above, which correctly omits these rows because it is an infrastructure section.

Section Build Specification (SBS)

Build Specification Key Points

Section Build Specification (SBS). These key points are the machine-readable contract between this specification and the Code Factory.

GEN-SBS12: Operator Lifecycle & Fitness Evaluation

Source: genesis.html#s12

Status: Verified

Packets: GEN-SBS12-BP1-3, GEN-SBS12-BP2-3, GEN-SBS12-BP3-3

v2 | 2026-03-10T14:30:00Z

Functionality

Aspect

Specification

Purpose

Operator fitness evaluation using Risk-Adjusted Return (RAR). Lifecycle state machine governing operator promotion, demotion, quarantine, and retirement. Capital allocation adjustment based on rolling fitness scores.

Inputs

Trade execution records (from Execution Layer L6). Market data snapshots (from Data Layer L2). Portfolio state (positions, P&L, drawdown). Operator metadata (generation, lineage, creation timestamp).

Outputs

RAR scores per operator (published to C-Space). Lifecycle state transitions (events to EventBus). Capital reallocation signals (to CFU Allocator). Operator retirement records (to Knowledge Graph).

Algorithms

RAR Calculation (Rolling Window):
RAR(t) = (R(t) − R_f) / σ(R, w)
Where:
  • R(t) = operator return at time t
  • R_f = risk-free rate (NC1)
  • σ(R, w) = standard deviation of returns over rolling window w (NC2)
  • RAR is clamped to [0, 1] via sigmoid normalisation

Exponential Decay Weighting:
w_i = λ^(t − t_i)
Where:
  • λ = decay factor (NC3), controls how quickly old performance fades
  • t = current time, t_i = time of trade i
  • Applied to return series before σ calculation

Promotion/Demotion Thresholds:
  • If RAR(t) ≥ promotion_threshold (NC4) for sustained_periods (NC6) consecutive periods → PROMOTE
  • If RAR(t) ≤ demotion_threshold (NC5) for sustained_periods (NC6) consecutive periods → DEMOTE
  • If RAR(t) ≤ quarantine_threshold (NC7) at any single evaluation → QUARANTINE immediately

Sigmoid Normalisation:
σ_norm(x) = 1 / (1 + e^(−NC12 × (x − NC13)))
Where: NC12 = sigmoid_k = 10.0, NC13 = sigmoid_x0 = 0.5

Boundary Conditions:
BOUNDARY: σ(R, w) < 1e-9 → RAR = 0.0, skip evaluation, emit SkippedEvaluationEvent
BOUNDARY: R(t) overflow (|R| > 1e6) → cap to ±1e6, emit HIROCalculationError
BOUNDARY: trade_count < NC10 → RAR = 0.0, skip evaluation
BOUNDARY: σ_norm output > 1.0 or < 0.0 → clamp to [0, 1] (floating point guard)

Numerical Constants

ID	Name	Value	Unit	Source	Mutable
NC1	risk_free_rate	0.0425	annual rate	S04 §4.1	YES — config
NC2	rolling_window	30	trading days	S12 §12.3	YES — Guardian
NC3	lambda_decay	0.95	dimensionless	S04 §4.2	YES — Guardian
NC4	promotion_threshold	0.7	RAR score [0,1]	S12 §12.4	YES — Guardian
NC5	demotion_threshold	0.3	RAR score [0,1]	S12 §12.4	YES — Guardian
NC6	sustained_periods	5	consecutive evaluations	S12 §12.4	YES — config
NC7	quarantine_threshold	0.15	RAR score [0,1]	S12 §12.4	YES — Guardian
NC8	probation_allocation	0.005	fraction of total capital	S16 §16.2	YES — config
NC9	minimum_evaluation_periods	10	evaluation cycles	S12 §12.5	NO — Canon Law
NC10	min_trades	20	trade count	S12 §12.3	NO — Canon Law
NC11	max_drawdown	0.08	fraction of allocation	S31 §31.1	YES — Guardian
NC12	sigmoid_k	10.0	dimensionless	S12 §12.2	YES — Guardian
NC13	sigmoid_x0	0.5	dimensionless	S12 §12.2	YES — Guardian

Logic

1. Collect trade records for evaluation window. 2. Apply exponential decay weighting. 3. Calculate RAR score. 4. Compare against promotion/demotion/quarantine thresholds. 5. Execute lifecycle state transition if triggered. 6. Publish updated RAR to C-Space. 7. Signal CFU reallocation if state changed.

Business Rules

B1: Operators below quarantine_threshold are immediately suspended — no further trades until manual review. B2: Newly created operators receive probation_allocation (NC8) and cannot be promoted until minimum_evaluation_periods (NC9) have elapsed. B3: Retired operators are archived in Knowledge Graph with full trade history — never deleted. B4: RAR calculation must use at minimum min_trades (NC10) data points; insufficient data → RAR = 0.0 (not evaluated).

Kill Conditions

K1: If > 30% of active operators are in QUARANTINE simultaneously → SAFE_MODE (systemic signal). K2: If any single operator's drawdown exceeds max_drawdown (NC11) → immediate QUARANTINE regardless of RAR.

Performance Targets

T1: RAR calculation latency ≤ 15ms per operator. T2: Full cohort evaluation (up to 500 operators) ≤ 3 seconds. T3: Lifecycle state transition event published ≤ 5ms after decision.

Shared Parameters

lambda_decay | S04 | CONSUME. risk_free_rate | S04 | CONSUME. rar_scores | S12 | PUBLISH. operator_states | S12 | PUBLISH. cfu_reallocation_signal | S16 | PUBLISH.

Events Emitted

Event ID	Trigger	Payload Fields	Schema
EVT_OPERATOR_PROMOTED	RAR ≥ NC4 for NC6 consecutive periods	operator_id: str, new_state: str, rar_score: float, previous_state: str, timestamp: ISO8601	OperatorLifecycleEvent
EVT_OPERATOR_DEMOTED	RAR ≤ NC5 for NC6 consecutive periods	operator_id: str, new_state: str, rar_score: float, previous_state: str, timestamp: ISO8601	OperatorLifecycleEvent
EVT_OPERATOR_QUARANTINED	RAR ≤ NC7 at any evaluation	operator_id: str, reason: str, rar_score: float, timestamp: ISO8601	OperatorLifecycleEvent
EVT_OPERATOR_RETIRED	Guardian or lifecycle policy triggers retirement	operator_id: str, generation: int, final_rar: float, trade_count: int, timestamp: ISO8601	OperatorRetiredEvent

Temporal Anchor

Evaluation trigger: hybrid (event-driven + time-driven)
Frequency: once per trading day at market close for rolling RAR; on every new trade event for real-time RAR update
Time basis: trading_days (rolling_window NC2), wall_clock_seconds (latency targets T1, T3)
Timezone: UTC
Note: NC2 (rolling_window = 30 trading days) and NC6 (sustained_periods = 5 consecutive evaluations) both refer to the daily evaluation cycle.

Genesis References

S04 (Mathematical Foundations), S08 (Execution Layer), S16 (Capital Allocation), S31 (Risk Envelope), S33 (Guardian).

Code

Aspect	Specification
Language	Python (fitness engine, lifecycle state machine, C-Space publisher)
Key Classes	RARCalculator: computes Risk-Adjusted Return using rolling window with exponential decay — implements RAR formula and sigmoid normalisation. LifecycleStateMachine: manages operator states PROBATION → ACTIVE → PROMOTED / DEMOTED / QUARANTINED → RETIRED, enforces threshold-based transitions. FitnessPublisher: publishes RAR scores to C-Space embeddings and lifecycle events to EventBus.
Data Structures	OperatorFitnessRecord: (operator_id, generation, rar_score, state, last_evaluation, trade_count, creation_ts, lineage_hash).
Storage	PostgreSQL: operator_fitness_log, lifecycle_transitions. Redis: rar_cache (key: operator:{id}:rar, TTL: 60s). Knowledge Graph: retired operator archives.
Fault Tolerance	Raises HIROCalculationError when σ < 1e-9 (undefined RAR). Raises HIRODataError when trade_count < NC10 (insufficient data). Returns RAR = 0.0 and emits SkippedEvaluationEvent on data insufficiency. On HIROIntegrationError (upstream DB unavailable): retry 3× with 500ms backoff, then serve cached RAR score with STALE flag. Circuit breaker: 5 consecutive integration failures in 60s → open circuit for 30s.
Verification Suite	UNIT: 90% line coverage. CRITICAL: σ near-zero returns RAR=0.0; promotion exactly at threshold after sustained_periods; quarantine triggers immediately at NC7; probation blocks promotion for NC9 periods. INTEGRATION: dependency_signatures contract for operator_fitness_log schema. PERF: 500-operator cohort evaluation in <3s (T2), single RAR calculation in <15ms (T1).
Guardian Protocol	HALT: Stop all RAR calculations immediately. Return last cached scores only. Latency ≤ 100ms. SAFE_MODE: Continue calculations but flag all results as UNVERIFIED in C-Space. Latency ≤ 500ms. REDUCE_EXPOSURE: Not applicable (calculator, not executor). EMERGENCY_FLATTEN: Not applicable. RESUME: Resume normal calculation cycle from last checkpointed state. Latency ≤ 1s.

Dashboards

Panel	Chart Type	Metrics	Refresh	Interactions
Operator Fitness Heatmap	HEATMAP	RAR scores for all active operators, colour-coded by state. X: operator ID, Y: time, colour: RAR value	10s	Click operator → detail view with trade history
Lifecycle Flow	SANKEY	Flow of operators between states over selected time period. Width = count of transitions	Hourly	Click flow → list of operators in that transition
RAR Distribution	HISTOGRAM	Distribution of current RAR scores across all active operators. Threshold lines overlaid at NC4, NC5, NC7	10s	Click bin → operator list

Packet Map

Packet ID	Component	SBS Scope	Upstream Deps
GEN-SBS12-BP1-3	RAR Calculation Engine	`CLASS:RARCalculator, TABLE:operator_fitness_log, RULE:B4, NC:NC1, NC:NC2, NC:NC3, NC:NC10, TARGET:T1`	None
GEN-SBS12-BP2-3	Lifecycle State Machine	`CLASS:LifecycleStateMachine, TABLE:lifecycle_transitions, RULE:B1, RULE:B2, RULE:B3, KILL:K1, KILL:K2, NC:NC4, NC:NC5, NC:NC6, NC:NC7, NC:NC8, NC:NC9, NC:NC11, TARGET:T3`	GEN-SBS12-BP1-3
GEN-SBS12-BP3-3	Fitness Publishing & Dashboards	`CLASS:FitnessPublisher, DS:OperatorFitnessRecord, PANEL:OperatorFitnessHeatmap, PANEL:LifecycleFlow, PANEL:RARDistribution, PARAM:rar_scores, PARAM:operator_states, PARAM:cfu_reallocation_signal, TARGET:T2`	GEN-SBS12-BP1-3, GEN-SBS12-BP2-3

Changelog

Version	Date	Author	Summary of Changes
v2	2026-03-10	Claude (P21)	Added NC9 (minimum_evaluation_periods) as Canon Law per Guardian review. Updated B2 to reference NC9. Added Kill Condition K2 (max_drawdown).
v1	2026-02-12	Claude (P15)	Initial SBS creation. 11 numerical constants, 3 packets.

Source Format — Exact Insertable Content

Canonical content structure for both genesis.html and hilbert-factory.html

{ heading: "Section Build Specification (SBS)" },
"Build Specification Key Points",
"Section Build Specification (SBS). These key points are the machine-readable contract between this specification and the Code Factory.",
"FAC-SBS1: Document Precedence Order | Source: hilbert-factory.html#s1 | Status: Verified | Packets: FAC-SBS1-BP1-1 | v1 | 2026-02-10T09:00:00Z",
{ heading: "Functionality" },
{ type: "table", headers: ["Aspect", "Specification"], rows: [
    ["Purpose", "..."],
    ["Inputs", "..."],
    ["Outputs", "..."],
    ["Business Rules", "B1. ... B2. ... B3. ..."],
    ["Shared Parameters", "param_name | owner_section | PUBLISH/CONSUME"],
    ["Genesis References", "..."]
]},
{ heading: "Code" },
{ type: "table", headers: ["Aspect", "Specification"], rows: [
    ["Language", "Python"],
    ["Key Classes", "ClassName: description. ClassName2: description."],
    ["Data Structures", "..."],
    ["Storage", "PostgreSQL: table_name, table_name2. Redis: key_pattern."]
]},
{ heading: "Dashboards" },
{ type: "table", headers: ["Panel", "Chart Type", "Metrics", "Refresh", "Interactions"], rows: [
    ["PanelName", "TABLE", "...", "On event", "Click → ..."]
]},
{ heading: "Packet Map" },
{ type: "table", headers: ["Packet ID", "Component", "SBS Scope", "Upstream Deps"], rows: [
    ["FAC-SBS1-BP1-1", "Document Precedence Order", "CLASS:PrecedenceResolver, TABLE:conflict_event_log, ...", "None"]
]},
{ heading: "Changelog" },
{ type: "table", headers: ["Version", "Date", "Author", "Summary of Changes"], rows: [
    ["v1", "2026-02-10", "Claude (P15)", "Initial SBS creation"]
]}

L5/L6 SOURCE FORMAT — Showing conditional rows (Algorithms, Numerical Constants, Performance Targets)

L5 Trading Intelligence — all rows including Algorithms, Numerical Constants, Performance Targets

{ heading: "Section Build Specification (SBS)" },
"Build Specification Key Points",
"Section Build Specification (SBS). These key points are the machine-readable contract between this specification and the Code Factory.",
"GEN-SBS12: Operator Lifecycle & Fitness Evaluation | Source: genesis.html#s12 | Status: Verified | Packets: GEN-SBS12-BP1-3, GEN-SBS12-BP2-3, GEN-SBS12-BP3-3 | v2 | 2026-03-10T14:30:00Z",
{ heading: "Functionality" },
{ type: "table", headers: ["Aspect", "Specification"], rows: [
    ["Purpose", "Operator fitness evaluation using Risk-Adjusted Return (RAR). Lifecycle state machine governing operator promotion, demotion, quarantine, and retirement."],
    ["Inputs", "Trade execution records (L6). Market data snapshots (L2). Portfolio state. Operator metadata."],
    ["Outputs", "RAR scores per operator (C-Space). Lifecycle state transitions (EventBus). Capital reallocation signals (CFU Allocator)."],
    ["Algorithms", "RAR Calculation: RAR(t) = (R(t) - R_f) / sigma(R, w). Exponential Decay: w_i = lambda^(t - t_i). Thresholds: RAR >= NC4 for NC6 periods -> PROMOTE; RAR <= NC5 for NC6 periods -> DEMOTE; RAR <= NC7 -> QUARANTINE immediately."],
    ["Numerical Constants", "NC1 | risk_free_rate | 0.0425 | annual rate | S04 §4.1 | YES-config. NC2 | rolling_window | 30 | trading days | S12 §12.3 | YES-Guardian. NC3 | lambda_decay | 0.95 | dimensionless | S04 §4.2 | YES-Guardian. NC4 | promotion_threshold | 0.7 | RAR [0,1] | S12 §12.4 | YES-Guardian. NC5 | demotion_threshold | 0.3 | RAR [0,1] | S12 §12.4 | YES-Guardian. NC6 | sustained_periods | 5 | evaluations | S12 §12.4 | YES-config. NC7 | quarantine_threshold | 0.15 | RAR [0,1] | S12 §12.4 | YES-Guardian. NC8 | probation_allocation | 0.005 | fraction NAV | S16 §16.2 | YES-config. NC9 | minimum_evaluation_periods | 10 | cycles | S12 §12.5 | NO-CanonLaw. NC10 | min_trades | 20 | trade count | S12 §12.3 | NO-CanonLaw. NC11 | max_drawdown | 0.08 | fraction alloc | S31 §31.1 | YES-Guardian."],
    ["Logic", "1. Collect trade records. 2. Apply decay weighting. 3. Calculate RAR. 4. Compare thresholds. 5. Execute transition. 6. Publish RAR. 7. Signal reallocation."],
    ["Business Rules", "B1: Operators below quarantine_threshold immediately suspended. B2: New operators get NC8 allocation, cannot promote until NC9 periods elapsed. B3: Retired operators archived in KG — never deleted. B4: RAR requires min NC10 trades; insufficient data -> RAR = 0.0."],
    ["Kill Conditions", "K1: > 30% operators in QUARANTINE simultaneously -> SAFE_MODE. K2: Any operator drawdown > NC11 -> immediate QUARANTINE."],
    ["Performance Targets", "T1: RAR calculation <= 15ms per operator. T2: Full cohort (500 operators) <= 3s. T3: Lifecycle transition event published <= 5ms."],
    ["Shared Parameters", "lambda_decay | S04 | CONSUME. risk_free_rate | S04 | CONSUME. rar_scores | S12 | PUBLISH. operator_states | S12 | PUBLISH. cfu_reallocation_signal | S16 | PUBLISH."],
    ["Genesis References", "S04 (Mathematical Foundations), S08 (Execution Layer), S16 (Capital Allocation), S31 (Risk Envelope), S33 (Guardian)."]
]},
{ heading: "Code" },
{ type: "table", headers: ["Aspect", "Specification"], rows: [
    ["Language", "Python (fitness engine, lifecycle state machine, C-Space publisher)"],
    ["Key Classes", "RARCalculator: rolling RAR with exponential decay and sigmoid normalisation. LifecycleStateMachine: PROBATION->ACTIVE->PROMOTED/DEMOTED/QUARANTINED->RETIRED. FitnessPublisher: RAR to C-Space, lifecycle events to EventBus."],
    ["Data Structures", "OperatorFitnessRecord: (operator_id, generation, rar_score, state, last_evaluation, trade_count, creation_ts, lineage_hash)."],
    ["Storage", "PostgreSQL: operator_fitness_log, lifecycle_transitions. Redis: rar_cache key operator:{id}:rar TTL 60s. Knowledge Graph: retired operator archives."]
]},
{ heading: "Dashboards" },
{ type: "table", headers: ["Panel", "Chart Type", "Metrics", "Refresh", "Interactions"], rows: [
    ["Operator Fitness Heatmap", "HEATMAP", "RAR scores all active operators, colour by state. X: operator ID, Y: time, colour: RAR", "10s", "Click operator -> detail view"],
    ["Lifecycle Flow", "SANKEY", "Flow of operators between states. Width = transition count", "Hourly", "Click flow -> operator list"],
    ["RAR Distribution", "HISTOGRAM", "Distribution of current RAR scores. Threshold lines at NC4, NC5, NC7", "10s", "Click bin -> operator list"]
]},
{ heading: "Packet Map" },
{ type: "table", headers: ["Packet ID", "Component", "SBS Scope", "Upstream Deps"], rows: [
    ["GEN-SBS12-BP1-3", "RAR Calculation Engine", "CLASS:RARCalculator, TABLE:operator_fitness_log, RULE:B4, NC:NC1, NC:NC2, NC:NC3, NC:NC10, TARGET:T1", "None"],
    ["GEN-SBS12-BP2-3", "Lifecycle State Machine", "CLASS:LifecycleStateMachine, TABLE:lifecycle_transitions, RULE:B1, RULE:B2, RULE:B3, KILL:K1, KILL:K2, NC:NC4, NC:NC5, NC:NC6, NC:NC7, NC:NC8, NC:NC9, NC:NC11, TARGET:T3", "GEN-SBS12-BP1-3"],
    ["GEN-SBS12-BP3-3", "Fitness Publishing & Dashboards", "CLASS:FitnessPublisher, DS:OperatorFitnessRecord, PANEL:OperatorFitnessHeatmap, PANEL:LifecycleFlow, PANEL:RARDistribution, PARAM:rar_scores, PARAM:operator_states, PARAM:cfu_reallocation_signal, TARGET:T2", "GEN-SBS12-BP1-3, GEN-SBS12-BP2-3"]
]},
{ heading: "Changelog" },
{ type: "table", headers: ["Version", "Date", "Author", "Summary of Changes"], rows: [
    ["v2", "2026-03-10", "Claude (P21)", "Added NC9 (minimum_evaluation_periods) as Canon Law. Updated B2. Added Kill Condition K2."],
    ["v1", "2026-02-12", "Claude (P15)", "Initial SBS creation. 11 numerical constants, 3 packets."]
]}

Row Reference

SBS Header

Every SBS begins with these metadata fields. Display format: {DOC}-SBS{ID}: Name | Source | Status | Packets | v{version} | {last_modified}

Field	Required	Description
{DOC}-SBS{SectionID}	REQUIRED	SBS identifier. Regex: `^(GEN\|FAC)-SBS(\d+[A-Z]{0,3})$`. e.g. FAC-SBS29, GEN-SBS3. Collision rule: unique numeric prefix per document. P1
Section Name	REQUIRED	Human-readable section title. e.g. "Operational Framework"
Source	REQUIRED	Document and anchor link. e.g. hilbert-factory.html#s29, genesis.html#s03
Status	REQUIRED	DRAFT (not yet reviewed) / VERIFIED (passed adversarial audit) / STALE (section modified since last SBS verification). Auto-flips to STALE on source_hash mismatch.
Packets	REQUIRED	List of Build Packet IDs derived from this SBS. e.g. FAC-SBS29-BP1-13 through FAC-SBS29-BP13-13. "N/A" for Genesis SBS entries.
source_hash P6	REQUIRED	MD5 hash of the parent section text at SBS verification time. Used for automated stale detection — compared against live section content on every build cycle.
source_version P6	REQUIRED	Incrementing integer (v1, v2…) bumped on each re-verification of this SBS against updated source content.
version P11	REQUIRED	Integer starting at 1. Incremented each time the SBS content is changed and re-verified. Every version increment MUST have a corresponding entry in the Changelog.
last_modified P11	REQUIRED	ISO 8601 timestamp of the most recent verification. Example: `2026-03-15T09:22:00Z`. Updated automatically on every re-verification.
consumed_section_hashes P28	COND	Required if Shared Parameters row contains any CONSUME entries. JSON object mapping consumed section IDs to their MD5 hashes at SBS verification time. Example: `{"S04": "a3f2b8c1...", "S31": "b7c9d0e2..."}` The Integrity Monitor (P6) checks BOTH the parent section hash AND all consumed section hashes on every build cycle. If any consumed section hash has changed: SBS → STALE, all child packets → STALE, dashboard shows which consumed section changed.

Functionality Rows

Row Required Description

Purpose REQUIRED What this component does. One paragraph, no sub-bullets.

Inputs REQUIRED Data and events flowing in. Name specific sources and types.

Outputs REQUIRED What this component produces. Name specific artefacts and events with types.

Algorithms P8 COND REQUIRED for target_layer L4 (Discovery), L5 (Intelligence), or L6 (Execution). Optional for L1, L2, L3, L7. Content: mathematical formulas, pseudocode, or algorithm descriptions specific enough that two independent implementations produce equivalent outputs. Preflight rejects placeholder text ("TBD", "See code") for L4–L6.
Boundary Conditions (REQUIRED within Algorithms for L4–L6) P27: Every formula MUST specify behaviour at its mathematical boundaries:
BOUNDARY: σ < 1e-9 → value = 0.0 (undefined, not evaluated)
BOUNDARY: overflow → cap at ±1e6, emit HIROCalculationError
BOUNDARY: empty input / below minimum size → skip evaluation, return default
BOUNDARY: output range saturation → clamp to valid range
Preflight: If target_layer is L4–L6 and Algorithms row contains no BOUNDARY: entries, the SBS SHALL NOT pass verification.

Numerical Constants P9

COND

REQUIRED for L4, L5, L6. A structured table of EVERY numerical value referenced in Algorithms, Business Rules, Performance Targets, or Kill Conditions rows.

ID	Name	Value	Unit	Source	Mutable
NC1	lambda_decay	0.95	dimensionless	S04 §4.2	YES — Guardian config
NC2	max_position_pct	0.02	fraction of NAV	S31 Rule B3	NO — Canon Law

Mutable levels: NO — Canon Law (hardcoded) · YES — Guardian · YES — config. Builder Agent MUST implement mutable constants as configurable parameters. Scope key: NC:{id}.

Logic OPTIONAL Multi-step processing order. Include only if multi-step.

Business Rules REQUIRED Numbered B1, B2, B3… Hard constraints, thresholds, limits, HALT conditions. Numbering required for key-based scope references (RULE:B1).

Kill Conditions P31 COND REQUIRED for L5 (Trading Intelligence) and L6 (Execution). Optional for L1, L2, L3, L4, L7.
Numbered K1, K2, K3… Conditions that trigger HALT or SAFE_MODE.
Minimum requirements for L5–L6: at least one HALT condition (full stop), at least one SAFE_MODE condition (reduce exposure). Every Kill Condition must reference the specific threshold (from Numerical Constants) that triggers it.
Preflight: If target_layer is L5 or L6 and Kill Conditions row is missing or contains fewer than 2 entries (one HALT, one SAFE_MODE), the SBS SHALL NOT pass verification.

Guardian Protocol P32

COND

REQUIRED for L4, L5, L6. Optional for L1, L2, L3, L7.
This component's response to each Guardian command:

Command	Response	Max Latency
HALT	What this component does on HALT	≤ 100ms
SAFE_MODE	Reduced operation mode	≤ 500ms
REDUCE_EXPOSURE	How exposure is reduced	≤ 1s
EMERGENCY_FLATTEN	How positions are closed (or N/A)	≤ 2s
RESUME	How normal operation resumes	≤ 1s

Rule: The Builder Agent MUST implement a Guardian command handler responding to all commands within the specified latency. Components that ignore Guardian commands are build failures.

Performance Targets P10 COND REQUIRED for L2 (Data), L4 (Discovery), L5 (Intelligence), L6 (Execution). Optional for L1, L3, L7.
Numbered T1, T2, T3… to enable key-based scope referencing (TARGET:T1).
T1: Latency budget (ms). T2: Throughput target (ops/sec). T3: Memory ceiling.
Note: T1 latency budgets are summed across dependency chains by Gate #7 (Path Latency Check).

Shared Parameters P2 REQUIRED List all parameters this section shares with or consumes from other sections.
Format: parameter_name | owner_section | direction (PUBLISH / CONSUME)
Example: lambda_decay | S04 | CONSUME
Rule: Every parameter listed here MUST exist in the Global Parameter Registry (Settings dashboard). Preflight flags the SBS as non-compliant if a parameter is not registered.
Decomposition: each packet inherits ONLY the Shared Parameters it directly references.

Events Emitted P21

COND

REQUIRED for any section that publishes to the EventBus (check Outputs row for EventBus references). Optional for sections with no event output.
A structured list of every event this component emits.

Event ID	Trigger	Payload Fields	Schema
EVT_OPERATOR_PROMOTED	RAR exceeds promotion_threshold for sustained_periods	operator_id: str, new_state: str, rar_score: float, previous_state: str, timestamp: ISO8601	OperatorLifecycleEvent

Rules: Every event MUST have a unique Event ID system-wide. Payload fields MUST specify name and type. Consuming packets MUST reference the exact Event ID in their Inputs row. The Preflight SHALL verify that every Event ID referenced in an Input row exists as an emitted event in some SBS.
Scope key: EVT:{EventID} (PARTITION — each event assigned to exactly one packet).

Temporal Anchor P26

COND

REQUIRED for L4, L5, L6. Optional for L1, L2, L3, L7.
Must specify:

Evaluation trigger: event-driven | time-driven | hybrid
Frequency: specific interval or event name
Time basis: trading_days | calendar_days | wall_clock_seconds | tick
Timezone: UTC unless otherwise specified

Rule: All Numerical Constants with time-based units (e.g. "evaluations", "periods") MUST reference the Temporal Anchor to resolve ambiguity. The Preflight SHALL flag any NC entry with unit "evaluations" or "periods" that lacks a corresponding Temporal Anchor.

Genesis References REQUIRED Cross-references to Genesis sections and other Factory sections.

Code Rows

Row	Required	Description
Language	REQUIRED	Python, Rust, TypeScript. Justify if mixed.
Key Classes	REQUIRED	Named classes with descriptions. PascalCase. These become the actual class names in code. Used as `CLASS:` scope keys.
Data Structures	OPTIONAL	Named schemas with field lists. Include only if this section defines new schemas. Used as `DS:` scope keys.
Storage	REQUIRED	PostgreSQL table names (snake_case), Redis key patterns, Knowledge Graph entity types. Used as `TABLE:` scope keys.
Fault Tolerance P20	REQUIRED	How this component handles errors, invalid inputs, and upstream failures. Must specify: Exception hierarchy: which exceptions this component raises (must extend from `hiro.exceptions` base classes) Failure return values: what the component returns when it cannot complete its primary function — e.g. "returns RAR = 0.0 and emits FailedEvaluationEvent" NOT "returns None" Upstream failure behaviour: retry with backoff / degrade gracefully / halt Circuit breaker: whether this component implements circuit-breaking and at what threshold HIRO exception hierarchy (all components MUST use): `HIROBaseException → HIRODataError \| HIROCalculationError \| HIROIntegrationError \| HIROConfigError \| HIROCriticalError` Rules: MUST NOT use bare try/except. MUST NOT return None for error cases. MUST NOT silently swallow exceptions.
Numeric Precision P25	COND	REQUIRED for L4, L5, L6. Optional for L1, L2, L3, L7. Must specify for each calculation type: Financial values (P&L, capital, prices): `Decimal(18, 8)` Statistical values (σ, correlation, ratios): `float64` (numpy.float64) Scores and metrics (RAR, fitness): `float64` Timestamps: `int64` (nanoseconds since epoch) or ISO8601 string Counts and integers: `int64` Rule: MUST NOT use float32 for any financial or statistical calculation. Decimal types MUST be used for any value that represents money or is used in money calculations. Preflight: If target_layer is L4–L6 and this row is missing, the SBS SHALL NOT pass verification.
Configuration Provider P23	REQUIRED	How this component loads and refreshes configurable values. All components MUST use the HIRO standard configuration stack: Canon Law values — hardcoded constants (immutable) Guardian overrides — loaded from `hiro.config.guardian` (Redis-backed, real-time) Runtime config — loaded from `hiro.config.runtime` (PostgreSQL-backed, refreshed on SIGHUP) Environment vars — `HIRO_` prefixed, lowest priority, deployment-only Numerical Constants "Mutable" column maps: NO — Canon Law* → Level 1 · YES — Guardian → Level 2 · YES — config → Level 3 Rule: MUST use `hiro.config.get(key, default)` for all mutable values. Direct `os.environ`, .env files, YAML/JSON config files, and Consul/etcd are FORBIDDEN.
Verification Suite P22	REQUIRED	Testing requirements for this component. Must include: Unit test coverage: minimum percentage (default: 85% line coverage) Critical paths: specific input→output paths that MUST have dedicated tests Integration touchpoints: which upstream/downstream interfaces require integration tests (reference dependency_signatures entries) Performance validation: test confirming Performance Targets (T1, T2, T3) are met under expected load Format: `UNIT: 85% · CRITICAL: [scenarios] · INTEGRATION: [interfaces] · PERF: [load spec]` Rule: A packet with correct class names but 0% test coverage FAILS verification.

Dashboards Columns

Column	Required	Description
Panel	REQUIRED	Panel name as displayed on the dashboard. PascalCase. Used as `PANEL:` scope key.
Chart Type	REQUIRED	TABLE, GAUGE, LINE, BAR, TIMELINE, SANKEY, TREE, INDICATOR, HEATMAP, SCATTER_3D, INTERACTIVE, HISTOGRAM
Metrics	REQUIRED	What data the panel shows. Name specific fields and aggregations.
Refresh	REQUIRED	Real-time, On event, On demand, On change, Hourly, Daily, Weekly, 5s, 10s
Interactions	REQUIRED	Click and hover actions. Omit the entire Dashboards section if no UI.

Packet Map Columns

Every SBS must end with a Packet Map table listing every packet derived from this SBS. The Preflight uses this to verify completeness — every Key Class, Storage table, and Dashboard panel from the SBS must appear in exactly one Packet Map row.

Column	Required	Description
Packet ID	REQUIRED	Full packet identifier using the naming convention. e.g. FAC-SBS29-BP1-13
Component	REQUIRED	Human-readable name of what this packet builds. e.g. "PostgreSQL schema"
SBS Scope	REQUIRED	Typed key list (see Scope Format above). No free text. e.g. `CLASS:PostgreSQLManager, TABLE:backup_config, RULE:B1, NC:NC2`
Upstream Deps	REQUIRED	Packet IDs this packet depends on. "None" if no dependencies.

SBS Changelog P11

Every SBS carries a running changelog appended after the Packet Map. Each entry corresponds to one version increment. Required on every version bump — no silent increments.

Version	Date	Author	Summary of Changes
v3	2026-03-15	Claude (P21)	Updated Business Rules B2, B4 per Genesis §12 rev
v2	2026-02-28	Claude (P18)	Added Kill Condition K3, new class OperatorReaper
v1	2026-02-10	Claude (P15)	Initial SBS creation

Changelog Rules

Every version increment MUST have a changelog entry — no silent version bumps.
The Author field records which process/project created the version (e.g. "Claude (P21)" = Claude Code during Project 21).
The Summary must reference specific row IDs (B2, K3, CLASS:X) so downstream impact can be traced.
Changelog entries are append-only — historical entries MUST NOT be modified.

Build Packet — All Fields

Field Type Req Description

packet_id P1 STRING YES Unique ID. Regex: ^(GEN|FAC)-SBS(\d+[A-Z]{0,3})-BP(\d+)-(\d+)$. e.g. FAC-SBS29-BP1-13

title STRING YES What this packet builds. Must be specific to this packet.

factory_section STRING YES Parent Hilbert Factory section. e.g. §29, §37B, §E

parent_sbs_id P2 STRING YES The SBS this packet was decomposed from. Must reference a VERIFIED SBS. Regex: ^(GEN|FAC)-SBS(\d+[A-Z]{0,3})$

sbs_scope P5 STRING YES Comma-separated typed key list defining exactly what this packet owns. No free text. e.g. CLASS:EventBus, TABLE:event_log, RULE:B2, NC:NC3

step_number INT YES Build construction step (1–10).

wave_number INT YES Build wave within step. Same-wave packets build in parallel.

target_layer ENUM YES L1 Core Infrastructure, L2 Knowledge & Data, L3 AI Engineering, L4 Verification & Governance, L5 Trading Intelligence, L6 Execution, L7 Observability. Determines which SBS rows are conditionally required.

language STRING YES Python, Rust, SQL/Python, TypeScript

target_server P15 ENUM / ARRAY YES Deployment target. Valid values: H (Hetzner / Helsinki — infrastructure, CI/CD, dashboards), A2 (Singapore — primary execution), C (London — European execution).
Multi-server: use array ["A2", "C"] — each element validated independently.
Retired — do NOT use: B (Batam — decommissioned), A1 (Singapore legacy — consolidated into A2). Either value triggers CONFIG_DRIFT flag.

estimated_effort P3 INT 1–5 YES Complexity Points scale. Must be integer 1–5; values outside range rejected by Readiness Gate.
1 = Trivial (single class, <100 lines) · 2 = Simple · 3 = Moderate · 4 = Complex (4+ classes, multi-layer deps) · 5 = Critical (core infrastructure, high fan-out).
Rule: estimated_effort = 5 requires complexity_justification to be populated.

upstream_deps JSON[] YES Packet IDs that must complete before this builds. [] if none. All listed packets must have status VERIFIED before this packet can pass the Readiness Gate.

dependency_signatures P7 P37

JSON[]

YES

Interface contracts exported by each upstream dependency. Use [] if upstream_deps is empty. Auto-populated from verified build output of upstream packets. If an upstream packet has not been built and verified, its signatures are unavailable and this packet cannot pass the Readiness Gate.
Format per entry:

{
  "dep_packet_id": "GEN-SBS12-BP1-3",
  "module_namespace": "hiro.intelligence.rar_calculator",
  "verification_hash": "sha256:a3f2b8c1d4e5...",
  "verified_at": "2026-03-10T14:30:00Z",
  "exports": [{"name": "RARCalculator", "type": "class", "signature": "RARCalculator(config: HiroConfig)", "returns": "RARCalculator instance"}]
}

Schema exports (table type) P30: Add "type": "table" entries for owned tables:

{"name": "operator_fitness_log", "type": "table", "columns": [{"name": "operator_id", "type": "VARCHAR(64)", "pk": true}, {"name": "rar_score", "type": "FLOAT8"}, ...]}

Rule: Every TABLE: scope key in a packet's ownership MUST have a corresponding "type": "table" export entry after build & verification. Downstream packets use these schema exports as their contract for reading owned tables.

Write Protection P37: This field is READ-ONLY for human authors and Builder Agents.

Population Mechanism

When an upstream packet reaches status TESTED, the Verifier Agent extracts its public interface (classes, functions, table schemas) and signs the export manifest.
The signed manifest is stored as the upstream packet's canonical export.
When a downstream packet enters the build queue, the system auto-populates dependency_signatures by pulling the signed manifests of all upstream_deps.

Verification

Each signature entry carries a verification_hash computed from the upstream packet's verified artefact content. Gate #5 SHALL verify that dependency_signatures hashes match the current signed manifests of upstream packets. If any hash mismatches (upstream was rebuilt since signatures were captured), the downstream packet is blocked until signatures are refreshed.

Manual Override

Manual editing of dependency_signatures is FORBIDDEN under normal operation. Emergency override requires Guardian approval and is logged as a MANUAL_SIGNATURE_OVERRIDE event with justification.

data_flow P38

JSON[]

COND

Required if upstream_deps is non-empty OR if Outputs row references EventBus/C-Space/other consumers.
Declares every data flow INTO and OUT OF this packet.

Format per flow:

{
  "direction": "IN" | "OUT",
  "counterpart_packet": "GEN-SBS12-BP1-3" | "EXTERNAL:binance_ws",
  "data_type": "table_read" | "event_publish" | "event_subscribe" |
               "api_call" | "cache_read" | "cache_write" | "file_write",
  "resource": "operator_fitness_log" | "EVT_OPERATOR_PROMOTED" | "rar_cache",
  "estimated_volume": "~500 rows/evaluation cycle",
  "estimated_frequency": "every 5 minutes during trading hours",
  "server_path": "A2 → H" | "local" | "A2 → A2"
}

Rules:

Every table referenced in code (owned or upstream) MUST appear as a data_flow entry
Every event emitted or consumed MUST appear as a data_flow entry
Cross-server flows (different target_server values) MUST specify the server_path so bandwidth requirements can be calculated
The Preflight SHALL sum cross-server data volumes and flag any path exceeding estimated bandwidth thresholds

Example (for GEN-SBS12-BP2-3, Lifecycle State Machine):

[
  {
    "direction": "IN",
    "counterpart_packet": "GEN-SBS12-BP1-3",
    "data_type": "table_read",
    "resource": "operator_fitness_log",
    "estimated_volume": "~500 rows per evaluation",
    "estimated_frequency": "every 5 min",
    "server_path": "local"
  },
  {
    "direction": "OUT",
    "counterpart_packet": "GEN-SBS12-BP3-3",
    "data_type": "event_publish",
    "resource": "EVT_OPERATOR_PROMOTED",
    "estimated_volume": "~5-20 events per evaluation",
    "estimated_frequency": "every 5 min",
    "server_path": "local"
  },
  {
    "direction": "OUT",
    "counterpart_packet": "EXTERNAL:guardian_monitor",
    "data_type": "event_publish",
    "resource": "EVT_SAFE_MODE_TRIGGERED",
    "estimated_volume": "rare — 0-1 per day",
    "estimated_frequency": "on trigger only",
    "server_path": "A2 → H"
  }
]

Preflight Integration:

Cross-server flows are summed per server_path for capacity planning
Flows referencing non-existent resources trigger SCOPE_REFERENCE_ERROR
Flows referencing upstream tables verify ownership via sbs_scope

sbs_content P4 TEXT YES Minimal-context SBS subset (Rule 3 + Addendum). Verbatim-extracted from parent SBS. Contains only: SBS Header metadata, BROADCAST rows, PARTITION items for this packet's scope, FILTERED items relevant to this packet. No paraphrasing, no rewording.

status P36

ENUM

YES

Values: PENDING, IN_PROGRESS, BUILDING, DEPLOYED, TESTED, IMPLEMENTED, STALE, SUPERSEDED

State Machine — Valid Transitions Only:

From	To	Trigger
PENDING	IN_PROGRESS	Decomposition assigned, ready for build queue
IN_PROGRESS	BUILDING	Builder Agent has started code generation
BUILDING	DEPLOYED	Code generated, artefacts written to artefact_path
DEPLOYED	TESTED	Verifier Agent passed all checks
TESTED	IMPLEMENTED	Integration tests passed, production-ready
Any State	STALE	Parent SBS changed — auto-triggered by P6/P28
Any State	SUPERSEDED	Replaced during deduplication — P18
STALE	PENDING	SBS re-verified, packet regenerated

Forbidden Transitions (system SHALL reject):

PENDING → DEPLOYED (cannot skip build)
PENDING → TESTED (cannot skip build + deploy)
BUILDING → TESTED (cannot skip deployment)
DEPLOYED → IMPLEMENTED (cannot skip verification)
IMPLEMENTED → BUILDING (cannot go backward — regenerate as new packet)
SUPERSEDED → any forward state (superseded packets are terminal)

Enforcement: The /api/packets endpoint SHALL reject any status update that is not a valid transition. Invalid transitions return HTTP 409 with the message: "Invalid status transition: {current} → {requested}. Valid transitions from {current}: [{list}]"

source_sbs_version P11 INT YES The SBS version number this packet was generated from. If the parent SBS version is greater than this field, the packet is OUT OF DATE and auto-flips to STALE — must be regenerated.

capability_block STRING OPT HIRO Capability Block. e.g. CB-L1-006

artefact_path STRING OPT Output file path relative to project root (e.g. hiro/execution/router.py). Must be globally unique across all DRAFT and VERIFIED packets — Gate #9 enforces this.

module_namespace P24 STRING YES Python import path for this packet's exports. Derived from artefact_path by converting path separators to dots and removing the .py extension.
Example: artefact_path: hiro/intelligence/rar_calculator.py → module_namespace: hiro.intelligence.rar_calculator
The Builder Agent MUST use this namespace when importing from upstream packets. dependency_signatures entries SHALL include the module_namespace of the exporting packet.

built_at TIMESTAMP OPT When successfully built.

verified_at TIMESTAMP OPT When passed verification.

complexity_justification P19 STRING COND Required if estimated_effort = 5. Explains why this packet cannot be further decomposed and what mitigation is in place. Must be reviewed and added to the SBS changelog entry for the version in which this packet was created.

feedback_loop_exemption P34 JSON[] COND Required if this packet participates in an intentional architectural feedback loop (e.g. Execution L6 results feeding back into Discovery L4 fitness evaluation). Declares specific dependency edges exempted from Gate #8 cycle detection.
Format per entry: {"from_packet": "GEN-SBS8-BP2-4", "to_packet": "GEN-SBS12-BP1-3", "justification": "...", "approved_by": "Guardian review 2026-03-15", "break_strategy": "async|cached|phased"}
Rules: Every exemption MUST have a justification and an approved_by field. break_strategy must be async (queue/event), cached (stale data), or phased (alternating phases). Gate #8 removes exempted edges before running topological sort — if cycles remain after removal, those are genuine errors. Compliance Status shows: FEEDBACK LOOPS (EXEMPTED): N declared, all approved

Duplicate SBS Enforcement P18

Two SBS entries are "duplicates" if they share the same {DOC}-SBS{ID} identifier. The 1:1 rule mandates exactly one SBS per section.

1. Creation Block

The system SHALL prevent creation of a new SBS if one already exists for that section ID. The only permitted path is to update the existing SBS, which increments its version (P11).

2. Deduplication of Existing Duplicates

For each duplicate group:

Identify the canonical version: highest version number, most recent verification date, most complete content.
Mark all non-canonical versions as SUPERSEDED.
Re-point any packets referencing superseded SBS versions to the canonical version.
Archive superseded versions — do NOT delete. Maintain audit trail.

3. Compliance Gate

The Compliance Status score SHALL not exceed PARTIAL while any unresolved duplicates exist. Duplicates are displayed as a CRITICAL blocker. Each group requires explicit canonical selection — there is no automatic merge.

Readiness Gate — Complete Index

11 gates total. Gates #1–#6 from Hilbert Factory §5. Gates #7–#10 from audit patches P6, P10, P14, P16. Gate #11 from P36.

#	Check	Pass Condition	Source
1	Required fields populated P17	packet_id, parent_sbs_id, sbs_scope, title, factory_section, step_number, wave_number, target_layer, language, upstream_deps, sbs_content, status, source_sbs_version all non-empty and non-placeholder. source_sbs_version equals parent SBS current version.	§5 + P17
2	SBS content structural + density check P17	Contains { heading: "Functionality" } and { heading: "Code" } sections. All required rows have substantive content — not TBD, TODO, FIXME, "See code", "Pending", "WIP", or string <10 chars. Key Classes row has at least one PascalCase name. Storage row has at least one snake_case name.	§5 + P17
3	SBS is packet-specific	No other packet shares identical sbs_content (first 500 chars). See P18: duplicate SBS enforcement.	§5 + P18
4	Key Classes are named	Code table has a Key Classes row with actual class names (PascalCase, no spaces, no placeholders).	§5
5	Dependencies exist and are VERIFIED	Every packet_id in upstream_deps exists in the packet registry and has status VERIFIED. dependency_signatures populated for all listed deps.	§5 + P7
6	L4–L6 conditional rows present P8 P9	If target_layer is L4, L5, or L6: Algorithms row present and substantive; Numerical Constants table present with at least one fully-populated entry (ID, Name, Value, Unit, Source, Mutable).	P8, P9
7	Cumulative path latency ≤ ceiling P10	Sum of T1 latency budgets across full upstream dependency chain does not exceed system ceiling: market data→signal ≤100ms, signal→order ≤50ms, full tick-to-trade ≤200ms. Uses critical path (longest branch).	P10
8	No dependency cycles P14	Kahn's algorithm topological sort succeeds on global packet graph. Self-dependencies rejected immediately. Cross-SBS cycles detected. Diamond dependencies are valid.	P14
9	artefact_path globally unique P16	No two DRAFT or VERIFIED packets share the same artefact_path. Both packets in any collision are blocked. Failure display: `ARTEFACT PATH CONFLICTS: path → packet1, packet2`	P16
10	Source hash integrity P6	Current MD5 hash of parent source section equals stored source_hash in parent SBS. If mismatch: parent SBS → STALE, all child packets → STALE, build queue blocked. Lock released only after SBS re-verification.	P6
11	Status Transition Validity P36	Every packet status change MUST follow the defined state machine. The system SHALL reject invalid transitions and log the attempt. Backward transitions (except via STALE → PENDING regeneration) are forbidden.	P36

Gate #2 Conditional Density (L4–L6): If target_layer is L4, L5, or L6 — Algorithms row must be present and substantive (not placeholder); Numerical Constants table must have at least one entry; each entry must have all columns populated. Gate reports: GATE #2 FAIL: Algorithms row missing for L5 packet

Gate #7 Edge Cases: Parallel branches → use LONGEST branch (critical path). Packets without T1 → assumed 0ms, flagged as warning if L4–L6. Circular dependencies → Gate #8 detects first; cycle = undefined latency, blocked immediately.

Loading compliance data...

Loading…

Phase: Idle Current: — Next: — Status: Ready

0 / 0 sections

Mode: SBS Only Packets Only ● Full Pipeline

GENESIS FRAMEWORK Loading…

#	Section	Name	SBS ID	SBS Chars	SBS Trunc	SBS Adverse	Build Packet ID	BP Chars	BP Trunc	BP Adverse	Status	Actions
Loading…

HILBERT FACTORY Loading…

#	Section	Name	SBS ID	SBS Chars	SBS Trunc	SBS Adverse	Build Packet ID	BP Chars	BP Trunc	BP Adverse	Status	Actions
Loading…

Build Panel

No active build. Click [Create SBS], [Build SBS], or [Create Packets] on any section above to begin.

Code Factory Build Standards ▸ Conventions enforced when packets are built into code

These conventions are enforced by the Builder Agent (Code Creator) when generating production code from Build Packets. SBS authors should understand what the downstream build process expects.

NAMING	Classes: PascalCase (matches Key Classes in SBS) Functions: snake_case Tables: snake_case (matches Storage in SBS) Constants: UPPER_SNAKE_CASE Files: snake_case.py (derived from primary class name) Modules: hiro.{layer}.{component} (derived from artefact_path)
ERROR HANDLING	HIROBaseException → HIRODataError \| HIROCalculationError \| HIROIntegrationError \| HIROConfigError \| HIROCriticalError No bare try/except. No returning None for errors. No silently swallowing exceptions.
CONFIGURATION	All mutable values: hiro.config.get(key, default) Canon Law → hardcoded constants Guardian → hiro.config.guardian (Redis, real-time) Runtime → hiro.config.runtime (PostgreSQL, SIGHUP reload) No .env files, no YAML, no os.environ direct access.
NUMERIC PRECISION	Financial values: Decimal(18, 8) Statistical values: numpy.float64 Timestamps: int64 (nanoseconds) or ISO8601 string No float32 for any calculation (P25).
LOGGING	hiro.telemetry structured logger. JSON format. Fields: timestamp, level, component, message, context. Event publishing via hiro.events.EventBus with typed schemas.
TESTING	Unit test coverage: ≥85% line coverage. Every class: constructor test, happy-path, error-path, boundary conditions. Integration tests for all upstream_deps interfaces.
IMPORTS	Use module_namespace from dependency_signatures (P24). from hiro.intelligence.rar_calculator import RARCalculator No relative imports. No wildcard imports. No sys.path hacks.
GUARDIAN PROTOCOL	All L4–L6 components implement guardian_handler() responding to: HALT \| SAFE_MODE \| REDUCE_EXPOSURE \| EMERGENCY_FLATTEN \| RESUME (P32).