Software Classification & Safety Case — Project VELA

Status: DESIGNED/ROADMAPPED unless marked IMPLEMENTED. The core investigation stack (LangGraph agents + Neo4j + Qdrant + 3 FastMCP servers + FastAPI) is implemented and tested. The safety-case controls, invariants, and verifying tests named below are a separate surface: some are IMPLEMENTED with passing tests, others remain design commitments whose evidence is pending. This document is a living safety case: it states the argument and attaches evidence against each claim as the controls land. Implemented ≠ independently audited or certified.

Last reviewed: (owner to date)

Owner: SKOPAQ AI Pvt Ltd. Scope: VELA v1 — ground-segment, advisory-only anomaly-investigation co-pilot. Sibling docs: SECURITY.md, COMPLIANCE-ROADMAP.md, DATA-HANDLING.md, docs/assurance/hazard-analysis.md, docs/assurance/rtm.csv, docs/design/06-TEST-PLAN.md, docs/design/02-ARCHITECTURE.md, CLAUDE.md.

1. What VELA is (for classification purposes)

Property	Value
Segment	Ground only. Runs in the operations centre, never onboard.
Function	Detects telemetry deviations; produces a cited root-cause narrative + a drafted recovery procedure.
Authority	Advisory only. Zero commanding authority in v1. A human reads the draft and executes (or not) through the existing, separate commanding chain.
Coupling to spacecraft	None direct. VELA consumes telemetry (read) and command history (read). It constructs no telecommands (audit invariant #3, grep-guarded in CI).
Failure effect	An unhelpful, wrong, or misleading recommendation to a human. Not an action on the spacecraft.

The safety-relevant consequence of any VELA failure is mediated entirely by a human operator and the unchanged commanding chain. VELA cannot, by construction, be the proximate cause of a spacecraft action. This is the load-bearing fact for classification.

2. Classification argument

Claim: VELA is equivalent to NASA NPR 7150.2 Class E (ground-based, non-flight, advisory), sitting at the E/D boundary only because it informs operational decisions on a real asset.

NPR 7150.2 Classes A–C are flight and mission-critical software. Class D covers non-safety-critical flight-adjacent or significant ground software; Class E covers general-purpose ground/analysis tools whose failure does not directly endanger a mission. VELA’s failure mode — a bad recommendation to a human who independently decides and commands — places it in Class E. We acknowledge the E/D boundary honestly: because VELA’s output can influence a real anomaly-recovery decision on an operational satellite, we choose to hold it to a standard stricter than a pure Class E throwaway analysis script by borrowing the assurance disciplines in §3, without claiming any higher NPR class.

This is our own reasoned classification, not an external determination. It is not a certification and confers no compliance status.

Regimes that do NOT bind VELA

Regime	Why it does not apply
DO-178C	Airborne/flight software certification; VELA is ground software with no flight execution path.
NASA NPR 7150.2 Class A–C	Reserved for flight and mission-/safety-critical software that directly controls or endangers the vehicle; VELA has zero control authority.
MISRA C	A C-language coding standard for embedded/safety systems; VELA is Python 3.12 + TypeScript, not embedded C.
JPL Power-of-10	Rules for flight C with bounded loops/no dynamic allocation on constrained real-time targets; wrong language and wrong runtime for an LLM agent stack.
ECSS milestone review boards (PDR/CDR/QR)	Bind space-system/flight-segment procurements under an ECSS contract; VELA is a commercial ground tool, not delivered under an ECSS project baseline.

None of the above is invoked, claimed, or implied anywhere in VELA’s marketing or docs.

Spirit we DO borrow (deliberately, even though unbound)

Borrowed discipline	Where it lives in VELA	Label
Requirements traceability (DO-178C / NPR spirit)	`docs/assurance/rtm.csv` links each PRD requirement/invariant → design → test.	DESIGNED
Independent V&V of the safety-critical checker	The citation-integrity checker (`vela/audit/citation_check.py`) is treated as the one component whose correctness we verify adversarially and independently of the agents it guards.	DESIGNED
Configuration management	Model IDs, endpoints, thresholds in `config/.yaml`; prompts versioned in `vela/agents/prompts/.md` and reviewed like code; content-addressed (sha256) `DocSection` citations.	DESIGNED
Hazard analysis	`docs/assurance/hazard-analysis.md` enumerates the ways VELA could mislead or (impossibly-by-design) command, and maps each to a control.	DESIGNED

We borrow the spirit — trace, verify the critical piece, control configuration, analyse hazards — without adopting the flight-certification apparatus that does not fit a ground advisory tool.

3. Assurance case (Claim–Argument–Evidence)

Notation: C = claim, A = argument (why the claim holds), E = evidence (what proves it). Evidence status is one of IMPLEMENTED / DESIGNED / ROADMAPPED / ASPIRATIONAL / PENDING (design exists, artifact not yet built). Pre-build, nearly all evidence is PENDING against a DESIGNED control — stated so no reader mistakes intent for proof.

C0 — Top claim

VELA cannot cause a spacecraft to take a harmful action, and cannot mislead an operator without leaving an auditable, blockable trail.

Two independent halves: (a) no-action — VELA has no path to act on the spacecraft; and (b) no-silent-deception — any misleading output is either blocked before release or is fully reconstructable after the fact. C0 holds if the sub-claims below hold.

C0  VELA cannot cause a harmful spacecraft action, nor mislead without an auditable/blockable trail
├── C1  No VELA code path constructs or transmits a telecommand           (audit invariant #3)
├── C2  No narrative asserts a telemetry value not actually returned       (audit invariant #1)
├── C3  Every narrative/procedure claim carries a resolvable citation      (audit invariant #2)
├── C4  A human must approve before any procedure draft is released        (interrupt gate)
└── C5  Every tool call + hypothesis transition is persisted per case      (audit invariant #4)

C1 — No commanding path (the “no-action” half of C0)

A: VELA reads telemetry and command history only. No module constructs, formats, wraps, or transmits a telecommand; the Yamcs adapter exposes subscription/replay/command-history reads, not command issuance. A CI grep guard fails the build on any command-issuance surface, and CLAUDE.md guardrail #1 forbids adding, wrapping, or stubbing one.
E: CI grep-guard job (per 06-TEST-PLAN.md “Guardrail tests”); CLAUDE.md §Hard guardrails #1; architecture invariant #3 in docs/design/02-ARCHITECTURE.md. Status: DESIGNED / evidence PENDING (CI job not yet built). This is the strongest leg of the case: it is a structural impossibility enforced by a deterministic test, not a behavioural hope about an LLM.

C2 — No fabricated telemetry values

A: Agents reach data only through the three MCP servers (import-linter forbids vela/agents/ → {neo4j, qdrant, stores}), so any telemetry value in a narrative must trace to an MCP telemetry call made in that investigation. Values with no such call are flagged, not emitted.
E: Import-linter rule + MCP-boundary tests (06-TEST-PLAN.md); hostile-input suite asserts UNGROUNDED/insufficient rather than fabrication on empty/gappy/contradictory inputs. Status: DESIGNED / evidence PENDING.

C3 — Citation integrity (the load-bearing leg of the “no-deception” half)

A: Every narrative claim and every procedure step carries a Citation resolvable against the KG/Qdrant via content-addressed (sha256) DocSection refs. An ungroundable claim emits UNGROUNDED, which blocks release of the draft rather than softening the language. The checker (vela/audit/citation_check.py) is deterministic and independently V&V’d (§2 borrowed disciplines).
E: citation_check.py unit + adversarial suite; golden-case eval asserts 100% citation integrity at every tier; 06-TEST-PLAN.md Gate 2 marks any hallucinated reference as a failed run regardless of other scores. Status: DESIGNED / evidence PENDING.
Severity note: citation integrity is 100% at every PRD tier (0/1/2). One hallucinated reference presented before an anomaly review board is a sev-1 incident (docs/policies/incident-response-citation-integrity.md). There is no acceptable non-zero rate.

C4 — Human-in-the-loop approval gate

A: Procedure-draft release pauses the LangGraph at a first-class interrupt(); a human (reviewer/approver RBAC role) must resume from that exact checkpoint before any draft leaves VELA. Low-confidence binding escalations use the same mechanism. Approval is graph structure, not a UI convention that could be bypassed. VELA never closes the loop to the spacecraft regardless.
E: LangGraph interrupt() gate in docs/design/02-ARCHITECTURE.md §3 Runtime commitments; RBAC roles operator/reviewer/admin in docs/policies/rbac.md. Status: DESIGNED / evidence PENDING.

C5 — Full auditable trail

A: Every tool call and every hypothesis transition is persisted per investigation, backed by OpenTelemetry traces spanning MCP calls and agent nodes. tenant_id + satellite_id are mandatory on every MCP request and audit record from day one. Durable Postgres checkpointing enables time-travel replay of any investigation — the anomaly-review-board forensic artifact.
E: Audit invariant #4; OTel trace backbone and replay feature in 02-ARCHITECTURE.md; retention in docs/policies/audit-log-retention.md. Status: DESIGNED / evidence PENDING.

Assurance-case summary

Sub-claim	Anchored invariant	Primary enforcement	Evidence status
C1 no-commanding	#3	CI grep guard (deterministic)	DESIGNED · PENDING
C2 no fabricated telemetry	#1	MCP boundary + import-linter	DESIGNED · PENDING
C3 citation integrity	#2	`citation_check.py` + golden eval	DESIGNED · PENDING
C4 human approval	—	LangGraph `interrupt()` + RBAC	DESIGNED · PENDING
C5 audit trail	#4	OTel + Postgres checkpoint	DESIGNED · PENDING

4. Defeaters (honest gaps that could break the case)

An assurance case is only as good as the challenges it survives. Known open defeaters, pre-build:

#	Defeater	Current answer	Status
D1	CI grep guard is a heuristic; a novel command surface could evade it.	Guard is a floor, not a ceiling; adapter is read-only by construction and reviewed. Threat: false confidence.	OPEN — harden grep + add allowlist review
D2	Citation resolves but is irrelevant to the claim (semantically wrong).	`citation_check` verifies resolvability, not relevance; golden-case LLM-judge + human spot-check target relevance. Residual risk acknowledged.	OPEN — partial mitigation only
D3	Operator over-trusts advisory output (“automation complacency”).	Advisory framing, confidence/`insufficient` verdicts surfaced, shadow-mode pilots before live. Human-factors risk, not fully controllable in software.	OPEN — process control
D4	Airgap mode uses a weaker local model (Qwen) → lower reasoning quality.	Same invariants enforced in both modes; golden eval runs in `cloud` and `airgap`; quality thresholds per tier.	DESIGNED — both-mode CI
D5	None of the above is proven yet — it is all design.	This document and the RTM exist precisely so evidence attaches against named claims as the build proceeds.	PRE-BUILD reality

5. How this document stays alive

Re-review at each of the three V&V gates in docs/design/06-TEST-PLAN.md (public benchmark → fault-injection sim → shadow pilot), flipping evidence rows from PENDING to a dated artifact link.
Any change to an audit invariant, the citation checker, or the commanding-guard requires an update here and in docs/assurance/rtm.csv in the same PR.
A confirmed citation-integrity breach triggers incident-response-citation-integrity.md and a mandatory review of C3.
Nothing in this file may be cited externally as a certification. The correct external phrasing is “classification argued as NPR 7150.2 Class E-equivalent; assurance case designed, evidence in progress” — never “certified”, “compliant”, or “audited”.