SpecCompiler Core Design
This document describes the software architecture and design of SpecCompiler Core.
SpecCompiler uses a layered architecture with the engine orchestrating a five-phase <Pipeline> that processes documents through registered <Handler>.
The architecture comprises 30 CSCs organized in four source layers and two model packages. For the complete decomposition with all 162 CSUs, see the Software Decomposition chapter.
SpecCompiler uses a dynamic type system where models define available types for objects, <Float>, relations, and views.
Each extension module returns one descriptor table. The host reads the declared descriptor fields.
-- Example: models/default/types/objects/hlr.lua
return {
kind = "object", -- object | float | view | relation | specification | analyze
schema = { -- SpecIR fields for this kind. schema.id is authoritative.
id = "HLR",
long_name = "High-Level Requirement",
extends = "TRACEABLE", -- attribute + hook inheritance via the extends chain
attributes = {
{ name = "status", type = "ENUM", values = { "Draft", "Review", "Approved", "Implemented" } },
},
},
hooks = { -- Optional custom behavior.
render = function(ctx) ... end,
},
}Custom behavior belongs in hooks.
The host validates each hook name against the descriptor kind. It
rejects functions on other top-level keys. A data-only type can omit
hooks. An on_<phase> function in hooks registers phase participation.
| Category | Database Table | Key Fields |
|---|---|---|
| Specifications | spec_specification_types | id, long_name, extends, is_default |
| Objects | spec_object_types | id, long_name, extends, is_default (HLR, FD, CSC, CSU, VC, etc.) |
| Floats | spec_float_types | id, long_name, counter_group, needs_external_render |
| Relations | spec_relation_types | id, source_type_ref, target_type_ref, link_selector |
| Views | spec_view_types | id, inline_prefix, aliases |
Each hook accepts one frozen context table. The polymorphic subject field contains the hook input.
The capability field identifies
the hook. The hook name selects one of two context tiers:
| Hook(s) | Tier / context | Returns |
|---|---|---|
| render, render_block, render_link, message | render context with Pandoc and output-format fields | Pandoc AST / string |
| dataset | data context with
subject.params |
{ source / data / links } dataset |
| build_block | data context with
subject.params |
pandoc.Block |
| transform | data context with
subject.raw_content and subject.float |
resolved-AST string |
| resolve | data context with target text and source identifier | { target, ambiguous } |
| prepare_task, handle_result | data context with task or result fields | task table / DB write |
A render hook receives the render core and its subject. A data hook
receives data, spec_id, log, and its subject. The host checks
required context fields. It prevents assignment to top-level context
fields. Each hook must return its documented type.
contract.registry) loads default then each overlay model
(later-wins-by-id), scanning models/{model}/types/{category}/.
kind, schema.id, each hook valid for the kind,
no behaviour on top-level keys) and emits the type row into the
corresponding SpecIR table.
(kind, id) -> hook map that every
consumer reads via get_hook /
get_hook_inherited (which walks
the extends chain). An on_<phase> hook in hooks is synthesized into pipeline:register_handler.
host:finalize() propagates
inherited attributes, creates the analyze-query SQL views, and asserts
required hooks (e.g. a TABLE_VIEW subtype must resolve a build_block).
The Specification <Intermediate Representation> (SpecIR) is implemented as a <SQLite Database> schema composed from:
src/db/schema/types.lua
src/db/schema/content.lua
src/db/schema/build.lua
src/db/schema/search.lua
src/db/schema/init.lua (combines all
schema modules, initializes EAV pivot views)
The schema has four domains:
| Domain | Tables |
|---|---|
| Type system | spec_specification_types,
spec_object_types, spec_float_types,
spec_relation_types, spec_view_types,
datatype_definitions, spec_attribute_types,
enum_values |
| Content | specifications,
spec_objects, spec_floats,
spec_relations, spec_views,
spec_attribute_values |
| Build cache | build_graph,
output_cache |
| Search (FTS5) | fts_objects,
fts_attributes, fts_floats |
SpecIR is a ReqIF inspired relational metamodel that lowers textual specifications into a typed intermediate representation against which structural validity is evaluated.
Where Pandoc provides the syntactic bridge from Markdown to a structured AST, SpecIR provides the semantic layer by separating: a type layer (Γ), which defines what may exist and a content layer, which records what does exist.
Validation reduces to relational set operations: constraints are expressed as queries over finite sets of entities and relations, and violations emerge as counterexamples (e.g., anti-joins between expected and actual structures).
Allocation: Realized by Core Runtime (Core Runtime) through Build Engine (Build Engine) and Pipeline Orchestrator (Pipeline Orchestrator), with handlers registered via Pipeline Handlers (Pipeline Handlers). Phase-specific handlers are organized in Analyze Handlers (Analyze Handlers), Initialize Handlers (Initialize Handlers), and Transform Handlers (Transform Handlers), with shared utilities in Shared Pipeline Utilities (Shared Pipeline Utilities).
The <Pipeline> execution orchestration function manages the five-phase document processing lifecycle from initial Pandoc hook entry through final output generation. It encompasses <Handler> registration, dependency-based execution ordering, context propagation, and phase abort logic.
Entry Point: The Pandoc filter (Build Engine) hooks into the Pandoc Meta callback, extracts project metadata via Validation Policy, and invokes the build engine. The engine creates the database, initializes the data manager, loads the model via Type Loader, processes document files (with <Build Cache> checks), and delegates to the pipeline orchestrator.
Handler Registration: During model loading, Type Loader registers each
handler with the Pipeline Orchestrator Pipeline Orchestrator, which enforces the
registration contract by validating that every handler declares both a
name and a [dic:prerequisites](#) field before
accepting registration. The orchestrator rejects duplicate handler names
— attempting to register a handler whose name already exists raises an
immediate error. Accepted handlers are stored in a lookup table keyed by
name for O(1) retrieval during phase execution. Each handler implements
phase hooks using the naming convention on_{phase} (e.g., on_initialize, on_analyze, on_transform, on_verify, on_emit). All hooks receive the full
contexts array: on_{phase}(data, contexts, diagnostics).
<Topological Sort>: Before
executing each phase, the Pipeline Orchestrator Pipeline Orchestrator applies Kahn’s
algorithm to produce a deterministic handler execution order. Only
handlers that implement an on_{phase} hook for the current phase
participate in the sort; handlers without a relevant hook are skipped
entirely. The algorithm begins by building a dependency graph restricted
to participants and initializing an in-degree count for each node. Nodes
with zero in-degree — handlers whose prerequisites are already satisfied
— seed a processing queue. At each step the algorithm dequeues the first
node, appends it to the sorted output, and decrements the in-degree of
all its dependents; any dependent whose in-degree reaches zero is
enqueued. Alphabetical tie-breaking is applied at every dequeue step so
that handlers at the same dependency depth are always emitted in the
same order, guaranteeing deterministic output across runs. After the
queue is exhausted, if the sorted list length is less than the
participant count a dependency cycle exists and is reported as an
error.
For example, if INITIALIZE has three handlers —
specifications(no prerequisites),spec_objects(prerequisite:specifications), andspec_floats(prerequisite:specifications) — the sort produces[specifications, spec_floats, spec_objects], withspec_floatsandspec_objectsordered alphabetically since both depend only onspecifications.
Phase Execution: The pipeline executes five phases in order:
All phases use the same dispatch model: for each handler in sorted
order, the Pipeline Orchestrator Pipeline Orchestrator calls the handler’s
on_{phase}(data, contexts, diagnostics)
hook once with the full set of contexts. Handlers are responsible for
iterating over contexts internally. Each handler invocation is bracketed
by uv.hrtime() calls at nanosecond
precision to record its duration, and the orchestrator also records the
aggregate duration of each phase, providing two-level performance
visibility (handler-level and phase-level).
Phase Abort: After ANALYZE, the Pipeline Orchestrator Pipeline Orchestrator inspects the diagnostics collector for any error-level entries. If errors exist, the pipeline aborts before EMIT — only output generation is skipped, since TRANSFORM has already completed. This design allows analyze queries to validate transform results before committing to output.
Context Propagation: Each document file produces a context containing the parsed AST, file path, specification ID, and walker state. Contexts are passed through all phases, accumulating state. The diagnostics collector aggregates errors and warnings across all handlers and contexts.
Component Interaction
The pipeline is realized through the core runtime and four handler packages that correspond to pipeline phases.
CSC Core Runtime (Core
Runtime) provides the entry point and orchestration layer. CSU Pandoc Filter Entry
Point (Pandoc Filter Entry Point) hooks into the Pandoc callback to
launch the build. CSU
Configuration Parser (Configuration Parser) reads project.yaml and resolves model, output,
and logging settings. CSU Data
Loader (Data Loader) loads external data files referenced by
specifications. CSU Build
Engine (Build Engine) coordinates the full build lifecycle —
creating the database, loading the model, processing document files with
cache checks, and delegating to CSU Pipeline Orchestrator (Pipeline
Orchestrator) for phase execution. The orchestrator drives topological
sort, handler dispatch, timing, and abort logic across all five
phases.
CSC Pipeline Handlers
(Pipeline Handlers) registers cross-cutting handlers. CSU Include Expansion Filter (Include
Expansion Filter) resolves include
directives during INITIALIZE, expanding referenced files into the
document AST before entity parsing begins.
CSC Initialize Handlers (Initialize Handlers) parses the Pandoc AST into SpecIR entities. CSU Specification Parser (Specification Parser) extracts document-level metadata, CSU Object Parser (Object Parser) identifies typed content blocks, CSU Attribute Parser (Attribute Parser) extracts key-value attributes from object paragraphs, CSU Float Parser (Float Parser) detects embedded figures, tables, and listings, CSU Relation Parser (Relation Parser) captures cross-reference links, and CSU View Parser (View Parser) identifies view directives.
CSC Analyze Handlers (Analyze Handlers) resolves cross-references and infers types. CSU Relation Resolver (Relation Resolver) matches link targets to spec objects using selector-based resolution. CSU Relation Type Inferrer (Relation Type Inferrer) assigns relation type_refs based on source and target object types. CSU Attribute Caster (Attribute Caster) validates and casts attribute values against their declared datatypes.
CSC Shared Pipeline Utilities (Shared Pipeline Utilities) provides reusable base modules consumed by handlers across phases. CSU Spec Object Base (Spec Object Base) and CSU Specification Base (Specification Base) provide shared parsing logic for objects and specifications. CSU Float Base (Float Base) provides float detection and extraction. CSU Attribute Paragraph Utilities (Attribute Paragraph Utilities) parses attribute blocks from definition-list paragraphs. CSU Include Handler (Include Handler) and CSU Include Utilities (Include Utilities) manage file inclusion and path resolution. CSU Render Utilities (Render Utilities) and CSU Math Render Utilities (Math Render Utilities) provide AST-to-output conversion helpers. CSU View Utilities (View Utilities) supports view parsing and rendering. CSU Source Position Compatibility (Source Position Compatibility) normalizes Pandoc source position data across API versions.
Pipeline handler registration shall reject handlers that do not
provide a non-empty name
field.
Pipeline handler registration shall reject handlers that do not
provide a prerequisites array.
Pipeline handler registration shall reject duplicate handler names within the same pipeline instance.
Pipeline execution shall propagate the base context fields (validation, build_dir, log, output_format, template, reference_doc, docx, project_root, outputs, html5, bibliography, csl) to handlers.
Pipeline execution shall attach doc and spec_id for each processed document
context passed to handlers.
Pipeline execution shall create a fallback project context when the
document list is empty, with doc=nil and a derived spec_id.
Given registered <Handler>s, CSU Pipeline Orchestrator shall execute phases in fixed order: <INITIALIZE Phase> → <RESOLVE Phase> → <TRANSFORM Phase> → <ANALYZE Phase> → <EMIT Phase>.
Given the <Handler> set for a <Phase>, CSU Pipeline Orchestrator
shall invoke only those declaring an on_{phase} hook for that phase.
When diagnostics:has_errors()
returns true after <ANALYZE Phase>, CSU Pipeline Orchestrator shall not
execute <EMIT
Phase> phase handlers.
Given a <Phase> name and the <Handler>
registry, CSU Pipeline
Orchestrator shall build the <Topological Sort> dependency graph
from only those handlers declaring an on_{phase} hook, producing an ordered
execution list.
When multiple <Handler>s have no dependency
ordering between them, CSU
Pipeline Orchestrator shall sort them alphabetically by name, producing deterministic
output.
When a cyclic <Prerequisites> graph is detected, CSU Pipeline Orchestrator shall report an error listing the remaining unordered handler names.
CSU Build Engine shall
complete all <TRANSFORM Phase> phase handlers
before checking has_errors() for
abort, ensuring transforms are applied before validation results are
inspected.
When aborting execution before <EMIT Phase>, CSU Build Engine shall log the error count via CSU Logger.
Given a document context array, CSU Pipeline Orchestrator shall pass the
full array to each <Handler>’s on_{phase} hook in a single call.
CSU Pipeline
Orchestrator shall invoke phase hooks with signature on_{phase}(data, contexts, diagnostics)
where data is a CSU Data Manager instance, contexts is the array, and diagnostics is a CSU Diagnostics Collector instance.
Given a Pandoc Header at level 1 in the <Abstract Syntax Tree>, CSU Specification Parser
shall parse the optional TYPE:
prefix and @<Project
Identifier> suffix and insert one <Specification> record into the specifications table with identifier derived from filename, type_ref validated against the <Type
Registry>, and header_ast
storing the serialized <Abstract Syntax Tree>.
Given a Pandoc Header at level 2–6, CSU Object Parser shall insert one <Spec
Object> record with type resolved via explicit TYPE: prefix → <Type Alias>
lookup → default fallback.
Given Pandoc BlockQuote lines matching > key: value, CSU Attribute Parser shall insert <Attribute>
records in spec_attribute_values
linked to the enclosing <Spec Object> via owner_object_id.
Given a Pandoc CodeBlock with syntax:label class, CSU Float Parser shall insert one <Spec Float>
record with type_ref resolved from
<Type
Alias>, label, and raw_content.
Given a Pandoc Link with (@) or
(#) target, CSU Relation Parser shall insert one <Spec
Relation> record with target_text and <Relation
Selector> preserved for downstream resolution.
For any <Intermediate Representation> record,
CSU Object Parser and CSU Hash Utilities shall
compute identifier as SHA1 hash of
source context and assign file_seq
preserving document order.
Given .include CodeBlock paths,
CSU Include Expansion
Filter shall resolve each path relative to the including file’s
directory.
When recursive include traversal detects a cycle, CSU Include Expansion Filter shall raise an error with the include chain path before performing any expansion.
After expanding included content, CSU Include Expansion Filter shall inject
data-source-file and data-pos attributes into expanded blocks
for diagnostic tracing.
Given a non-<Composite Object Type> <Spec
Object> without explicit @<Project
Identifier>, the pid_generator shall produce a <Project
Identifier> using pid_prefix
+ pid_format from the <Type>
definition (e.g., HLR-%03d → HLR-001).
Given a <Composite Object Type> <Spec
Object> without explicit @<Project Identifier>, the
pid_generator shall produce a hierarchical <Project Identifier> qualified by the
<Specification> PID (e.g., SRS-sec1.2.3).
Given a <Spec
Object> with explicit @<Project
Identifier> annotation, the pid_generator shall preserve the PID
unchanged.
After generating a <Project Identifier>, the pid_generator shall check for collisions across all <Specification>s, raising an error if a duplicate is found.
Given an unresolved <Spec Relation> and the <Type
Registry>, CSU
Relation Type Inferrer shall filter candidate relation types by <Relation
Selector>, source_attribute, source type_ref, and target type_ref constraints.
When a candidate relation type has a NULL constraint, CSU Relation Type Inferrer shall treat it as a wildcard matching any value, adding 0 to the <Specificity Scoring> score.
When multiple candidates achieve equal highest <Specificity Scoring>, CSU Relation Type Inferrer shall mark the <Spec Relation> as ambiguous.
When resolving target candidates, CSU Resolution Queries shall prefer targets in the same <Specification> over cross-specification targets.
Selected SQLite as the persistence engine for the Specification Intermediate Representation.
SQLite provides:
Selected Entity-Attribute-Value storage for dynamic object and float attributes.
The EAV model enables runtime schema extension through model definitions:
Selected a five-phase sequential pipeline (INITIALIZE, RESOLVE, TRANSFORM, ANALYZE, EMIT) for document processing.
Five phases separate concerns and enable verification before output:
Selected Kahn’s algorithm with declarative prerequisite arrays for handler execution ordering within each pipeline phase.
Declarative prerequisites with topological sort enable:
prerequisites = {"handler_a", "handler_b"}
rather than manual sequence numbers
The host loads model descriptors from the filesystem. It registers schema data, behavior hooks, phase hooks, and analyze queries.
Model order: The engine loads default before the selected model. It loads
manifest dependencies before the model that requires them. A descriptor
with the same kind and identifier replaces the earlier descriptor.
Model paths: The host searches $SPECCOMPILER_HOME/models/{model} first.
It then searches {cwd}/models/{model}. A missing selected
or required model stops the build.
Type discovery: The host scans five directories
under models/{model}/types/.
| Category | Directory | Descriptor kind |
Database table |
|---|---|---|---|
| Specifications | specifications/ |
specification |
spec_specification_types |
| Objects | objects/ |
object |
spec_object_types |
| Floats | floats/ |
float |
spec_float_types |
| Relations | relations/ |
relation |
spec_relation_types |
| Views | views/ |
view |
spec_view_types |
The host loads Lua files in sorted order. A type can use one file or
a directory with init.lua. The
declared kind must match the directory category.
Descriptor contract: Each module returns { kind, schema, hooks }. The hooks field is optional. The host requires
a known kind and a non-empty schema.id. It rejects invalid hooks and
functions outside hooks.
return {
kind = "object",
schema = {
id = "HLR",
extends = "TRACEABLE",
attributes = {
{ name = "status", type = "ENUM",
values = { "Draft", "Approved" } },
},
},
hooks = {
render = function(ctx)
return ctx.subject.element
end,
},
}Registration: The host writes schema data to the
applicable SpecIR table. It registers declared attributes and records
the extends relationship. It
indexes each behavior hook by kind, identifier, and hook name.
Hook inheritance: get_hook_inherited searches the descriptor
and then its ancestors. This lookup applies to all descriptor kinds that
support extends.
Phase hooks: An on_<phase> hook creates a pipeline
handler named <lowercase schema.id>_handler. The
schema.phase_prerequisites field
defines its ordering constraints. Phase hooks do not enter the
behavior-hook index.
Analyze queries: The host scans models/{model}/analyze_queries/. Each
descriptor uses kind = "analyze".
Repeated policy keys use later-model precedence. A descriptor with disabled = true removes the policy
key.
Finalization: After model loading, the host
propagates inherited attributes. It creates analyze-query SQL views and
checks required hooks. A TABLE_VIEW subtype without build_block stops the build.
The host shall scan the five known type-category directories in deterministic order.
The host shall index each valid behavior hook by kind, schema.id, and hook name.
The standard object renderer shall render attributes listed in schema.attr_order first. It shall append
other attributes in alphabetical order.
The host shall stop model loading when a descriptor has no non-empty
schema.id. It shall apply category
defaults to valid schemas and register enum values.
Model resolution shall check SPECCOMPILER_HOME/models/{model} before
{cwd}/models/{model}.
Model loading shall stop when neither model path contains the selected or required model.
Chart data loading shall use the inherited dataset hook for the requested view.
Fixture modules outside the host index can use the loose-module
loader.
For a Sankey series, chart injection shall copy returned data and links to the first series. It shall
remove the conflicting dataset.
Chart injection shall preserve the chart configuration when no view is specified or the view returns an unsupported shape.
The host shall register descriptor on_<phase> hooks with the
pipeline.
The host shall register view descriptors from models/{model}/types/views/.
The host shall return direct hooks from its index and inherited hooks
from the extends chain. An absent
hook shall return nil.
SpecCompiler shall use Lua descriptor modules for model types.
extends field supports
attribute and hook inheritance. Ordered model loading supports
replacement without changes to the default model.
Allocation: Realized by Database Persistence (Database Persistence) through Data Manager (Data Manager) and Build Cache (Build Cache). The database schema is defined in DB Schema (DB Schema), queries in DB Queries (DB Queries), and materialized views in DB Views (DB Views).
The <Intermediate Representation> persistence function manages the <SQLite Database> database that stores all parsed specification content and provides cache coherency for incremental builds. It encompasses schema management, the <EAV Model> storage model, build caching, and output caching.
SQLite Persistence: The data manager (Data Manager) wraps all
database operations, providing a query API over the SpecIR schema. The
database file is created in the project’s output directory and persists
across builds. Schema creation is executed inside DataManager.new(), establishing all content
and type tables.
SpecIR Schema: The content schema (Output Cache) defines the core entity tables:
specifications — Document-level
containers with header AST and metadata
spec_objects — Typed content blocks
with AST, file position, and specification scope
spec_floats — Embedded figures,
listings, tables with render state
spec_views — Materialized data views
(TOC, LOF, traceability matrices)
spec_relations — Links between
objects with type inference results
spec_attribute_values — EAV-model
attribute storage for object and float properties
The type schema (Analyze Query Definitions) defines the metamodel tables that describe valid types, attribute definitions, and datatype constraints.
EAV Attribute Model: Attributes are stored as
individual rows in spec_attribute_values rather than as
columns, enabling dynamic schema extension through model definitions.
Each attribute row references its parent entity (object or float),
attribute definition, and stores the value as text with type casting at
query time.
<Build
Cache>: The build cache (Build Cache) records, per document, the full
file set the last successful build read — the root document itself plus
every included file — as nodes of the build_graph table, each with the SHA1 it
had at build time (the root is its own node). Before parsing, the Build
Engine (Build Engine)
hashes the root and the build cache walks the recorded nodes, hashing
include files via the Hash Utilities (Hash Utilities). The document is dirty —
reparsed from source — when any node’s current hash differs, a node file
is missing (hash returns nil, forcing the parse to fail fast with a
clear include-not-found error), or no root node is recorded (first
build, or the previous build failed before the deferred cache update).
Unchanged documents skip parsing entirely and reuse their cached SpecIR
state.
<Output Cache>: The output cache stores, per generated output file, the SHA1 of the exact serialized document that was fed to Pandoc — assembled from the database, views rendered, and the format filter applied. Before invoking Pandoc, the emitter serializes the assembled document, hashes it, and skips the invocation when the stored hash matches and no file dependency (bibliography, LaTeX class archive, reference.docx for DOCX) is newer than the output. Because the hash covers the render input itself rather than a model of its dependencies, any change that affects the rendered document — including cross-document view data such as traceability matrices, and template filter changes — invalidates the cache by construction.
Component Interaction
The storage subsystem is realized through four packages that separate runtime operations from static definitions.
CSC Database Persistence
(Database Persistence) provides the runtime database layer. CSU Database Handler
(Database Handler) wraps raw SQLite operations and connection management
with DELETE journal mode for single-file reliability. CSU Data Manager (Data Manager) builds on the
handler to provide the high-level query API used by all pipeline phases
— inserting spec entities during INITIALIZE, updating references during
RESOLVE, and reading assembled content during EMIT. CSU Build Cache (Build Cache) queries build_graph to detect changed documents
via SHA1 comparison of every recorded node (root and includes). CSU Output Cache (Output
Cache) tracks generated output files and the hash of their serialized
render input to skip redundant generation. CSU Analyze Query Loader (Analyze Query
Loader) materializes SQL analyze query views at build time for the
ANALYZE phase.
CSC DB Schema (DB Schema) defines the database structure through composable modules. CSU Schema Aggregator (Schema Aggregator) is the entry point, composing: CSU Content Schema (Content Schema) for the core SpecIR tables, CSU Type System Schema (Type System Schema) for attribute and datatype definitions, CSU Build Schema (Build Schema) for source file and dependency tracking, and CSU Search Schema (Search Schema) for FTS5 virtual tables.
CSC DB Queries (DB Queries) mirrors the schema structure with composable query modules. CSU Query Aggregator (Query Aggregator) combines: CSU Content Queries (Content Queries) for spec entity CRUD, CSU Resolution Queries (Resolution Queries) for cross-reference and relation resolution, CSU Build Queries (Build Queries) for cache and dependency lookups, CSU Type Queries (Type Queries) for type definitions and attribute constraints, and CSU Search Queries (Search Queries) for FTS5 population and search.
CSC DB Views (DB Views) provides materialized SQL views over the SpecIR data. CSU Views Aggregator (Views Aggregator) composes: CSU EAV Pivot Views (EAV Pivot Views) for pivoting attribute values into typed columns, CSU Resolution Views (Resolution Views) for joining relations with resolved targets, and CSU Public API Views (Public API Views) for stable query interfaces used by pipeline handlers and external tools.
DataManager.begin_transaction()
followed by facade insert calls and DataManager.rollback() shall leave no
persisted staged rows.
DataManager facade methods (insert_specification, insert_object, insert_float, insert_relation, insert_view, insert_attribute_value, query_all, query_one, execute) shall persist and retrieve
canonical IR rows in content tables.
Attribute casting shall map raw attribute values to the correct typed
columns (string_value, int_value, real_value, bool_value, date_value, enum_ref) and skip updates for invalid
casts.
Given a document path and its current SHA1 hash, CSU Build Cache is_document_dirty() shall walk the
document’s <Build Graph> nodes and return false when the root node is recorded and
every node’s stored node_sha1
matches its current file hash.
Given a document path with no root node recorded in the <Build
Graph> (first build, or a previous build that failed before the
deferred cache update), CSU
Build Cache is_document_dirty() shall return true.
Given a spec_id, output_path, and the SHA1 of the serialized document
to be rendered (the exact Pandoc input, after assembly, view rendering,
and format filtering), CSU
Output Cache is_output_current() shall return false when the stored hash in the <Output
Cache> differs.
When the output file does not exist on disk, CSU Output Cache is_output_current() shall return false regardless of hash match.
Given a root document path, CSU Build Cache is_document_dirty() shall compare every
<Build
Graph> node — the root itself and all includes — against current
file hashes, returning true if any
differs or a node file is missing.
After a successful build, CSU Build Cache and CSU Build Queries update_build_graph() shall delete old <Build
Graph> rows for root_path
and insert the current file set: the root document as its own node plus
the include tree.
Given <Type
Registry> spec_object_types
entries, CSU EAV Pivot
Views shall generate <EAV Model> pivot views named view_{type_lower}_objects with one
column per registered attribute.
Given a <Composite Object Type> spec_object_types entry, CSU EAV Pivot Views shall
not generate a pivot view.
Selected SHA1 content hashing for incremental build detection.
Content-addressed hashing provides deterministic cache invalidation:
build_graph table records the
whole file set of a build (root as its own node plus includes), so a
single node walk answers the dirty check
pandoc.sha1() when available, falling
back to vendor/sha2.lua in
standalone mode
Selected runtime-generated CREATE VIEW statements per object type to pivot EAV attributes into typed columns.
Dynamic view generation bridges EAV flexibility with query usability:
Allocation: Realized by Transform Handlers (Transform Handlers) and Emit Handlers (Emit Handlers) through External Render Handler (External Render Handler) and Emitter Orchestrator (Emitter Orchestrator). Output infrastructure is provided by Infrastructure (Infrastructure), with format-specific utilities in Format Utilities (Format Utilities), DOCX generation in DOCX Generation (DOCX Generation), I/O operations in I/O Utilities (I/O Utilities), and external process management in Process Management (Process Management).
The multi-format publication function encompasses the TRANSFORM and EMIT pipeline phases, covering content rendering, external subprocess rendering, document assembly from the <Intermediate Representation> database, <Float> numbering and resolution, and parallel output generation via Pandoc. Views (table of contents, list of figures/tables, abbreviation lists, matrices) are rendered live at EMIT time by their view-type render hooks querying the database, so their content always reflects current database state — a requirement of the output cache, which keys on the serialized render input.
TRANSFORM Phase: Prepares content for output through the handler stages:
Float Transformer:
Resolves float content that does not require external rendering (e.g.,
CSV parsing, text processing) and updates spec_floats.resolved_ast.
External Render Handler:
Coordinates parallel subprocess rendering for float types requiring
external tools (PlantUML, ECharts, Math). Prepares tasks via renderer
callbacks, checks output cache for hits, and spawns remaining tasks in
parallel via luv spawn_batch().
Results update resolved_ast with
output paths.
Object Render Handler:
Invokes type-specific handlers for each spec_object (ordered by
file_seq). Type handlers provide header() and body() functions dispatched through the
base handler wrapper. Rendered AST is merged back to spec_objects.ast.
Specification Render
Handler: Renders document title headers via specification type
handlers, storing result in specifications.header_ast.
EMIT Phase: Assembles and generates output documents in multiple formats, fulfilling multi-format output requirements:
Float Numbering: Assigns sequential numbers to floats by counter_group (e.g., FIGURE, TABLE, LISTING, EQUATION) across all documents. Shared counter groups enable natural numbering where related visual content types form a single sequence.
Document Assembler:
Reconstructs a complete Pandoc AST from the SpecIR database Queries
spec_objects ordered by file_seq,
decodes JSON AST fragments, normalizes header levels, and assembles
floats and views into the document structure. Metadata is built from
specification attributes and the assembler returns a complete pandoc.Pandoc document.
Float Resolver: Builds a
lookup map of rendered float results (ast, number, caption, type_ref)
from spec_floats with resolved_ast. The resolver queries the
database for all floats belonging to the current specification and
indexes them for efficient lookup during document traversal.
Float Emitter: Walks assembled document blocks and replaces float placeholder CodeBlocks with rendered Div elements containing captions and semantic CSS classes for format-specific styling.
FTS Indexer: Replaces
view placeholder blocks with materialized content from the TRANSFORM
phase. Views are expanded inline as formatted tables, lists, or custom
structures depending on view type. Additionally, populates FTS5 virtual
tables (fts_objects, fts_attributes, fts_floats) for <Full-Text
Search> in the web application, converting AST to plain text and
indexing searchable fields with Porter stemming.
Inline Handler
Dispatcher: Processes inline elements during emit - resolves (@) links to #anchor references, processes citations,
and renders inline math expressions.
Emitter Orchestrator:
Format-agnostic orchestration for batch mode execution: (1) assigns
float numbers globally, (2) assembles documents per specification, (3)
resolves and transforms floats, (4) applies format-specific filters
(docx, html), (5) serializes assembled documents to intermediate JSON
via pandoc.write(doc, "json") to
temporary files, (6) checks output_cache for staleness and skips
generation when outputs are current, (7) spawns parallel Pandoc
processes via luv for concurrent format conversion (docx, html5), and
(8) cleans up intermediate JSON files after generation completes.
Format-specific postprocessors run after Pandoc generation: DOCX
postprocessing applies style fixups via OOXML manipulation, and HTML5
postprocessing bundles assets for web application deployment.
Infrastructure Support: The Pandoc CLI wrapper (Pandoc CLI Builder) builds
command arguments for multiple output formats (docx, html5, markdown,
json) with reference document, bibliography, and filter support. The
reference generator (Reference
Generator) creates reference.docx from style presets for DOCX
output styling.
Component Interaction
The output subsystem spans the TRANSFORM and EMIT pipeline phases, realized through handler packages and infrastructure components.
CSC Transform Handlers
(Transform Handlers) prepares content for output. CSU Float Transformer (Float Transformer)
resolves float content not requiring external tools. CSU External Render Handler (External Render
Handler) coordinates parallel subprocess rendering via luv. CSU Object Render Handler
(Object Render Handler) invokes type-specific header/body renderers. CSU Specification Render
Handler (Specification Render Handler) renders document title
headers. CSU Relation Link
Rewriter (Relation Link Rewriter) rewrites (@) link targets to resolved anchors in
the final AST.
CSC Emit Handlers (Emit Handlers) assembles and generates output documents. CSU FTS Indexer (FTS Indexer) populates full-text search tables. CSU Float Numbering (Float Numbering) assigns sequential numbers by counter group. CSU Document Assembler (Document Assembler) reconstructs complete Pandoc AST from SpecIR. CSU Float Resolver (Float Resolver) builds the rendered float lookup map. CSU Float Emitter (Float Emitter) replaces float placeholders with rendered Divs. CSU View Emitter (View Emitter) expands view placeholders with materialized content. CSU Inline Handler Dispatcher (Inline Handler Dispatcher) processes inline elements — links, citations, math. CSU Float Handler Dispatcher (Float Handler Dispatcher) routes float rendering to type-specific handlers. CSU View Handler Dispatcher (View Handler Dispatcher) routes view expansion to type-specific materializers. CSU Emitter Orchestrator (Emitter Orchestrator) coordinates the full emit sequence: numbering, assembly, resolution, filtering, and parallel Pandoc output.
CSC Infrastructure (Infrastructure) provides cross-cutting utilities. CSU Hash Utilities (Hash Utilities) computes SHA1 hashes for cache coherency. CSU Logger (Logger) implements NDJSON structured logging. CSU JSON Utilities (JSON Utilities) handles JSON serialization for AST interchange. CSU Reference Cache (Reference Cache) caches resolved cross-references for O(1) lookup during emit. CSU MathML to OMML Converter (MathML to OMML Converter) translates MathML equations to Office Math Markup for DOCX output.
CSC Format Utilities (Format Utilities) provides format-specific helpers. CSU Format Writer (Format Writer) serializes AST to intermediate JSON for Pandoc consumption. CSU XML Utilities (XML Utilities) generates and manipulates XML for OOXML postprocessing. CSU ZIP Utilities (ZIP Utilities) handles DOCX archive creation and modification.
CSC DOCX Generation
(DOCX Generation) produces Word documents. CSU Preset Loader (Preset Loader) reads
style preset definitions from Lua files. CSU Style Builder (Style Builder) generates
OOXML style elements from preset values. CSU OOXML Builder (OOXML Builder) assembles
the final DOCX package with styles, numbering, and content parts. CSU Reference Generator
(Reference Generator) creates reference.docx for Pandoc’s --reference-doc option.
CSC I/O Utilities (I/O Utilities) provides file-system operations. CSU Document Walker (Document Walker) traverses specification documents and their includes to build processing contexts. CSU File Walker (File Walker) scans directories for files matching glob patterns during model discovery.
CSC Process Management (Process Management) manages external subprocesses. CSU Pandoc CLI Builder (Pandoc CLI Builder) constructs Pandoc command-line arguments for each output format. CSU Task Runner (Task Runner) provides the luv-based parallel task executor used by both external float rendering and batch Pandoc output generation.
DOCX preset loading shall resolve preset paths, merge extends chains deterministically, and reject malformed or cyclic preset definitions.
Given a <Specification> identifier, CSU Document Assembler
shall query spec_objects ordered
by file_seq, producing a Pandoc
Block list in document order.
Given an included file under an active heading, CSU Include Handler shall shift all Pandoc
Header levels by the same amount. The shallowest included heading shall
be one level below the active heading. The handler shall preserve
relative depths and combine shifts across nested includes. A ---- section close shall reduce the
active level by one. Without an active heading, the handler shall
preserve source levels. The source file can start at any heading level.
The handler shall preserve computed levels greater than 6.
Given <Spec
Float> and <Spec View> positions, CSU Document Assembler
shall insert <Placeholder Block>s at correct
file_seq positions for
downstream resolution.
Given a <Placeholder Block> in the assembled
document, CSU Float
Emitter shall match its label against spec_floats records to retrieve the
resolved_ast.
Given a resolved <Spec Float>, CSU Float Emitter shall wrap it in a Pandoc
Div with semantic classes (speccompiler-float, <Counter
Group>-specific class) and a bookmark anchor identifier.
Given a <Spec
Float> with NULL resolved_ast (failed <External
Renderer>), CSU
Float Emitter shall preserve an error placeholder block with <Diagnostic Record> message.
Given all <Spec Float>s across all <Specification>s ordered by file_seq, CSU Float Numbering shall assign
monotonically increasing number
within each <Counter Group>, starting at 1.
When float types share a <Counter Group> (e.g., FIGURE, CHART, PLANTUML share “FIGURE”), CSU Float Numbering shall use a single numbering sequence.
Given an assembled Pandoc document and output config, CSU Emitter Orchestrator
shall call CSU Output
Cache is_output_current()
and skip format generation when it returns true.
After Pandoc format conversion completes, CSU Emitter Orchestrator shall remove the intermediate JSON file from the build directory.
When embed_resources: true is
set in project.yaml html5: config,
CSU Pandoc CLI Builder
shall add --embed-resources to
Pandoc CLI args, producing single-file HTML5 output.
When <Full-Text Search> tables are populated, CSU HTML5 Postprocessor HTML5 postprocessor shall bundle the search index JSON into the output.
During <EMIT
Phase> phase, CSU FTS
Indexer shall create FTS5 virtual tables (fts_objects, fts_attributes, fts_floats) with tokenize='porter'.
Given <Spec
Object> body <Abstract Syntax Tree>, CSU FTS Indexer shall
convert to plain text via Pandoc utils.stringify() before inserting
into the <Full-Text Search> index.
Selected Newline-Delimited JSON format for structured logging.
NDJSON enables:
Configuration via config.logging.level with env override
SPECCOMPILER_LOG_LEVEL.
Selected luv (libuv) for parallel subprocess execution.
Document processing benefits from parallel execution:
Selected preset system for DOCX style customization.
Corporate documents require consistent styling. The preset system:
Selected Deno as the runtime for TypeScript-based external tools.
Deno provides:
npm: specifiers
Tools are spawned via task_runner.spawn_sync() with timeout
handling.
Selected Pandoc as the document parsing and output generation engine.
Pandoc serves as both input parser and output generator:
pandoc.read() provides a well-defined
AST
--reference-doc support enables
DOCX style customization via generated reference.docx
--lua-filter support enables
format-specific transformations (docx.lua, html.lua)
The type system and domain model definition function encompasses the default model components that provide base type definitions, format-specific processing, and style configuration. These components are overlaid by the host engine (<Type Loader>, Type Loader) during the model discovery phase described in Type Model Discovery and Registration and collectively define the foundational capabilities that all domain models inherit and extend.
Model Directory Structure: Each model provides a
standard directory layout with types/
(objects, floats, relations, views, specifications), filters/, postprocessors/, and styles/ subdirectories. Each .lua file under types/ returns one descriptor table { kind, schema, [hooks] }. The host reads
the descriptor fields. The default model (models/default/) establishes baseline
definitions for all five type categories.
Type Definitions: CSC-017 defines the foundational document
object and specification types (SECTION, SPEC) that every overlay reuses. CSC-022 defines float types
(FIGURE, TABLE, LISTING, PLANTUML, CHART, MATH) with counter groups for
shared numbering. CSC-023
defines the reusable base relation types (PID_REF, LABEL_REF) plus built-in cross-reference
relations (XREF_SEC, XREF_FIGURE, XREF_TABLE, XREF_LISTING, XREF_MATH, XREF_CITATION) that map @ and #
selectors to typed targets without reimplementing resolution. CSC-024 defines view types
(TOC, LOF, ABBREV, ABBREV_LIST, GAUSS, MATH_INLINE) with inline prefix
syntax and materializer strategies.
Format Processing: CSC-018 provides Pandoc Lua filters for DOCX, HTML, and Markdown output that convert speccompiler-format markers (page breaks, bookmarks, captions, equations) into native output elements. CSC-019 applies format-specific post-processing after Pandoc output generation, loading template-specific fixup modules for DOCX and LaTeX. CSC-021 defines style presets with page layout, typography, and formatting configuration for DOCX (Letter-sized, standard margins) and HTML (Inter/JetBrains Mono fonts, color palette) output.
Component Interaction
The default model is realized through six packages that define the baseline type system, format processing, and style configuration inherited by all domain models.
CSC Default Float Types (Default Float Types) defines the visual content types. CSU FIGURE Float Type (FIGURE) handles image-based floats. CSU TABLE Float Type (TABLE) handles tabular data with CSV parsing. CSU LISTING Float Type (LISTING) handles code blocks with syntax highlighting. CSU PLANTUML Float Type (PLANTUML) renders UML diagrams via external subprocess. CSU CHART Float Type (CHART) renders ECharts visualizations. CSU MATH Float Type (MATH) renders LaTeX equations via KaTeX. Each type declares a counter group for cross-specification numbering.
CSC Default Relation
Types (Default Relation Types) defines reusable cross-reference
relations. The base types PID_REF and
LABEL_REF centralize @ and # resolution. XREF_SEC targets sections by PID. CSU XREF_FIGURE Relation Type
(XREF_FIGURE) targets FIGURE floats. CSU XREF_TABLE Relation Type (XREF_TABLE)
targets TABLE floats. CSU
XREF_LISTING Relation Type (XREF_LISTING) targets LISTING floats. CSU XREF_MATH Relation Type
(XREF_MATH) targets MATH floats. CSU XREF_CITATION Relation Type
(XREF_CITATION) resolves bibliography citations via BibTeX keys.
CSC Default View Types (Default View Types) defines data views with inline prefix syntax. CSU TOC View Type (TOC) generates tables of contents from spec objects. CSU LOF View Type (LOF) generates lists of figures, tables, or listings by counter group. CSU ABBREV View Type (ABBREV) renders inline abbreviation expansions. CSU ABBREV_LIST View Type (ABBREV_LIST) generates abbreviation glossaries. CSU GAUSS View Type (GAUSS) renders Gaussian distribution charts. CSU MATH_INLINE View Type (MATH_INLINE) renders inline LaTeX math expressions.
CSC Default Filters (Default Filters) provides format-specific Pandoc Lua filters applied during EMIT. CSU DOCX Filter (DOCX Filter) converts markers to OOXML-compatible elements — page breaks, bookmarks, and custom styles. CSU HTML Filter (HTML Filter) converts markers to semantic HTML5 elements with CSS classes. CSU Markdown Filter (Markdown Filter) normalizes markers for clean Markdown output.
CSC Default Postprocessors (Default Postprocessors) applies fixups after Pandoc generation. CSU DOCX Postprocessor (DOCX Postprocessor) manipulates the OOXML package — injecting custom styles, fixing table widths, and applying numbering overrides. CSU LaTeX Postprocessor (LaTeX Postprocessor) applies template-specific LaTeX fixups for PDF output.
CSC Default Styles (Default Styles) provides output styling presets. CSU DOCX Style Preset (DOCX Style Preset) defines page layout (Letter, standard margins), heading styles, table formatting, and font selections for Word output. CSU HTML Style Preset (HTML Style Preset) defines the web typography (Inter/JetBrains Mono), color palette, and responsive layout for HTML output.
Given a source file path, CSU Specification Parser shall derive the
<Specification> identifier from the filename without
extension.
When a L1 header declares an unknown type_ref, CSU Specification Parser shall fall back to
the default <Type> or emit a <Diagnostic Record> warning via CSU Diagnostics
Collector.
Given source path, start_line, and title_text, CSU Object Parser and CSU Hash Utilities shall compute the <Spec
Object> identifier as
SHA1 hash of the concatenation.
Given L2-H6 header text, CSU Object Parser shall resolve the <Type> in
order: explicit TYPE: prefix →
<Type
Alias> lookup in <Type Registry> → default type.
Given a resolved <Spec Object>, CSU Object Parser shall format the label field as {type_lower}:{title_slug} for (#) cross-referencing.
Given a float source context, CSU Float Parser and CSU Hash Utilities shall compute the <Spec
Float> identifier in
short format float-{8-char-sha1}
for DOCX bookmark compatibility.
Given a CodeBlock class string, CSU Float Parser shall resolve the <Spec
Float> type_ref from <Type
Alias> entries in spec_float_types (e.g., “csv” →
“TABLE”).
When a <Spec
View> has needs_external_render = 1 in spec_view_types, CSU External Render Handler shall delegate
it to the registered <External Renderer>.
Given Inline Code with type: content format, CSU View Parser shall insert a <Spec
View> record with view_type_ref and raw_ast.
Given a (@) <Relation
Selector>, CSU
Resolution Queries shall resolve via spec_objects.pid; given (#) <Relation Selector>, CSU Resolution Queries
shall resolve via spec_objects.label or spec_floats.label.
When no explicit relation type is provided, CSU Relation Type Inferrer shall select the
default <Spec
Relation> type where is_default = 1 AND link_selector matches in spec_relation_types.
Given an ENUM <Attribute> raw_value, CSU Attribute Caster shall
resolve it against the enum_values table and populate the
enum_ref foreign key.
Given an XHTML <Attribute> raw_value, CSU Attribute Parser shall
preserve the Pandoc <Abstract Syntax Tree> serialization
in the ast column as JSON.
Given a <Analyze Query> SQL string, CSU Analyze Query Loader
shall register it as a CREATE VIEW in the <SpecIR> database during the <ANALYZE
Phase> phase.
Given a <Validation Policy> policy_key and project.yaml
configuration, CSU
Validation Policy shall return severity (error, warn, ignore) controlling <Diagnostic Record> emission.
Selected layered model loading where domain models extend and override the default model by type identifier.
ID-based override enables clean domain specialization:
policy_key
Allocation: Realized by Core Runtime (Core Runtime) and Default Analyze Queries (Default Analyze Queries) through Analyze Handler (Analyze Handler) and Hash Utilities (Hash Utilities).
The audit and integrity function ensures deterministic compilation, reproducible builds, and audit trail integrity. It encompasses content-addressed hashing for incremental build detection, structured logging for audit trails, and include dependency tracking for proper cache invalidation.
Include Hash Computation: The engine (Build Engine) queries the
build_graph table for known includes
from the previous build, then computes SHA1 hashes for each include
file. Missing files cause a cache miss (triggering a full rebuild). The
resulting map of path-to-hash is compared against stored values to
detect changes. SHA1 hashing uses Pandoc’s built-in pandoc.sha1() when available, falling back
to vendor/sha2.lua in standalone
worker mode.
Document Change Detection: Each document’s content
is hashed and compared against the hashes recorded as build_graph nodes (the root document is
its own node, alongside its includes). Unchanged documents (every node
hash matching) skip parsing and reuse cached <Intermediate Representation> state,
providing significant performance improvement for large projects.
Structured Logging: NDJSON (Newline-Delimited JSON)
logging provides machine-parseable audit trails with structured data
(level, message, timestamp, context). Log level is configurable via
config.logging.level with
environment override via SPECCOMPILER_LOG_LEVEL. Levels: DEBUG,
INFO, WARN, ERROR.
Build Reproducibility: Given identical source files (by content hash), project configuration, and tool versions, the system produces identical outputs. Content-addressed hashing of documents, includes, and the P-IR state ensures deterministic compilation.
Verification Execution: The Analyze Handler Analyze Handler executes in batch mode during the ANALYZE phase. It iterates over all registered analyze queries, querying each via the Data Manager Data Manager. For each violation row returned, the handler consults the Validation Policy Validation Policy to determine the configured severity level. Error-level violations are emitted as structured diagnostics via the Diagnostics Collector Diagnostics Collector. Violations at the ignore level are suppressed entirely. Each analyze query enforces constraints declared by the type metamodel, ensuring that registered types satisfy their validation rules.
After verification completes, the handler stores the verification result (error and warning counts) in all pipeline contexts. The Pipeline Orchestrator Pipeline Orchestrator checks for errors after ANALYZE and aborts before EMIT if any exist.
Analyze Queries — Entity-Based Taxonomy
Verification views follow the SpecIR 5-tuple: S
(Specification), O (Object), F (<Float>),
R (Relation), V (View). Each analyze
query is identified by its policy_key.
Specification Verification views (S)
| Policy Key | View Name | Validates |
|---|---|---|
spec_missing_required |
view_spec_missing_required | Required spec attributes present |
spec_invalid_type |
view_spec_invalid_type | Specification type is valid |
Spec Object Verification views (O)
| Policy Key | View Name | Validates |
|---|---|---|
missing_required |
view_object_missing_required | Required object attributes present |
cardinality_over |
view_object_cardinality_over | Attribute count <= max_occurs |
invalid_cast |
view_object_cast_failures | Attribute value casts to declared type |
invalid_enum |
view_object_invalid_enum | Enum value exists in enum_values |
invalid_date |
view_object_invalid_date | Date format is YYYY-MM-DD |
bounds_violation |
view_object_bounds_violation | Numeric values within min/max bounds |
object_duplicate_pid |
view_object_duplicate_pid | PID is globally unique |
Spec Float Verification views (F)
| Policy Key | View Name | Validates |
|---|---|---|
float_orphan |
view_float_orphan | Float has a parent object |
float_duplicate_label |
view_float_duplicate_label | Float labels unique per specification |
float_render_failure |
view_float_render_failure | External render succeeded |
float_invalid_type |
view_float_invalid_type | Float type is registered |
Spec Relation Verification views (R)
| Policy Key | View Name | Validates |
|---|---|---|
unresolved_relation |
view_relation_unresolved | Link target resolves |
dangling_relation |
view_relation_dangling | Target ref points to existing object |
ambiguous_relation |
view_relation_ambiguous | Float reference is unambiguous |
Component Interaction
The audit subsystem is realized through core runtime components and the default verification view package.
CSC Core Runtime (Core
Runtime) provides the verification infrastructure. CSU Build Engine (Build Engine) drives the
build lifecycle and content-addressed hash computation. CSU Analyze Query Loader
(Analyze Query Loader) discovers and loads analyze query modules from
model directories, registering them with the data manager for ANALYZE
phase execution. CSU
Validation Policy (Validation Policy) maps analyze query policy_key values to configured severity
levels (error, warn, ignore) from project.yaml. CSU Analyze Handler (Analyze Handler)
iterates over registered analyze queries during ANALYZE, querying each
via CSU Data Manager
(Data Manager) and emitting violations through CSU Diagnostics Collector (Diagnostics
Collector). CSU Pipeline
Orchestrator (Pipeline Orchestrator) inspects diagnostics after
ANALYZE and aborts before EMIT if errors exist.
CSC Default Analyze Queries (Default Analyze Queries) provides the baseline verification rules organized by the SpecIR 5-tuple. Specification analyze queries: CSU Spec Missing Required (Spec Missing Required) validates that required specification attributes are present, and CSU Spec Invalid Type (Spec Invalid Type) validates that specification types are registered. Object analyze queries: CSU Object Missing Required (Object Missing Required) checks required object attributes, CSU Object Cardinality Over (Object Cardinality Over) enforces max_occurs limits, CSU Object Cast Failures (Object Cast Failures) validates attribute type casts, CSU Object Invalid Enum (Object Invalid Enum) checks enum values against allowed sets, CSU Object Invalid Date (Object Invalid Date) validates YYYY-MM-DD date format, and CSU Object Bounds Violation (Object Bounds Violation) checks numeric bounds. Float analyze queries: CSU Float Orphan (Float Orphan) detects floats without parent objects, CSU Float Duplicate Label (Float Duplicate Label) enforces label uniqueness per specification, CSU Float Render Failure (Float Render Failure) flags failed external renders, and CSU Float Invalid Type (Float Invalid Type) validates float type registration. Relation analyze queries: CSU Relation Unresolved (Relation Unresolved) detects links whose targets cannot be resolved, CSU Relation Dangling (Relation Dangling) detects resolved references pointing to nonexistent objects, and CSU Relation Ambiguous (Relation Ambiguous) flags ambiguous float references.
When build completes with no <ANALYZE Phase> errors, CSU Build Engine shall rewrite the <Build Graph> node hashes via CSU Build Cache; when errors are present, hashes shall not be updated.
When all <Build Graph> node hashes (root and includes) match current content, CSU Build Engine shall skip <Pipeline> processing and reuse cached <Intermediate Representation> state.
During include expansion, CSU Include Expansion Filter shall record
root_path, node_path, and node_sha1 for each included file into the
<Build
Graph> table via CSU
Build Cache.
When an include path is already in the processed-file set, CSU Include Expansion Filter shall raise an error with the circular include chain path before performing any expansion.
Given a diagnostics:error(file, line, code, msg)
or diagnostics:warn(...) call from
any <Handler>, CSU Diagnostics Collector shall store a <Diagnostic
Record> record with file
(path), line (int), code (string), and msg (string).
<Diagnostic Record> codes shall follow
domain prefix + number format (e.g., invalid_enum, dangling_relation) enabling
machine-parseable classification via CSU Diagnostics Collector.
Given non-TTY output, CSU
Logger shall emit one <Newline-Delimited JSON> object per
line with fields level, message, timestamp, and optional context.
Given TTY output with NO_COLOR
environment variable set, CSU Logger shall suppress ANSI color codes
in console mode.
CSU Float Numbering
shall determine <Spec Float> numbering solely by
file_seq ordering, which is stable
across builds for identical input.
CSU Build Cache shall base <Build Cache> dirty checks solely on SHA1 content hashes, never on filesystem timestamps or mtime.
Allocation: Realized by SW Docs Model (SW Docs Model), with domain analyze queries in SW Docs Analyze Queries (SW Docs Analyze Queries), object types in SW Docs Object Types (SW Docs Object Types), relation types in SW Docs Relation Types (SW Docs Relation Types), specification types in SW Docs Specification Types (SW Docs Specification Types), and view types in SW Docs View Types (SW Docs View Types).
The software documentation domain model extends the default model with traceable object types, domain-specific relation semantics, specification document types, and verification views for MIL-STD-498 and DO-178C compliant software documentation workflows.
Object Type Taxonomy: SW Docs Object Types defines the TRACEABLE
abstract base type providing an inherited status enum (Draft, Review,
Approved, Implemented) that all domain objects extend. The taxonomy
includes requirements (HLR, LLR, NFR), design elements (FD, SF, DD),
architectural decomposition (CSC, CSU), verification artifacts (VC, TR),
and reference types (DIC, SYMBOL). Each SW Docs type declares its own
attributes, PID prefix, and inheritance chain through the extends field.
Relation Types: SW Docs Relation Types defines
domain-specific traceability relations: REALIZES (FD traces to SF via
the traceability source attribute),
BELONGS (HLR membership in SF via belongs_to), TRACES_TO (general-purpose
@ link traceability), XREF_DIC
(dictionary cross-references), and XREF_DECOMPOSITION (references
targeting CSC/CSU elements). These relations enable automated
traceability matrix generation and coverage analysis.
Specification Types: SW Docs Specification Types defines document types for the software documentation lifecycle: SRS (Software Requirements Specification), SDD (Software Design Description), SVC (Software Verification Cases), SUM (Software User Manual), and TRR (Test Results Report). Each type declares version, status, and date attributes.
View Types: SW Docs View Types defines domain-specific views for generating traceability matrices (TRACEABILITY_MATRIX, TEST_EXECUTION_MATRIX, TEST_RESULTS_MATRIX) and coverage summaries (COVERAGE_SUMMARY, REQUIREMENTS_SUMMARY).
Analyze Queries: SW Docs Analyze Queries provides domain-specific analyze query queries that enforce traceability constraints: VC must trace to HLR, TR must trace to VC, every HLR must be covered by at least one VC, every FD must trace to at least one CSC and CSU, and every CSC and CSU must have at least one FD allocated. SW Docs Model provides the HTML5 postprocessor that generates a single-file documentation web app with embedded CSS, JS, and SQLite-WASM full-text search.
Component Interaction
The software documentation domain model is realized through six packages that extend the default model with traceable types, domain relations, document types, analyze queries, and verification constraints.
CSC SW Docs Object Types (SW Docs Object Types) defines the domain object taxonomy. CSU TRACEABLE Base Object Type (TRACEABLE Base Object Type) provides the abstract base with an inherited status enum (Draft, Review, Approved, Implemented) that all domain objects extend. Requirements: CSU HLR Object Type (HLR) for high-level requirements, CSU LLR Object Type (LLR) for low-level requirements, and CSU NFR Object Type (NFR) for non-functional requirements. Design elements: CSU FD Object Type (FD) for functional descriptions and CSU SF Object Type (SF) for software functions. Architecture: CSU CSC Object Type (CSC) for computer software components and CSU CSU Object Type (CSU) for computer software units. Verification: CSU VC Object Type (VC) for verification cases and CSU TR Object Type (TR) for test results. Design decisions: CSU DD Object Type (DD) for design decision records. Reference types: CSU DIC Object Type (DIC) for dictionary entries and CSU SYMBOL Object Type (SYMBOL) for symbol definitions.
CSC SW Docs Relation
Types (SW Docs Relation Types) defines domain-specific traceability
relations. CSU REALIZES
Relation Type (REALIZES) traces FD to SF via the traceability source attribute. CSU BELONGS Relation Type
(BELONGS) establishes HLR membership in SF via belongs_to. CSU TRACES_TO Relation Type (TRACES_TO)
provides general-purpose @ link
traceability between any traceable objects. CSU XREF_DIC Relation Type (XREF_DIC)
resolves dictionary cross-references targeting DIC entries.
CSC SW Docs Specification Types (SW Docs Specification Types) defines document types for the software documentation lifecycle. CSU SRS Specification Type (SRS) for Software Requirements Specifications. CSU SDD Specification Type (SDD) for Software Design Descriptions. CSU SVC Specification Type (SVC) for Software Verification Cases. CSU SUM Specification Type (SUM) for Software User Manuals. CSU TRR Specification Type (TRR) for Test Results Reports. Each type declares version, status, and date attributes.
CSC SW Docs View Types (SW Docs View Types) defines domain-specific views for documentation output. CSU Traceability Matrix View (Traceability Matrix) generates requirement-to-design traceability matrices. CSU Test Execution Matrix View (Test Execution Matrix) generates verification case execution status tables. CSU Test Results Matrix View (Test Results Matrix) generates test result summary tables. CSU Coverage Summary View (Coverage Summary) computes requirement coverage statistics. CSU Requirements Summary View (Requirements Summary) generates requirement status dashboards.
CSC SW Docs Analyze Queries (SW Docs Analyze Queries) provides domain-specific traceability verification rules. CSU VC Missing HLR Traceability (VC Missing HLR Traceability) ensures every verification case traces to at least one HLR. CSU TR Missing VC Traceability (TR Missing VC Traceability) ensures every test result traces to a verification case. CSU HLR Missing VC Coverage (HLR Missing VC Coverage) ensures every HLR is covered by at least one VC. CSU FD Missing CSC Traceability (FD Missing CSC Traceability) ensures every FD references at least one CSC. CSU FD Missing CSU Traceability (FD Missing CSU Traceability) ensures every FD references at least one CSU. CSU CSC Missing FD Allocation (CSC Missing FD Allocation) ensures every CSC is allocated to at least one FD. CSU CSU Missing FD Allocation (CSU Missing FD Allocation) ensures every CSU is allocated to at least one FD.
CSC SW Docs Model (SW Docs Model) provides the domain postprocessor. CSU HTML5 Postprocessor (HTML5 Postprocessor) generates a single-file documentation web application with embedded CSS, JS, navigation, and SQLite-WASM full-text search from the SpecIR database.
This chapter defines decomposition and design allocation using MIL-STD-498 nomenclature:
CSC (<CSC (Computer Software Component)>)
identifies structural subsystems/layers.
CSU (<CSU (Computer Software Unit)>)
identifies concrete implementation units.
Note: Software Functions (SF) are defined in the SRS alongside their constituent HLRs. Functional Descriptions (FD) trace to SFs via the REALIZES relation and are documented in the SDD design files.
[PID](@) and [PID](#)) from object ASTs and stores
them in spec_relations. Type inference and link rewriting are delegated
to relation_type_inferrer (RESOLVE) and relation_link_rewriter
(TRANSFORM).
@ and # links in stored spec_object AST JSON,
replacing them with resolved anchor targets using the relation lookup
built from spec_relations.
The matrix below is generated live from SpecIR at build time and lists only HLRs whose allocation chain (SF -> FD -> CSC -> CSU) is incomplete. An empty result means every requirement is fully allocated to the design.
| HLR | HLR Title | SF | FD | CSC | CSU | Status |
|---|---|---|---|---|---|---|
| HLR-AUDIT-001 | Content-Addressed Hashing | SF-006 | FD-006 | — | — | No CSC |
| HLR-AUDIT-001 | Content-Addressed Hashing | SF-006 | FD-006 | CSC-001 | — | No CSU |
| HLR-AUDIT-002 | Include Dependency Tracking | SF-006 | FD-006 | — | — | No CSC |
| HLR-AUDIT-002 | Include Dependency Tracking | SF-006 | FD-006 | CSC-001 | — | No CSU |
| HLR-AUDIT-003 | Structured Diagnostic Reporting | SF-006 | FD-006 | — | — | No CSC |
| HLR-AUDIT-003 | Structured Diagnostic Reporting | SF-006 | FD-006 | CSC-001 | — | No CSU |
| HLR-AUDIT-004 | Structured Logging | SF-006 | FD-006 | — | — | No CSC |
| HLR-AUDIT-004 | Structured Logging | SF-006 | FD-006 | CSC-001 | — | No CSU |
| HLR-AUDIT-005 | Build Reproducibility | SF-006 | FD-006 | — | — | No CSC |
| HLR-AUDIT-005 | Build Reproducibility | SF-006 | FD-006 | CSC-001 | — | No CSU |
| HLR-CFG-001 | Manifest Configuration | SF-005 | FD-002 | — | — | No CSC |
| HLR-CFG-001 | Manifest Configuration | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-001 | Type Descriptor Loading | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-001 | Type Descriptor Loading | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-002 | Model Directory Structure | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-002 | Model Directory Structure | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-003 | Descriptor Registration | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-003 | Descriptor Registration | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-004 | Type Schema | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-004 | Type Schema | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-005 | Model Resolution and Overlay | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-005 | Model Resolution and Overlay | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-006 | External Renderer Hooks | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-006 | External Renderer Hooks | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-007 | Data View Hooks | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-007 | Data View Hooks | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-008 | Hook Index | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-008 | Hook Index | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-009 | Canonical Hook Context | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-009 | Canonical Hook Context | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-010 | Model Manifest | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-010 | Model Manifest | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-011 | Hook Validation and Phase Registration | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-011 | Hook Validation and Phase Registration | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-EXT-012 | Analyze Query Descriptor | SF-005 | FD-002 | — | — | No CSC |
| HLR-EXT-012 | Analyze Query Descriptor | SF-005 | FD-002 | CSC-001 | — | No CSU |
| HLR-OUT-001 | Document Assembly | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-002 | Float Resolution | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-003 | Float Numbering | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-004 | Multi-Format Output | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-005 | DOCX Generation | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-006 | HTML5 Generation | SF-004 | FD-004 | — | — | No CSC |
| HLR-OUT-007 | Full-Text Search Indexing | SF-004 | FD-004 | — | — | No CSC |
| HLR-PIPE-001 | Five-Phase Lifecycle | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-001 | Five-Phase Lifecycle | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-002 | Handler Registration and Prerequisites | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-002 | Handler Registration and Prerequisites | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-003 | Topological Ordering via Kahn’s Algorithm | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-003 | Topological Ordering via Kahn’s Algorithm | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-004 | Phase Abort on ANALYZE Errors | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-004 | Phase Abort on ANALYZE Errors | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-005 | Batch Dispatch for All Phases | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-005 | Batch Dispatch for All Phases | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-006 | Context Creation and Propagation | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-006 | Context Creation and Propagation | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-007 | CommonSpec Input Parsing | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-007 | CommonSpec Input Parsing | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-008 | Include File Expansion | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-008 | Include File Expansion | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-009 | PID Auto-Generation | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-009 | PID Auto-Generation | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-010 | Relation Type Inference | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-010 | Relation Type Inference | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-011 | Prerequisite-Not-Found Diagnostic | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-011 | Prerequisite-Not-Found Diagnostic | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-PIPE-012 | Section Scope Termination | SF-001 | FD-001 | — | — | No CSC |
| HLR-PIPE-012 | Section Scope Termination | SF-001 | FD-001 | CSC-001 | — | No CSU |
| HLR-STOR-001 | SQLite Persistence | SF-002 | FD-003 | — | — | No CSC |
| HLR-STOR-002 | EAV Attribute Model | SF-002 | FD-003 | — | — | No CSC |
| HLR-STOR-003 | Build Cache | SF-002 | FD-003 | — | — | No CSC |
| HLR-STOR-004 | Output Cache | SF-002 | FD-003 | — | — | No CSC |
| HLR-STOR-005 | Incremental Rebuild Support | SF-002 | FD-003 | — | — | No CSC |
| HLR-STOR-006 | EAV Pivot Views for External Queries | SF-002 | FD-003 | — | — | No CSC |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-001 | Specifications Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-002 | Spec Objects Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-003 | Spec Floats Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-004 | Spec Views Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-005 | Spec Relations Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-006 | Spec Attributes Container | SF-003 | FD-005 | CSC-024 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | — | — | No CSC |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-017 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-018 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-019 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-021 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-022 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-023 | — | No CSU |
| HLR-TYPE-007 | Type Validation | SF-003 | FD-005 | CSC-024 | — | No CSU |