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), and spec_floats (prerequisite: specifications) — the sort produces [specifications, spec_floats, spec_objects], with spec_floats and spec_objects ordered alphabetically since both depend only on specifications.

Phase Execution: The pipeline executes five phases in order:

1. <INITIALIZE Phase> — Parse Pandoc <Abstract Syntax Tree> into <Intermediate Representation> database tables (specifications, spec_objects, attributes, spec_floats, spec_views, spec_relations)
2. <RESOLVE Phase> — Resolve cross-references and infer relation types
3. <TRANSFORM Phase> — Render content, materialize views, execute external renderers
4. <ANALYZE Phase> — Run analyze queries and collect diagnostics
5. <EMIT Phase> — Assemble documents and generate output files

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.

Selected Entity-Attribute-Value storage for dynamic object and float attributes.

Selected a five-phase sequential pipeline (INITIALIZE, RESOLVE, TRANSFORM, ANALYZE, EMIT) for document processing.

Selected Kahn’s algorithm with declarative prerequisite arrays for handler execution ordering within each pipeline phase.

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/.

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.

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.

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.

Selected runtime-generated CREATE VIEW statements per object type to pivot EAV attributes into typed columns.

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.

Selected luv (libuv) for parallel subprocess execution.

Selected preset system for DOCX style customization.

Selected Deno as the runtime for TypeScript-based external tools.

Selected Pandoc as the document parsing and output generation engine.

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.

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)

Spec Object Verification views (O)

Spec Float Verification views (F)

Spec Relation Verification views (R)

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.