1 WiSACS V1 Prototype Specification

2 Document Status

This Pandoc Markdown specification records the local implementation contract for the WiSACS V1 prototype. It is repository-maintained and is intended to be edited with the implementation changes it describes.

The prototype exposes a deterministic local API under:

/api/v1

The implementation is simulation-first by default. It models discovery, situational awareness, RF/IP network inventory, and advisory interoperability recommendations without real radio control, real active RF sensing, certified emergency-services deployment, or automatic live network bridging.

3 Update Workflow

1. Update catalog.py when normative intent, lifecycle, or evidence changes.
2. Run make spec-generate, review the generated diff, and run make spec-check.
3. Update docs/spec/*.md only for explanatory design material that is not generated from code.
4. Render review output with line numbers when needed:

uv run python scripts/build_wisacs_spec_docs.py --mode review --format pdf

4 Pandoc Markdown Conventions

This specification uses Pandoc Markdown rather than plain CommonMark so the source can carry stable requirement anchors, document metadata, pipe tables, definition lists, fenced code blocks, and PDF-oriented review controls without requiring authors to write LaTeX.

Generated requirement headings use explicit identifiers such as:

### WISACS-CATEGORY-NNN: Requirement Title {#WISACS-CATEGORY-NNN}

Catalog evidence uses tracked paths, Python qualified names, OpenAPI operation IDs, and collected test node IDs. The semantic validator resolves those references rather than counting identifier mentions in prose.

5 Normative Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in uppercase.

The generated catalog defines the normative conformance rules for these two profiles:

Simulation Profile

The deterministic local API implemented in this repository. A Simulation Profile implementation MAY use seeded demo users, local SQLite state, simulated incident data, and caller-supplied observations, but it MUST expose those limitations.

Production Profile

A target operational WiSACS implementation. A Production Profile implementation MUST satisfy Simulation Profile requirements that are not explicitly marked simulation-only, and MUST additionally satisfy production identity, persistence, cryptographic, operational-safety, audit-retention, and incident-data governance requirements.

Profile descriptions in this narrative are informative summaries. The identified requirements in the generated requirements chapter are authoritative.

6 Specification Parts

The complete rendered specification is assembled by build_wisacs_spec_docs.py in this order:

1. System definition and workflow.
2. API contract.
3. Data model.
4. Security posture.
5. SCA alignment.
6. Render deployment.
7. Traceability workflow.
8. Generated normative requirements and executable contracts.
9. Generated implementation, verification, and traceability maps.

That split keeps reviewed intent in a side-effect-free catalog, explanatory prose in docs/spec/, and executable facts in generated artifacts.

6.1 Purpose

WiSACS defines a prototype system for disaster-response wireless situation awareness and coordination. The system helps responders and incident coordinators answer three early-scene questions:

1. Who is present?
2. Where are personnel, devices, and observed RF/IP systems?
3. Which communication paths appear technically plausible enough for human review?

This specification describes V1 prototype behavior. It is not a production emergency-services certification, a live network-bridging standard, or a formal SCA conformance profile.

6.2 Scope

V1 covers discovery, inventory, visualization support, advisory interoperability recommendations, and reviewable SCA-ready metadata. V1 intentionally excludes automatic radio control, automatic cross-network bridging, active RF scanning hardware control, production identity federation, and operational policy automation.

6.3 Terms and Definitions

Incident

An emergency-scene operating context that bounds responders, devices, networks, observations, recommendations, and event history.

Responder

A person, crew role, or operational unit participating in an incident.

Field device

A radio, handset, tablet, gateway, router, SDR sensor, laptop, or other deployed system that may communicate, observe RF conditions, or provide services.

Network

An observed RF, IP, voice, mesh, satellite, or other communication system present at the incident.

Network attachment

Evidence that a field device is associated with a network, including optional address, signal, reachability, and observation metadata.

RF observation

A report of spectrum activity at a frequency with optional bandwidth, RSSI, protocol guess, modulation guess, confidence, source, and location.

Service endpoint

A TCP/IP-reachable service reported for a device or network.

Interoperability recommendation

An advisory result that summarizes a candidate communication path and its supporting evidence for human review.

SCA-ready descriptor

A draft JSON representation of device/component metadata that is shaped to support later SCA descriptor work but is not a conformance artifact.

6.4 Informative System Overview

The V1 prototype uses a cloud-hosted API as the shared incident state. Field users, simulation tools, or later hardware probes submit observations. The backend stores these observations, computes advisory recommendations, and exposes inventory data to client applications. The single-origin public deployment serves documentation at the root path, a lightweight HTML/SVG browser operational dashboard at /visualization, and the operational API under /api/v1. The Godot visualization can run as an installed client against the same hosted API, while the Flutter scaffold remains available for later cross-platform client development.

The system is deliberately conservative. WiSACS may identify that multiple devices share an IP network, that a gateway is attached to more than one network, or that a voice-only path must be preserved. WiSACS does not activate a bridge or change live network policy in V1.

6.5 Normative Requirements

Normative requirements are generated from the typed catalog and assembled later in this document. This chapter intentionally contains no hand-maintained requirement declarations.

6.6 Non-Normative Notes

V1 discovery is manual entry plus simulator/probe ingestion. Active RF scanning, production identity federation, and live data relay are deferred.

6.7 Informative V1 Workflow

A typical demonstration flow is:

1. An incident coordinator authenticates to the API.
2. The demo scenario or a probe tool posts responders, field devices, networks, attachments, RF observations, and service endpoints.
3. The backend computes interoperability recommendations from the current incident inventory.
4. The client displays the operating area, responders, devices, networks, observations, and recommendations.
5. Reviewers inspect each recommendation and its evidence before any real-world action is taken outside WiSACS.

7 WiSACS API Specification

7.1 Purpose

The WiSACS API is the system boundary between clients, probe tools, stored incident state, and interoperability recommendation logic. The API is designed to be inspectable through OpenAPI and usable by both the Flutter client and lightweight command-line tools.

7.2 API Conventions

All operational REST endpoints are under /api/v1. Root-level health and readiness endpoints are provided for hosting platforms that expect simple unauthenticated checks. JSON is the default request and response format. Identifier fields are opaque strings and should not be parsed by clients.

Bearer-token authentication is used for V1 operational endpoints. Demo users are seeded by the prototype for local review, but production deployments should replace this with an incident-appropriate identity and authorization design.

7.3 Roles

Admin

A user with prototype administrative access.

Commander

A user allowed to perform privileged setup actions such as loading the demo scenario.

Responder

A field user expected to contribute or inspect incident observations.

Observer

A read-only review user. Observer credentials MUST NOT create or mutate incident inventory.

7.4 Resource Families

The API is grouped around the incident lifecycle:

• Health and readiness checks support deployment and monitoring.
• Authentication endpoints issue and inspect bearer tokens.
• Inventory endpoints maintain incidents, responders, devices, networks, attachments, RF observations, and service endpoints.
• Recommendation endpoints compute advisory communication options from the current incident state.
• Import endpoints seed repeatable review scenarios.
• SCA endpoints expose draft metadata for later standards alignment.
• WebSocket endpoints publish incident update notifications.

7.5 Normative Requirements

The normative API requirements and their resolved implementation and verification evidence are generated from specification/catalog.py. The generated API reference is derived directly from the side-effect-free FastAPI OpenAPI contract.

7.6 API Shape

All operational REST endpoints are under /api/v1. The OpenAPI document is the executable API reference for V1.

7.7 Informative Error Handling

The prototype uses normal HTTP status codes: 401 for invalid or missing credentials, 403 for insufficient role authorization, 404 for missing resources, and 422 for schema validation errors generated by FastAPI/Pydantic. Future versions should standardize a structured error body once client behavior depends on machine-readable error categories.

8 WiSACS Data Model Specification

8.1 Purpose

The WiSACS data model preserves the minimum shared incident state needed to understand who is present, which communication systems are present, and which interoperability options can be reviewed. The model favors explicit incident scoping and flexible metadata fields because early disaster-response observations are incomplete and evolve quickly.

8.2 Entity Overview

Incident

The root entity for an emergency-scene dataset.

Responder

A person or operational unit associated with an incident.

Field device

Equipment associated with a responder or incident.

Network

A detected or manually entered RF/IP/voice/mesh/satellite communication system.

Network attachment

A relationship between a device and a network with reachability evidence.

RF observation

A spectrum observation produced manually, by a simulator, or by future sensor ingestion.

Service endpoint

A reachable service exposed by a device on a network.

Interop recommendation

A computed advisory record with evidence and risk metadata.

Event log

A lightweight audit/event record for incident state changes.

8.3 Relationship Model

Every operational entity is scoped to an incident. Devices may be assigned to responders, may attach to one or more networks, and may expose service endpoints. Networks may have many device attachments and may carry service endpoints. RF observations may be sourced by a device when the observer is known.

The V1 schema stores latitude and longitude as scalar fields for broad client compatibility. Operational areas and coverage areas are represented as GeoJSON-compatible JSON so the API can support maps without requiring every deployment to use spatial queries immediately.

8.4 Normative Requirements

Normative data requirements and resolved evidence are generated from the typed catalog. The generated data dictionary is derived from SQLAlchemy metadata; Alembic revisions remain the authoritative deployed schema history.

8.5 Storage

PostgreSQL with PostGIS is the production datastore. SQLite is permitted as a local development and automated-test fallback.

Local/test setup may create an empty schema directly. Every change to a populated or deployed database, including additions, renames, drops, type changes, backfills, and stricter constraints, belongs in a reviewed Alembic revision.

8.6 Informative Metadata Guidance

The metadata_tags, properties, and descriptor metadata fields are intended for ontology tags, source-system hints, confidence annotations, and newly discovered attributes. These fields should not become a dumping ground for stable fields that clients depend on; stable cross-client behavior should graduate into named schema fields in later versions.

9 WiSACS Security Specification

9.1 Purpose

WiSACS V1 handles operationally sensitive situational-awareness data. Even in prototype form, the API distinguishes public health checks from authenticated operational behavior and avoids taking automatic live-network actions.

9.2 Security Boundary

The V1 backend is the trust boundary for incident state. Clients and probe tools are treated as untrusted input sources. The backend validates request schemas, authenticates users, applies role checks to privileged actions, and records state through the database model.

9.3 Threat Model

The prototype is primarily concerned with:

• unauthenticated access to incident inventory,
• unauthorized loading or mutation of incident state,
• browser-delivered visualization code that shares an origin with the API,
• accidental interpretation of advisory recommendations as automatic approval,
• accidental claims of formal SCA compliance,
• and stale or fabricated observations being treated as field truth without review.

The prototype does not yet address production-grade federation, hardware attestation, incident-specific access policy, encrypted offline synchronization, or regulated audit retention.

9.4 Normative Requirements

Normative security requirements, route access classifications, and their executable evidence are generated from the catalog and application contract. This chapter retains the threat model and design explanation only.

9.5 V1 Security Posture

V1 may use explicitly enabled local demonstration users in the Simulation Profile. Production Profile rejects demo identities, demo scenario mutation, and the development signing secret. Production federation, audit retention rules, and incident-specific membership policy remain future work.

9.6 Same-Origin Web Notes

The preferred public deployment places documentation, browser visualization, and API calls on the same HTTPS origin. This avoids making cross-origin API access part of the default security posture. Same-origin deployment does not remove the need for authentication, input validation, content security policy review, or production identity replacement.

9.7 Informative Authorization Notes

Authentication proves that a caller has a recognized prototype user identity. Authorization determines whether that caller can perform a privileged action. V1 uses simple role checks to keep the prototype reviewable. A production deployment should replace seeded users, static roles, and development secrets before use with real incident data. Non-privileged responders and observers are additionally scoped by explicit incident memberships; observers receive read-only memberships and mutation routes reject them.

10 WiSACS SCA Alignment Specification

10.1 Purpose

WiSACS V1 is SCA-ready rather than SCA-compliant. The prototype captures device and service metadata in a shape that can be reviewed by SCA practitioners and later transformed into formal descriptor artifacts if the workgroup chooses that direction.

10.2 Informative Alignment Goals

The V1 alignment work has three goals:

1. Preserve component-like metadata for field devices.
2. Represent ports and properties in a form that can be inspected outside the application.
3. Avoid overstating compliance before a dedicated conformance profile, descriptor format, and validation process exist.

10.3 Conceptual Mapping

10.4 Normative Requirements

Normative SCA-alignment requirements and executable evidence are generated from the typed catalog. The mapping below is explanatory and is not a formal SCA conformance claim.

10.5 Mapping

WiSACS field devices map loosely to SCA components or devices. Service endpoints map to exposed ports. Device properties and descriptor metadata preserve values that may later be transformed into formal SCA descriptor artifacts.

10.6 Informative Conformance Note

Reviewers should treat V1 descriptors as traceable metadata exports. They are useful for discussing SCA alignment, but they are not XML descriptor files, are not generated by an SCA toolchain, and are not validated against an SCA conformance suite.

11 WiSACS Render Deployment Specification

11.1 Purpose

The WiSACS deployment profile describes how the prototype can be hosted as a single Render-backed web application and managed PostgreSQL database. The public deployment uses one origin, https://wisacs.winnforum.org, for documentation, browser visualization, and /api/v1 API calls. The same project can run locally with SQLite for quick review or Docker Compose for a local PostgreSQL/PostGIS workflow.

11.2 Deployment Components

Web application service

Runs the FastAPI application with Uvicorn, serves the documentation landing page, serves the lightweight HTML/SVG browser visualization, and exposes the operational API under /api/v1.

Installed clients

Godot and future Flutter clients may run on handsets or desktops and call the same hosted API origin.

PostgreSQL database

Stores incident, inventory, observation, recommendation, user, and event data.

PostGIS extension

Provides the production geospatial foundation for future spatial queries and indexes.

11.3 Configuration Model

Render supplies DATABASE_URL from the managed database. The web application also reads WISACS_SECRET_KEY, WISACS_ENV, WISACS_PROFILE, WISACS_ENABLE_DEMO_USERS, WISACS_ENABLE_DEMO_SCENARIO, WISACS_BOOTSTRAP_ADMIN_USERNAME, WISACS_BOOTSTRAP_ADMIN_PASSWORD, WISACS_AUTO_CREATE_SCHEMA, and WISACS_PUBLIC_BASE_URL; Render additionally selects the pinned PYTHON_VERSION. Local development may omit DATABASE_URL, in which case the application uses SQLite. Deployment environment and conformance profile are independent settings.

The optional ontology LLM planner uses WiSACS_OPENAI_API_KEY (secret), WISACS_QA_LLM_ENABLED=false, WISACS_QA_LLM_MODEL=gpt-5.6-luna, WISACS_QA_LLM_REASONING_EFFORT=medium (one of none, low, medium, high, xhigh, or max), WISACS_QA_LLM_TIMEOUT_SECONDS, WISACS_QA_LLM_MAX_OUTPUT_TOKENS, WISACS_QA_LLM_MAX_REPAIRS, and WISACS_QA_LLM_ALLOW_PUBLIC=false. Configure the secret through Render’s secret management; do not place credential material in source, blueprints, or documentation. The public qa_html LLM form requires both LLM enablement and the explicit public-mode setting, and it must remain disabled until rate and cost controls are accepted. Published token rates are model-specific; higher reasoning effort can consume more reasoning and output tokens and increase latency. Consult the provider’s current model pricing rather than recording volatile dollar rates here.

11.4 Normative Requirements

Normative deployment requirements and the deployment matrix are generated from the catalog and checked deployment descriptors. This chapter explains the intended Render topology and operational posture.

11.5 Deployment Notes

The backend start command runs uv run --no-sync python scripts/migrate_database.py before uv run --no-sync uvicorn wisacs_api.main:app --host 0.0.0.0 --port $PORT. Render supplies the database connection string through DATABASE_URL. The render.yaml blueprint attaches wisacs.winnforum.org to the web service, references the Render PostgreSQL resource as wisacs-db, and uses /ready as the health check path.

The hosted service uses production environment safeguards with the Simulation Profile. Published demo users remain disabled, the distinct Harbor/Milwaukee and Place Victoria/Old Montreal inventory fixtures are enabled, and a generated bootstrap password creates wisacs-admin only when that username does not exist. Existing Harbor demo deployments backfill the companion Old Montreal fixture at startup without replacing either incident identity. Changing the bootstrap environment password later does not rotate an existing database credential.

When enabled, model input contains the submitted question plus compact, process-cached and versioned TBox context. It returns a strict structured plan that WiSACS validates against the ontology and supported query capability, with at most one repair. The existing compiler alone produces incident-scoped SPARQL. Incident facts and IDs are never model input; the provider key authenticates the API request but is never prompt content.

11.6 Informative Operations Notes

The V1 deployment profile is suitable for prototype review and demonstration. Before production use, operators should add managed secret rotation, database backups, stronger identity integration, TLS/domain review, incident data retention policy, operational monitoring, and a decision on whether demo credentials are disabled or isolated from operational incident data.

12 WiSACS Traceability Specification

12.1 Purpose

Traceability keeps reviewed intent, executable contracts, implementation, and tests moving together. Each normative requirement has a stable ID and semantically resolvable implementation and verification evidence.

12.2 Traceability Model

Normative requirement

A typed record declared in specification/catalog.py with a stable WISACS-* ID and RFC-style requirement language.

Implementation reference

A Git-tracked path, qualified Python symbol, or OpenAPI operation ID resolved by the semantic validator.

Verification reference

A collected test node ID or an explicitly classified manual verification record.

Review PDF

A Pandoc/LaTeX PDF with line numbers intended for comment-based review.

12.3 Normative Requirements

Normative traceability requirements and their evidence are generated from the typed catalog. The generated trace matrix is the review surface for resolved and missing evidence.

12.4 Review Practice

Normative requirement IDs are stable anchors. Review comments should cite catalog IDs and line numbers from generated PDFs when available.

12.5 Informative Maintenance Workflow

When a requirement changes, update its catalog record and executable evidence in the same change, regenerate artifacts, and review the semantic diff. Automated resolution proves that evidence exists and targets a real symbol, operation, or test; human review still decides whether the evidence actually satisfies the requirement.

13 Generated Normative Requirements

Specification version: 0.1.0. Release date: 2026-07-10. Source hash: 7c8856a289d3eea6d28a12bed1bd3469318d4d20bfe8a1494f8693e05f5e880a.

Generated from specification/catalog.py; do not edit this file directly.

13.1 API Requirements

13.1.1 WISACS-API-004: Role-Based Access Control

The API MUST enforce role-based access control, restricting administrative and commander operations.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Non-commander/admin roles receive HTTP 403 Forbidden on restricted operations.

13.1.2 WISACS-API-008: Incident Membership Scoping

The API MUST verify incident membership permissions before allowing data mutation.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Users without active membership in an incident cannot modify its inventory.

13.1.3 WISACS-API-001: Health and Readiness

The API MUST expose health and readiness endpoints for local and hosted deployment checks.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Root and API-prefixed health/readiness endpoints return successful status payloads.

13.1.4 WISACS-API-002: Authentication Identity

The API MUST provide a login endpoint and an authenticated current-user endpoint.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Valid credentials issue a token accepted by the current-user operation; invalid tokens fail.

13.1.5 WISACS-API-003: Incident Read & Write Operations

The API MUST allow authenticated users to list accessible incidents.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Authenticated users retrieve accessible incidents.

13.1.6 WISACS-API-007: Strict Schema Validation

The API MUST enforce strict Pydantic input schema validation rejecting unknown fields and out-of-range bounds.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Payloads with unknown or out-of-range fields trigger HTTP 422 Unprocessable Entity.

13.1.7 WISACS-API-005: OpenAPI Contract Integrity

The implementation MUST generate valid OpenAPI schemas without database initialization side-effects.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Contract OpenAPI generation completes cleanly without connecting to databases.

13.1.8 WISACS-API-006: Rate Limiting Safeguards

The API MUST enforce sliding window rate limiting on sensitive login and map tile endpoints.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Requests exceeding rate thresholds return HTTP 429 Too Many Requests.

13.2 System Requirements

13.2.1 WISACS-SYS-004: FastAPI Standard Architecture

The implementation MUST construct its API endpoints using FastAPI routers and OpenAPI contracts.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• OpenAPI schemas generated from FastAPI routers conform to contract metadata.

13.2.2 WISACS-SYS-001: Incident-Scoped Inventory

The system MUST maintain an incident-scoped inventory of responders, field devices, networks, RF observations, reachable service endpoints, recommendations, memberships, and events.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• A demo import exposes each entity only through its authorized incident scope.

13.2.3 WISACS-SYS-005: In-Memory Database & Persistence Isolation

The system MUST support SQLite file and in-memory isolated databases for testing and simulation.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• In-memory SQLite database connections enforce StaticPool thread safety.

13.2.4 WISACS-SYS-006: PostgreSQL Dialect Schema Support

The system MUST support PostGIS extensions and dialect-aware schema creation.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Schema creation creates PostGIS extension on PostgreSQL engines.

13.2.5 WISACS-SYS-002: Location Data for Client Display

The system MUST expose validated location data for clients to show responders, devices, observations, and incident operating areas on a map.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Coordinates outside WGS84 bounds are rejected and valid demo coordinates are returned.

13.2.6 WISACS-SYS-003: Advisory Interoperability Only

The V1 system MUST NOT automatically bridge live networks; it MAY recommend candidate interoperability actions for human review.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• No OpenAPI operation activates a bridge and all computed outputs are advisory records.

13.3 Deployment Requirements

13.3.1 WISACS-DEPLOY-001: Render Deployment Protocol

The system MUST parse environment configuration variables for Render hosted deployment environments.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Environment variables WISACS_* and DATABASE_URL parse into typed Settings instances.

13.3.2 WISACS-DEPLOY-002: Hosted PostgreSQL Database Support

The system MUST support production PostgreSQL databases over encrypted TLS connections.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• PostgreSQL connection URIs parse and connect with pool_pre_ping enabled.

13.3.3 WISACS-DEPLOY-003: Container & Process Integrity

The system MUST serve root documentation and landing pages directly from process routes.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Root process serves interactive documentation and visualization dashboards.

13.4 Ontology Requirements

13.4.1 WISACS-ONT-001: Core OWL 2 DL Domain Ontology

The system MUST declare and parse a formal OWL 2 DL domain ontology defining upper-level concepts, spatial entities, responder roles, networks, and radio equipment.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Core OWL 2 DL ontology parses cleanly into graph memory with defined upper classes.

13.4.2 WISACS-ONT-003: SPARQL 1.1 Query Engine

The system MUST provide a SPARQL 1.1 graph query engine supporting SELECT and ASK graph pattern matching against operational incident subgraphs.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• SPARQL queries execute against incident subgraphs and return bound variables.

13.4.3 WISACS-ONT-007: Versioned Local Ontology Alignment Registry

The system MUST load ontology alignment modules only from a bounded, versioned, hash-pinned local registry.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Only registry-approved local Turtle modules with matching hashes, ontology headers, source provenance, and WiSACS-core imports are loaded.
• Remote ontology resources are never retrieved at runtime, and malformed, oversized, non-regular, or excessive-triple artifacts fail closed.

13.4.4 WISACS-ONT-005: Cognitive Linguistics 5D Modeling

The system SHOULD structure operational situational awareness using Cognitive Linguistics concepts (Things, Places, Paths, Actions, Causes) across People, Equipment, Space, Time, and RF dimensions.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Entities, places, paths, actions, and causes are represented natively in the graph.

13.4.5 WISACS-ONT-004: Reasoning-Based Interoperability Rules

The system SHOULD infer candidate gateway bridges, shared IP paths, and voice channels using SPARQL CONSTRUCT reasoning rules.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• SPARQL CONSTRUCT reasoning rules derive candidate interop recommendations.

13.4.6 WISACS-ONT-006: Natural Language Question-Answering

The system MAY provide natural language question-answering interfaces that map operator questions to executable SPARQL queries.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Supported operator questions resolve only to allowlisted ontology identifiers, compile into incident-scoped SPARQL, and return current evidence.
• When scenario time is supplied, evidence represents that non-mutating temporal snapshot rather than the completed fixture.
• Authenticated explicit LLM requests fall back to deterministic local grounding only when model execution is disabled, unavailable, or fails at the provider boundary.
• Ambiguous questions request clarification without compiling a query, lifting an incident graph, or returning evidence.
• Unsupported questions abstain without compiling a query, lifting an incident graph, or returning evidence.
• Ontology modules not approved for QA cannot add executable natural-language classes, properties, labels, or aliases.

13.4.7 WISACS-ONT-002: Operational Semantic Lifting

The system MUST lift relational database models and operational records into subject-predicate-object RDF triples.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• SQL database entities lift into valid RDF triples in incident graph.
• A requested scenario-relative snapshot lifts only due entities, relationships, and events without mutating relational inventory.
• Scenario Network status is active only when a due attachment connects the Network to a due responder-assigned device.

13.5 Security Requirements

13.5.1 WISACS-SEC-001: PBKDF2 Password Hashing

The system MUST store user passwords hashed with PBKDF2-HMAC-SHA256 and constant-time password verification.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Passwords are hashed using PBKDF2-HMAC-SHA256 with 600k iterations and verified in constant time.

13.5.2 WISACS-SEC-002: Bearer Token Authentication

The system MUST issue cryptographically signed JWT bearer tokens for authenticated API sessions.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Authenticated login issues signed JWT bearer tokens that pass signature verification.

13.5.3 WISACS-SEC-004: CORS Policy Control

The system MUST restrict cross-origin resource sharing unless explicit origins are configured.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• CORS headers are restricted to explicitly configured origins.

13.5.4 WISACS-SEC-003: Incident Boundary Isolation

The system MUST isolate incident inventories and resource access strictly by authorized user membership.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Users without incident membership cannot read or mutate incident data.
• Authenticated direct SELECT and ASK execute against a request-local graph containing the ontology and, when selected, only the authorized temporal incident; remote SERVICE clauses are rejected.

13.6 Data Invariants Requirements

13.6.1 WISACS-DATA-002: Strict Cascade Delete Invariants

The system MUST enforce strict foreign key cascade deletions across all incident sub-resources.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Deleting an incident automatically purges all child responders, devices, networks, and events.

13.6.2 WISACS-DATA-001: SQLite Isolation Invariant

The system MUST support complete database table schema drops and reset isolations.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Database reset purges all tables cleanly.

13.6.3 WISACS-DATA-004: Deterministic Scenario Import

The system MUST support deterministic scenario fixtures for disaster disruption and spectrum congestion simulations.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Validated JSON scenario files import deterministically with structured actors and RF observations.
• Simulation fixtures validate responder trajectories, inventory availability, and scenario duration before playback.

13.6.4 WISACS-DATA-003: OpenStreetMap Tile Caching

The system MUST cache OpenStreetMap tiles locally and enforce strict bounded tile request proxying.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• OSM tile requests are cached and bounded within memory/tile count limits.

13.7 SCA Integration Requirements

13.7.1 WISACS-SCA-002: Real-Time Semantic WebSocket Triple Broadcast

The system MUST stream real-time JSON-LD RDF triple deltas over incident WebSockets.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Triple additions broadcast JSON-LD triple deltas to connected clients.

13.7.2 WISACS-SCA-003: Old Montreal 3D Ray-Tracing Targets

The system MUST parse 3D footprint vector geometry for Place Victoria target building simulations.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Overpass 3D vector geometry returns valid centroid coordinates and building footprint radii.

13.7.3 WISACS-SCA-001: SCA Compliant Metadata Descriptors

The system MUST generate draft SCA-compliant component descriptors for field devices and radios.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• Devices generate draft SCA component descriptors containing ports, capabilities, and properties.

13.8 Traceability Requirements

13.8.1 WISACS-TRACE-001: Automated Traceability Matrix

The system MUST generate an automated traceability matrix verifying implementation and verification evidence for all normative requirements.

Profiles: simulation, production. Lifecycle: approved. Implementation status: implemented.

Rationale: Defines the repository-maintained WiSACS contract.

Acceptance criteria:

• AST generator produces complete traceability matrix matching requirements to code and tests.

14 Generated API Contract

15 Generated Data Model

16 Generated Event Contract

Message schema: EventMessage.

16.1 Persisted audit event types

16.2 WebSocket message event types

17 Generated Profiles and Limitations

17.1 Simulation Profile

• In-process WebSocket delivery is at-most-once and is not shared across workers.
• Demo identities and scenario mutation exist only when explicitly enabled.
• Recommendations are advisory and never activate live network bridging.

17.2 Production Profile

• Demo identities and demo scenario mutation are forbidden.
• The development signing secret is forbidden.
• Federated identity, durable event fanout, retention, and backup policy require deployment-specific controls.

18 Generated Public and Authenticated Surface

18.1 Explicit Public HTTP Allowlist

18.2 OpenAPI Operations

18.3 WebSocket

/api/v1/ws/incidents/{incident_id} is authenticated.

19 Generated Scenario Catalog

20 Generated Configuration Reference

21 Generated Deployment Reference

The Render blueprint declares 1 service(s) and 1 database(s). Docker Compose declares 1 local service(s). The Makefile exposes 22 executable workflow target(s): audit, backend-test, check-frontend-godot, coverage, db-current, db-upgrade, demo, docs, docs-all, docs-pdf, docs-review, docs-review-tex, format-check, lint, package, run-api, run-frontend-godot, spec-check, spec-generate, test, tool-test, traceability.

22 Generated Implementation Map

Generated; do not edit.

22.1 WISACS-API-004 Implementation

• python wisacs_api.api.deps:require_contributor — Implementation target in require_contributor.
• openapi POST /api/v1/responders — Responder creation operation.

22.2 WISACS-API-008 Implementation

• python wisacs_api.api.deps:require_contributor — Implementation target in require_contributor.

22.3 WISACS-SYS-004 Implementation

• python wisacs_api.api.routes:_contract — Implementation target in _contract.

22.4 WISACS-API-001 Implementation

• python wisacs_api.api.routes:health — Implementation target in health.
• openapi GET /api/v1/health — API health operation.
• openapi GET /ready — Hosted readiness operation.

22.5 WISACS-API-002 Implementation

• python wisacs_api.api.routes:login — Implementation target in login.
• openapi POST /api/v1/auth/login — Login operation.
• openapi GET /api/v1/auth/me — Current user operation.

22.6 WISACS-API-003 Implementation

• python wisacs_api.api.routes:list_incidents — Implementation target in list_incidents.
• openapi GET /api/v1/incidents — Incident list operation.

22.7 WISACS-DEPLOY-001 Implementation

• python wisacs_api.core.config:Settings — Implementation target in Settings.

22.8 WISACS-ONT-001 Implementation

• python wisacs_api.core.graph:WiSACSGraphStore — Implementation target in WiSACSGraphStore.
• openapi GET /api/v1/ontology/classes — Ontology taxonomy operation.

22.9 WISACS-ONT-003 Implementation

• python wisacs_api.core.graph:WiSACSGraphStore — Implementation target in WiSACSGraphStore.
• openapi POST /api/v1/ontology/sparql — SPARQL query operation.

22.10 WISACS-ONT-007 Implementation

• python wisacs_api.core.ontology_registry:load_ontology_registry — Implementation target in load_ontology_registry.

22.11 WISACS-SEC-001 Implementation

• python wisacs_api.core.security:hash_password — Implementation target in hash_password.
• openapi POST /api/v1/auth/login — Password authenticated login operation.
• openapi GET /api/v1/auth/me — Authenticated identity operation.

22.12 WISACS-SEC-002 Implementation

• python wisacs_api.core.security:create_access_token — Implementation target in create_access_token.

22.13 WISACS-SYS-001 Implementation

• python wisacs_api.db.models:Incident — Implementation target in Incident.
• openapi GET /api/v1/incidents — Authenticated incident inventory.

22.14 WISACS-DATA-002 Implementation

• python wisacs_api.db.models:Responder — Implementation target in Responder.

22.15 WISACS-SYS-005 Implementation

• python wisacs_api.db.session:configure_database — Implementation target in configure_database.

22.16 WISACS-DEPLOY-002 Implementation

• python wisacs_api.db.session:configure_database — Implementation target in configure_database.

22.17 WISACS-SYS-006 Implementation

• python wisacs_api.db.session:create_schema — Implementation target in create_schema.

22.18 WISACS-DATA-001 Implementation

• python wisacs_api.db.session:drop_schema — Implementation target in drop_schema.

22.19 WISACS-ONT-005 Implementation

• python wisacs_api.domain.cognitive:Place — Implementation target in Place.

22.20 WISACS-DATA-004 Implementation

• python wisacs_api.domain.scenarios:load_scenario — Implementation target in load_scenario.
• openapi GET /api/v1/scenarios — Scenario catalog operation.
• openapi POST /api/v1/imports/demo-scenario — Demo import operation.

22.21 WISACS-API-007 Implementation

• python wisacs_api.domain.schemas:ApiModel — Implementation target in ApiModel.

22.22 WISACS-SYS-002 Implementation

• python wisacs_api.domain.schemas:IncidentBase — Implementation target in IncidentBase.
• openapi GET /api/v1/visualization/old-montreal/target-building — Authenticated target building image.

22.23 WISACS-SEC-004 Implementation

• python wisacs_api.main:create_app — Implementation target in create_app.

22.24 WISACS-DEPLOY-003 Implementation

• python wisacs_api.main:create_app — Implementation target in create_app.

22.25 WISACS-API-005 Implementation

• python wisacs_api.main:create_contract_app — Implementation target in create_contract_app.

22.26 WISACS-SYS-003 Implementation

• python wisacs_api.main:create_contract_app — Implementation target in create_contract_app.
• openapi GET /api/v1/interop/recommendations — Authenticated interop recommendations endpoint.
• openapi POST /api/v1/interop/recommendations/recompute — Authenticated interop recommendation recomputation.

22.27 WISACS-SEC-003 Implementation

• python wisacs_api.services.access:can_access_incident — Implementation target in can_access_incident.
• openapi GET /api/v1/interop/recommendations — Boundary isolated interop recommendations endpoint.
• openapi POST /api/v1/interop/recommendations/recompute — Boundary isolated recompute operation.
• openapi POST /api/v1/ontology/sparql — Boundary isolated request-local SPARQL operation.

22.28 WISACS-SCA-002 Implementation

• python wisacs_api.services.events:EventBroker.publish_semantic_triples — Implementation target in EventBroker.publish_semantic_triples.
• openapi GET /api/v1/sca/descriptors/{device_id} — Semantic triple streaming operation.

22.29 WISACS-ONT-004 Implementation

• python wisacs_api.services.interop_reasoning:run_ontology_reasoning — Implementation target in run_ontology_reasoning.

22.30 WISACS-DATA-003 Implementation

• python wisacs_api.services.map_tiles:download_osm_map — Implementation target in download_osm_map.

22.31 WISACS-SCA-003 Implementation

• python wisacs_api.services.old_montreal:get_place_victoria_target_building — Implementation target in get_place_victoria_target_building.

22.32 WISACS-ONT-006 Implementation

• python wisacs_api.services.qa_engine:answer_natural_language_question — Implementation target in answer_natural_language_question.
• openapi POST /api/v1/ontology/qa — Natural language QA operation.

22.33 WISACS-API-006 Implementation

• python wisacs_api.services.rate_limit:SlidingWindowRateLimiter — Implementation target in SlidingWindowRateLimiter.

22.34 WISACS-SCA-001 Implementation

• python wisacs_api.services.sca:build_sca_descriptor — Implementation target in build_sca_descriptor.
• openapi GET /api/v1/devices — Field device list operation.
• openapi GET /api/v1/sca/descriptors/{device_id} — SCA descriptor operation.

22.35 WISACS-ONT-002 Implementation

• python wisacs_api.services.semantic_lifting:lift_incident_to_graph — Implementation target in lift_incident_to_graph.
• openapi POST /api/v1/ontology/lift/{incident_id} — Semantic lifting operation.

22.36 WISACS-TRACE-001 Implementation

• python specification.catalog:_load_requirements_from_ast — Implementation target in _load_requirements_from_ast.

23 Generated Verification Map

Generated; do not edit.

23.1 WISACS-API-004 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.2 WISACS-API-008 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.3 WISACS-SYS-004 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.4 WISACS-API-001 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.5 WISACS-API-002 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.6 WISACS-API-003 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.7 WISACS-DEPLOY-001 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.8 WISACS-ONT-001 Verification

• automated backend/tests/test_ontology.py::test_core_owl_ontology_representation — Verifies OWL 2 DL ontology class hierarchy.

23.9 WISACS-ONT-003 Verification

• automated backend/tests/test_ontology.py::test_sparql_query_endpoint_execution — Verifies SPARQL 1.1 graph query engine.
• automated backend/tests/test_temporal_sparql_api.py::test_temporal_sparql_select_and_ask_use_a_local_temporal_snapshot — Verifies authenticated SELECT and ASK execute against the requested temporal incident snapshot.
• automated backend/tests/test_temporal_sparql_api.py::test_temporal_sparql_cannot_read_another_global_incident_graph — Verifies direct SPARQL cannot cross the selected incident boundary.

23.10 WISACS-ONT-007 Verification

• automated backend/tests/test_ontology_registry.py::test_registry_loads_shipped_module_and_deterministic_selections — Verifies the shipped local registry, source ledger, module ordering, and QA visibility selection.
• automated backend/tests/test_ontology_registry.py::test_registry_refuses_oversized_regular_files_before_parsing — Verifies ontology artifacts fail closed at configured byte bounds before parsing.
• automated backend/tests/test_ontology_registry.py::test_turtle_parser_stops_during_materialization — Verifies Turtle parsing stops at the configured statement bound.

23.11 WISACS-SEC-001 Verification

• automated backend/tests/test_api.py::test_login_is_rate_limited — Verifies security and authentication mechanics.

23.12 WISACS-SEC-002 Verification

• automated backend/tests/test_api.py::test_login_is_rate_limited — Verifies security and authentication mechanics.

23.13 WISACS-SYS-001 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.14 WISACS-DATA-002 Verification

• automated backend/tests/test_api.py::test_demo_import_populates_inventory_and_recommendations — Verifies database schema and inventory invariants.

23.15 WISACS-SYS-005 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.16 WISACS-DEPLOY-002 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.17 WISACS-SYS-006 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.18 WISACS-DATA-001 Verification

• automated backend/tests/test_api.py::test_demo_import_populates_inventory_and_recommendations — Verifies database schema and inventory invariants.

23.19 WISACS-ONT-005 Verification

• automated backend/tests/test_ontology.py::test_cognitive_linguistics_5d_modeling — Verifies 5D situational awareness model.

23.20 WISACS-DATA-004 Verification

• automated backend/tests/test_api.py::test_demo_import_populates_inventory_and_recommendations — Verifies database schema and inventory invariants.

23.21 WISACS-API-007 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.22 WISACS-SYS-002 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.23 WISACS-SEC-004 Verification

• automated backend/tests/test_api.py::test_login_is_rate_limited — Verifies security and authentication mechanics.

23.24 WISACS-DEPLOY-003 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.25 WISACS-API-005 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.26 WISACS-SYS-003 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.27 WISACS-SEC-003 Verification

• automated backend/tests/test_temporal_sparql_api.py::test_direct_sparql_without_incident_cannot_read_global_incident_graph — Verifies ontology-only direct queries cannot see process-global incident graphs.
• automated backend/tests/test_temporal_sparql_api.py::test_temporal_sparql_enforces_incident_membership — Verifies direct SPARQL requires selected-incident membership.
• automated backend/tests/test_temporal_sparql_api.py::test_temporal_sparql_cannot_read_another_global_incident_graph — Verifies a direct query cannot read a different named incident graph.

23.28 WISACS-SCA-002 Verification

• automated backend/tests/test_api.py::test_sca_descriptor_for_gateway — Verifies SCA component descriptors.

23.29 WISACS-ONT-004 Verification

• automated backend/tests/test_ontology.py::test_operational_semantic_lifting — Verifies SPARQL CONSTRUCT reasoning rules.

23.30 WISACS-DATA-003 Verification

• automated backend/tests/test_api.py::test_demo_import_populates_inventory_and_recommendations — Verifies database schema and inventory invariants.

23.31 WISACS-SCA-003 Verification

• automated backend/tests/test_api.py::test_sca_descriptor_for_gateway — Verifies SCA component descriptors.

23.32 WISACS-ONT-006 Verification

• automated backend/tests/test_qa_paraphrase_evaluation.py::test_authenticated_hybrid_paraphrases_execute_against_harbor_evidence — Verifies grounded paraphrases compile and execute against authorized incident evidence.
• automated backend/tests/test_qa_hybrid_engine.py::test_ambiguous_communications_assets_requires_clarification_before_execution — Verifies ambiguous grounding requests clarification without query execution or graph lifting.
• automated backend/tests/test_llm_qa_planner.py::test_explicit_llm_clarification_stops_before_lifting — Verifies structured LLM ambiguity returns deterministic clarification without graph execution.
• automated backend/tests/test_qa_hybrid_engine.py::test_out_of_domain_weather_question_abstains_before_execution — Verifies unsupported language abstains without query execution or graph lifting.
• automated backend/tests/test_llm_qa_planner.py::test_unavailable_llm_uses_safe_local_grounding_and_execution — Verifies availability-only LLM failures use deterministic local grounding.
• automated backend/tests/test_temporal_scenario_qa.py::test_disabled_explicit_llm_uses_local_grounding_for_old_montreal_snapshot — Verifies authenticated explicit LLM fallback returns temporal Old Montreal evidence.
• automated backend/tests/test_qa_hybrid_llm_comparison.py::test_comparison_catalog_cases_match_local_grounding_and_classification — Compares 20 bounded hybrid and structured-LLM plans without provider calls, including strict and answer-sufficient matches.
• automated backend/tests/test_qa_hybrid_engine.py::test_runtime_catalog_isolated_from_default_graph_tbox_metadata — Verifies non-QA-visible default-graph ontology metadata cannot expand executable natural-language vocabulary.

23.33 WISACS-API-006 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

23.34 WISACS-SCA-001 Verification

• automated backend/tests/test_api.py::test_sca_descriptor_for_gateway — Verifies SCA component descriptors.

23.35 WISACS-ONT-002 Verification

• automated backend/tests/test_ontology.py::test_operational_semantic_lifting — Verifies database to RDF triple lifting.
• automated backend/tests/test_temporal_scenario_qa.py::test_temporal_network_statuses_are_derived_without_mutating_inventory — Verifies scenario Network status is derived from current responder use without mutating inventory.
• automated backend/tests/test_temporal_scenario_qa.py::test_temporal_lift_excludes_future_attachment_derived_relationships — Verifies future attachments cannot produce Network status or relationship facts early.

23.36 WISACS-TRACE-001 Verification

• automated backend/tests/test_api.py::test_health_and_ready — Verifies API routes and system contracts.

24 Generated Traceability Matrix