AMPEL360 is a unified digital lifecycle architecture for advanced aerospace systems

AEROSPACE MODELS, PLATFORMS, EVOLUTION, LEDGERS (360°)

AMPEL360 is a unified digital lifecycle architecture for advanced aerospace systems (AIRT / SPACET) that binds four foundational pillars into a single certifiable, auditable, continuously evolving knowledge system.

Domain scope. Advanced Air Transport (AIRT) and Space Transport (SPACET) programs governed through tailored ATA chapter structures spanning ATA 00–116, integrated into the OPT-INS framework and exposed through role-routed portal entry points (AoR/STK).

Principle. Aerospace tailoring is expressed as controlled allocations and applicability rules, not as ad-hoc folder sprawl.

Representational layer (governed assets).

• Architecture models — SysML/MBSE under STK_SE governance
• Digital twins — ATA 101 catalog, fidelity tiers, baseline control
• AI/ML models — ATA 90 registry, lifecycle governance under STK_AI
• Schemas / ontologies / SSOT — ATA 91 under STK_DAB
• Connectivity graphs — ATA 92 wiring/connectivity packages under STK_DAB, with STK_PHM dependencies

Rule. Every model is configuration-controlled, version-tracked, trace-linked, and evidence-addressable.

Execution infrastructure (deterministic delivery).

• CAXS Portal (CA360º) — role-routed entry points, roadmap orchestration, task-to-artifact execution spine
• On-board compute platforms — ATA 42 IMA/compute, partitioning, cyber-hardened under STK_CY with STK_DAB implementation dependencies
• Off-board infrastructure — ATA 80–89: spaceport services, GSE, test rigs, digital services
• SIL/HIL/PIL environments — ATA 103–105 automation benches
• PLC validators — process logic controllers enforcing nomenclature, identifiers, schema integrity, and evidence closure (PR-blocking)

Rule. Platform outputs are only valid when produced under validator-gated CI/PR control.

Temporal governance (controlled change, not drift).

• Uncertainty node resolution — predefined unknowns reduced via structured tasks aligned to KNOTS (K01..K14)
• Technology integration pathways — new capability introduced through reserved/controlled extension points
• Best-practice condensation — validated patterns crystallize into reusable knowledge capsules
• Lifecycle continuity — from design through certification, operations, MRO, and circular return flows (incl. ATA 85)
• Change impact analytics (ATA 97) — deterministic propagation of effects across wiring/config/trace

Rule. Evolution is governed by CM and evidenced by traceable impact and closure artifacts.

Evidence and trust fabric (audit-grade continuity).

• Knowledge ledger — immutable artifact addressing (repo path + sha256 + optional commit), typed relations, approval states
• Traceability graph (ATA 93) — REQ ↔ DESIGN ↔ V&V ↔ OPS linkage with audit queries
• Digital Product Passport (ATA 94) — provenance, materials, lifecycle identity
• SBOM/BOM exports (ATA 95) — dependency integrity for SW/HW/Model compositions
• Signed release packs (ATA 98) — manifests, exports, PR-blocking compliance evidence
• Master registers (ATA 99) — golden records and controlled vocabulary datasets

Rule. Engineering work becomes certifiable only when it is ledger-addressed, trace-linked, and release-packaged.

The "360" signifies full-circle lifecycle closure:

DESIGN → BUILD → VERIFY → CERTIFY → OPERATE → SUSTAIN → EVOLVE → (return)
   ↑                                                              ↓
   └──────────────── Knowledge Ledger Continuity ─────────────────┘

Every artifact produced at any phase feeds the ledger, reduces uncertainty, and is reusable across cycles—within the same vehicle, across variants, or across programs.

The CAXS Portal (CA360º) organizes all navigation and work execution around AoR entry points (STKs) and stakeholder roles, driving delivery through roadmaps that decompose into task → artifact generation → evidence closure.

Each portal entry point corresponds to an accountable AoR (STK) and exposes a role-oriented view of:

• Scope (what this AoR owns)
• Canonical ATA roots / domains it governs
• Active roadmaps and open uncertainty nodes
• Mandatory artifacts, evidence, and release gates

A Roadmap is a structured plan that:

• Is identified (ID + scope + owner AoR)
• Decomposes into tasks aligned to KNOTS (K01..K14)
• Produces controlled artifacts (NKU implicit) using the v6.0 naming standard
• Requires evidence outputs (validator logs, link-check logs, exception diffs, test results)
• Aggregates results into a knowledge ledger for audit, reuse, and release packaging

The portal treats key unknowns as pre-defined uncertainty nodes that are actively reduced by work:

• Each node has a measurable "unknown → known" target
• Each task must produce artifacts that reduce uncertainty
• Successful closure is recorded as evidence-backed ledger entries that become reusable "best-practice capsules"

This "condenses" activity by eliminating redundant effort and converging teams onto canonical patterns, validated schemas, verified interfaces, and repeatable evidence packs.

For any roadmap item, the portal enforces this spine:

1. Select entry point (AoR) → determines authority, templates, and gates
2. Bind to an uncertainty node + KNOT (K01..K14) → defines permitted actions and evidence needs
3. Generate/modify artifacts under v6.0 nomenclature → NKU implicit
4. Run PLC validators and link-check → PR-blocking evidence
5. Register exceptions (if any) → CM-controlled register diff included
6. Update ledger (paths + hashes + relations) → audit-ready trace graph
7. Package release (signed manifests / export packs) → certification/ops readiness reuse

This portal model provides:

• Role-correct navigation (stakeholder-specific, AoR-accountable)
• Enforceable governance (validators, CI gates, controlled KNOTS)
• Traceable delivery (task → artifact → evidence → release)
• Accelerated integration of new technology through reusable, validated knowledge capsules

Each AoR Portal is treated as a role-routed product surface with a standard feature catalog and a per-AoR MoSCoW selection. Features are defined once in a canonical catalog (SSOT), and each AoR contract declares which features are enabled, their defaults, required tooling/entitlements, and evidence/gates bindings.

For each aor_id, the portal contract defines:

1. Default workspace context — Default filters (OPT-INS axis, ATA set, LC phases, KNOTs, BLOCKs, CATEGORY/TYPE, STATUS), "Current slice" selector (Program/Family/Variant/Version/Node)
2. Feature set (MoSCoW) — must / should / could / wont referencing canonical feature IDs (F-01..F-20)
3. Tool Launchpad (TALF-aware) — Tool tiles with launch channel, entitlement group, license model/pool, preflight requirements, audit events
4. Execution surfaces — Kanban/backlog view bound to KNOTs + registries, task creation wizard from templates, evidence + signoff consoles
5. Assistant + communications — Portal-aware AI assistant capabilities (bounded by governance), communication threads bound to node/task/decision + signoff workflow
6. Backend bindings — Validators/gates invoked, indexers, trace/graph services, notification rules

The canonical feature catalog defines portal modules that an AoR can enable, organized by MoSCoW priority:

• F01 — Context Bar (Slice Selector)
• F02 — AoR Dashboard (Default Filters + KPIs)
• F03 — Registry-Driven Work Queue
• F04 — Kanban / Backlog mapped to KNOTs
• F05 — Artifact Generator (Template Wizard)
• F06 — Gates & Validator Console
• F07 — Evidence Console (Index + Attach + Hash)
• F08 — Signoff Console
• F09 — Tool Launchpad (TALF-aware)

• F10 — Portal-aware AI Assistant (Governance-bounded)
• F11 — Integrated Communication Threads
• F12 — Cross-AoR Handshake Panel
• F13 — Trace & Impact Viewer
• F14 — Notification Engine

• F15 — "Start Task" Execution Runner
• F16 — Integrated Meeting Capture
• F17 — Comparative Dashboards
• F18 — Offline/Edge Mode

• F19 — Auto-merge / Auto-signoff
• F20 — Unbounded external chatbots / uncontrolled tool plugins

The Tool Launchpad is a UI + policy surface with mandatory elements per tool tile:

• Tool identity — tool_id, version/class, owner AoR
• Launch — channel (VDI | HPC_job | container | web | api) + deep link
• Workspace bindings — mounts (repo node, exports, datasets, templates)
• Licensing — model + pool + checkout mode + constraints
• Preflight checks — validations before launching or starting a task
• Audit events — what must be recorded (launch/checkout/export)
• Failure modes — handling for "license unavailable" (block, retry, queue item, evidence log)

Backend engines (required for MUST features):

• Indexer/search over SSOT registries and artifact graph
• Gate/validator service (or CI bridge) exposing results to UI
• TALF service: entitlement check + license pool check + event logging
• Notification service (webhook/event log)

Frontend surfaces (required for MUST features):

• Context bar + AoR dashboard
• Work queue + Kanban (KNOT-mapped)
• Template wizard (artifact generation)
• Evidence console + signoff console
• Tool Launchpad

Assistants + communications (SHOULD):

• Assistant panel operating within templates and SSOT context
• Threaded communications bound to objects (task/node/signoff)

All 14 AoRs now have portal contracts defining their workspace context, feature sets, tool launchpads, and backend bindings:

• STK_CM — Configuration Management
• STK_PMO — Program Management Office
• STK_SE — Systems Engineering
• STK_DAB — Digital Applications & Blockchains
• STK_PHM — Physical & Mechanical Engineering
• STK_SAF — Safety
• STK_CERT — Certification / Compliance
• STK_TEST — Test / V&V
• STK_OPS — Operations
• STK_MRO — Maintenance, Repair & Overhaul
• STK_AI — AI / ML Engineering & Assurance
• STK_CY — Cybersecurity
• STK_SPACEPORT — Spaceport / Ground Segment
• STK_CEGT — Circular Economy and Green Tech

Contract Locations: CAXS/AoR/STK_*/PORTAL/*__portal-contract_REGISTRY_REG_I01-R01_ACTIVE.yaml

TALF (Tool Access & Licensing Fabric):

• Entitlement checking via IAM/SSO integration
• License pool management with concurrent checkout
• Preflight validation (SSO, compute, license, entitlements)
• Launch orchestration across VDI, web, HPC channels
• Audit logging with 7-year retention

Service Specification: CAXS/INFRASTRUCTURE/portals/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__talf-service-specification_DELIVERABLE_SPEC_I01-R01_DRAFT.md

Infrastructure:

• Tool Catalog: CAXS/INFRASTRUCTURE/access/tool_catalog.yaml
• Entitlement Matrix: CAXS/INFRASTRUCTURE/access/entitlement_matrix.csv
• License Events Registry: CAXS/INFRASTRUCTURE/access/license_events_registry.md

Implementation Guide: CAXS/INFRASTRUCTURE/portals/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__portal-frontend-components-specification_DELIVERABLE_SPEC_I01-R01_DRAFT.md

All MUST features (F01-F09) have detailed component specifications including:

• Component structure and UI requirements
• State management patterns
• API integration points
• Performance requirements

Governance Process: CAXS/INFRASTRUCTURE/portals/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__portal-feature-governance-process_DELIVERABLE_PROC_I01-R01_DRAFT.md

Processes defined:

• Feature addition (6-step workflow with review/approval gates)
• Feature modification (6-step workflow with AoR consultation)
• Feature deprecation (5-step workflow with migration support)

Governance bodies:

• Portal Steering Committee (monthly reviews)
• Portal Working Group (bi-weekly coordination)

CA360 Portal Gates Workflow: .github/workflows/ca360_portal_gates.yml

Gate F — Portal Contract Validation:

• Validates all 14 AoR contracts exist and are well-formed
• Checks for required sections (metadata, context, features, tools, execution, backend)
• Validates aor_id matches filename
• Ensures all MUST features (F01-F09) are present
• Cross-validates tool references against tool catalog

• Portal Feature Catalog (SSOT): CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__portal-feature-catalog_REGISTRY_CAT_I01-R01_ACTIVE.md
• AoR Portal Contract Schema: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__aor-portal-contract-schema_DELIVERABLE_SCHEMA_I01-R01_ACTIVE.md
• Tool Launchpad Specification: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_DAB__tool-launchpad-specification_DELIVERABLE_SPEC_I01-R01_ACTIVE.md

KNOTS (Knowledge Nets and Ontology as Tasking Strategy) is the AMPEL360 CAXS method for turning design thinking into certifiable, repeatable agentic work, expressed as SysML-consumable task structures and enforced by governance gates.

A KNOT is a controlled process node that:

1. defines what knowledge must exist (ontology commitments),
2. defines how it must connect (knowledge net interfaces),
3. defines what tasks agents may execute (tasking strategy),
4. defines what evidence must be produced (compliance-ready outputs).

KNOTS are the bridge between:

• MBSE/SysML architecture (requirements, behavior, structure, interfaces),
• agentic execution (task decomposition, automation, prompting/tooling),
• configuration control (traceability, naming standard, release packs),
• certification evidence (VV packs, audit queries, signed manifests).

Knowledge Net A directed graph where nodes are controlled artifacts (models, specs, data, test results) and edges are typed relations (e.g., satisfies, verifies, allocatesTo, dependsOn, evidencedBy).

Ontology Commitments A governed vocabulary and schema set that makes artifacts machine-checkable:

• controlled terms (AoR/STK, TYPE/STATUS, IDENTIFIER grammars),
• schemas (SSOT) for registers, evidence, and interfaces,
• constraints (allowed ranges, required fields, invariants).

Tasking Strategy A rule set that converts "what we need" into "what agents do":

• permitted actions per AoR,
• sequencing rules and dependencies,
• minimum evidence required to close a KNOT.

SysML Expression KNOTS are represented as:

• activity flows (task decomposition),
• state constraints (status transitions),
• requirements relations (satisfy/verify),
• interfaces/ports (ICDs and knowledge edges),
• allocation to AoR/STK owners and toolchains.

KNOT IDs are configuration-controlled tokens used in filenames and gates.

• Allowed IDs: K01..K14 only
• Optional task suffix: -T### (e.g., K06-T001)
• Any new KNOT requires a standard upgrade + CM approval.

This ensures:

• stable automation rules,
• predictable portal navigation,
• auditable process boundaries.

Each KNOT has:

• Inputs: required artifacts + schemas
• Transforms: allowed agentic actions (generate/validate/link/package)
• Outputs: NKUs (implicit) + evidence bundles
• Guards: PLC gates that must pass (PR-blocking)
• Trace edges: relations recorded into the traceability graph / ontology DB

A KNOT is "closed" only when:

• naming/identifier validators pass,
• evidence links resolve,
• exceptions are registered and approved (where allowed),
• release pack or checkpoint artifact is produced (when applicable).

• STK_SE (Architecture & Governance)
  Owns: SysML structure, ontology commitments, interface/ICD rules, allocation logic, process constraints.

• STK_SPE (Software & Prompting Engineering)
  Owns: agentic task runners, prompting specs, automation scripts, CI gates, validators, link-checkers, packaging tools.

KNOTS is the contract between them:

• SE defines "what must be true"
• SPE implements "how it is enforced and executed"
• CM/CERT decide "what is releasable / acceptable"

Each KNOT definition should include:

• knot_id: K01..K14
• purpose: why this knot exists
• inputs_required: artifact types + schemas
• outputs_required: artifact types + evidence expectations
• relations_required: required trace edges (satisfy/verify/etc.)
• aor_owner: primary AoR/STK
• dependencies: other STKs and required handoffs
• gates: validators that must pass
• close_criteria: measurable completion criteria
• exceptions_policy: what can be waived, by whom, and how recorded

KNOTS is design thinking operationalized as SysML-governed, agent-executable task networks, with ontology-backed validation and CM-controlled evidence closure.

CIPPs are the complement to KNOTs: while KNOTs produce new certainty through uncertainty resolution, CIPPs route execution through known certainty.

A CIPP (Certainty Integration Pointer and Path) is a programmable, deterministically identifiable object that binds execution to established knowledge bases:

• Released baselines
• Approved standards
• Validated schemas
• Certified procedures
• Known-good integration routes

Core distinction:

Promotion rule: A KNOT is "collapsed" only when it yields (a) a released artifact chain and (b) at least one CIPP that points to that chain for deterministic reuse.

Two-layer graph model:

1. CIPP Graph (Certainty Layer): Nodes = CIPPs; edges = deterministic dependencies (requires, implements, exports, consumes). All targets must be RELEASED.

2. KNOT Graph (Uncertainty Layer): Nodes = KNOT states; edges = entanglement and coupling (hard, soft, conditional). Resolution yields CIPPs.

Workflow integration (Step 1.5): Before instantiating a KNOT, check if a valid CIPP exists for the same intent. If yes → execute via CIPP (skip KNOT). If no → proceed with KNOT resolution.

References:

• CIPP vs KNOT Governance: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__cipp-vs-knot-governance_DELIVERABLE_STD_I01-R01_ACTIVE.md
• CIPP Registry: CAXS/LEDGERS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__cipp-registry_REGISTRY_CAT_I01-R01_ACTIVE.md
• CIPP Definition Schema: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__cipp-definition-schema_DELIVERABLE_SCHEMA_I01-R01_ACTIVE.md
• CIPP-KNOT Graph Model: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__cipp-knot-graph-model_DELIVERABLE_SPEC_I01-R01_ACTIVE.md

Both CIPPs and KNOTs must be directionally aligned with program intent to prevent accumulating "perfectly-structured work that is directionally wrong."

Intent Key (required for all CIPPs and KNOTs):

intent_key:
  vision_id: VSN-###       # Long-term "north star" (e.g., VSN-001: Zero-Carbon Aviation)
  mission_id: MSN-###      # Operational mission objective (e.g., MSN-005: Circular Material Recovery)
  scope_id: SCP-*          # Program boundaries (e.g., SCP-SPACET-Q10-BASELINE-PLUS)
  pathway_ids: [P01, ...]  # Execution lanes (P01-P05: Design/Implementation/V&V/Ops/Governance)
  outcome_ids: [OUT-###-###, ...] # Measurable downstream results

Intent Hash: sha256(canonical_json(intent_key + pgk_scope + aor_owner)) — prevents semantic drift.

SSOT Registries (intent oracle):

1. Vision Registry: Long-term strategic objectives with time horizons and disallowed directions
2. Mission Registry: Measurable mission objectives with success metrics and constraints
3. Scope & Outcome Registry: Program boundaries and measurable downstream results (DOIs/KPIs)

CI Gates (PR-blocking for in-scope artifacts):

• Gate A — Intent Reference Validity: All vision/mission/scope/outcome IDs must exist in SSOT registries and be ACTIVE/RELEASED; intent hash must match computed value
• Gate B — CIPP Determinism: All target refs exist, hashes match, status constraints satisfied, dependencies resolvable
• Gate C — Outcome Trace Completeness: Each outcome must link to evidence hooks and deterministic target chains (CIPPs) or task outputs + evidence (KNOTs)

References:

• Intent Alignment Policy: CAXS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__ca360-intent-alignment-policy_DELIVERABLE_STD_I01-R01_ACTIVE.md
• Vision Registry: CAXS/LEDGERS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__vision-registry_REGISTRY_IDX_I01-R01_ACTIVE.md
• Mission Registry: CAXS/LEDGERS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_PMO__mission-registry_REGISTRY_IDX_I01-R01_ACTIVE.md
• Scope & Outcome Registry: CAXS/LEDGERS/00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__scope-outcome-registry_REGISTRY_IDX_I01-R01_ACTIVE.md

The OPT-INS framework defines six canonical axes for information topology:

[ATA]_[PROJECT]_[PROGRAM]_[FAMILY]_[VARIANT]_[VERSION]_[MODEL]_[BLOCK]_[PHASE]_[KNOT]_[AoR]__[SUBJECT]_[CATEGORY]_[TYPE]_[ISSUE-REV]_[STATUS].[EXT]

1. Double-underscore __ is mandatory before SUBJECT.
2. No KNOT outside K01..K14 may appear anywhere in filename.
3. AoR must be one allowlisted STK token (10.2.9).
4. BLOCK is domain segmentation, not lifecycle (LC stays in PHASE).
5. One Official Chain applies to CATEGORY=DELIVERABLE (10.2.15).
6. TEKNIA credentials are CATEGORY=REGISTRY with TYPE=BADGE|CERT|LIC and AoR restricted (10.2.16).

• ATA: ^(0[0-9]|[1-9][0-9]|1[01][0-6])$
• PROJECT: ^AMPEL360$
• PROGRAM: ^(AIRT|SPACET)$
• FAMILY: ^(Q100|Q200LR|Q10|QHABITAT)$
• VARIANT: ^(GEN|BASELINE|FLIGHT_TEST|CERT|MSN|CUST)$
• VERSION: ^(PLUS|PLUSULTRA)$
• MODEL: ^(BB|HW|SW|PR)$
• BLOCK: ^(00|10|20|30|40|50|60|70|80|90)$
• PHASE: ^LC(0[1-9]|1[0-4])$
• KNOT: ^K(0[1-9]|1[0-4])(-T\d{3})?$
• AoR: ^(STK_CM|STK_PMO|STK_SE|STK_DAB|STK_PHM|STK_SAF|STK_CERT|STK_TEST|STK_OPS|STK_MRO|STK_AI|STK_CY|STK_SPACEPORT|STK_CEGT)$
• SUBJECT: ^[a-z0-9]+(?:-[a-z0-9]+)*$
• CATEGORY: ^(DELIVERABLE|EVIDENCE|REGISTRY|SIGNOFF|EXPORT_CONTROL|INTERNAL_PRODUCTION)$
• TYPE: build from allowlist in 10.2.11 (exact match).
• ISSUE-REV: ^I(0[1-9]|[1-9][0-9])-R(0[1-9]|[1-9][0-9])$
• STATUS: ^(DRAFT|ACTIVE|RELEASED|SUPERSEDED|OBSOLETE)$
• EXT: build from allowlist in 10.2.13 (exact match).

Interpretation rule: If you need explicit “REVIEW/FREEZE” semantics, map ACTIVE→REVIEW and RELEASED→FREEZE for gating purposes without adding new STATUS tokens.

The lifecycle PHASE token is one of the following 14 controlled values. Meanings are fixed and must not be repurposed.

• PHASE is lifecycle only; it must not encode domain segmentation (that is BLOCK).
• PHASE is always exactly one of LC01..LC14 and appears once in the filename.
• “V6V” naming is treated as part of the LC05 scope (Integration Testing & Prototyping).

CHARTER, README, STD, POL, PROC, PLAN, REQ, SPEC, ARCH, ICD, MOD

MAN

Manual subtype is encoded in SUBJECT (e.g., amm-*, ipc-*, srm-*, tsm-*, wdm-*, qrh-*, fcom-*).

TST, CASE, LOG, RPT, NCR, DEC, MIN, DIA, TAB, LST

IDX, REG, CAT

SCHEMA, ONTO, TRACE, DPP, SBOM, BOM, MAP, MANIFEST, EVD

BADGE, CERT, LIC

md, txt, yml, yaml, json, csv, svg, png

docx, xlsx, pptx

1. CATEGORY=SIGNOFF → AoR must be STK_CM or STK_CERT only.
2. CATEGORY=EXPORT_CONTROL → AoR must be STK_CM or STK_CERT only.
3. TYPE in {BADGE,CERT,LIC} → AoR must be STK_CM or STK_CERT only.

Define key: K = (ATA,PROJECT,PROGRAM,FAMILY,VARIANT,VERSION,MODEL,BLOCK,PHASE,AoR,SUBJECT,CATEGORY,TYPE)

• If CATEGORY=DELIVERABLE:
  • COUNT(status ∈ {ACTIVE, RELEASED}) ≤ 1
  • (ACTIVE = “REVIEW-equivalent”; RELEASED = “FREEZE-equivalent”)
• If CATEGORY=REGISTRY:
  • SSOT rule applies: exactly one canonical register per scope.
• If CATEGORY=EVIDENCE:
  • No uniqueness constraint, but must link to impacted DELIVERABLE(s).

For TYPE in {BADGE,CERT,LIC} (CATEGORY REGISTRY):

• must bind to one or more NKUs via:
  • repo_relative_path
  • sha256
  • optional commit
• credential schema must be versioned (TYPE=SCHEMA) and validated.
• issuance AoR restricted: STK_CM or STK_CERT only.

DELIVERABLE (official) 00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K01_STK_CM__nomenclature-standard_DELIVERABLE_STD_I01-R01_ACTIVE.md

EVIDENCE (change note NKU) 00_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_00_LC01_K04_STK_CM__nomenclature-change-note_EVIDENCE_RPT_I01-R01_ACTIVE.md

REGISTRY (TEKNIA credential) 94_AMPEL360_SPACET_Q10_BASELINE_PLUS_PR_30_LC06_K06_STK_CERT__teknia-credential_REGISTRY_CERT_I01-R01_RELEASED.json

The MODEL_SOFTWARE directory organizes software artifacts, automation tooling, and process scripts across all lifecycle phases. This structure provides a canonical organization for software models (MODEL=SW) aligned with the AMPEL360 lifecycle phases.

Location: CAXS/AoR/STK_CM/PORTAL/PROGRAM_SPACET/FAMILY_Q10/VARIANT_GEN/VERSION_PLUS/SYSTEM_ATA-00_Spacecraft/BLOCK_10_Operational_Systems/MODEL_SOFTWARE/

MODEL_SOFTWARE/
├── LC00_GENERAL/
├── LC01_PROBLEM_STATEMENT_GENERATION_PROMPTING_ENGINEERING/
├── LC02_SYSTEM_REQUIREMENTS/
├── LC03_DESIGN_MODELS/
├── LC04_ENGINEERING_ANALYSIS_AND_CALCULATION_MODELS/
├── LC05_INTEGRATION_TESTING_AND_PROTOTYPING_VV_V6V/
├── LC06_QUALITY/
├── LC07_SAFETY_AND_SECURITY/
├── LC08_CERTIFICATION_AND_FIRST_FLIGHT/
├── LC09_GREEN_AIRCRAFT_BASELINES/
├── LC10_INDUSTRIALIZATION_SERIALIZATION_PRODUCTION_PLAN_CM/
├── LC11_OPERATIONS/
├── LC12_SUPPORT_AND_SERVICES/
├── LC13_MRO_AND_SUSTAINMENT/
└── LC14_RETIREMENT_MANAGEMENT_AND_CIRCULARITY/

• Each directory contains software artifacts (scripts, tools, validators, generators) specific to that lifecycle phase
• Software follows the v6.0 nomenclature standard with MODEL=SW token
• Cross-phase or general-purpose software should be placed in LC00_GENERAL
• All software artifacts must be configuration-controlled and version-tracked
• Software in these directories supports the execution of tasks aligned to the corresponding KNOT (K01..K14) framework

The LC02_SYSTEM_REQUIREMENTS directory has a specialized internal structure to organize requirement management tooling:

Location: CAXS/AoR/STK_CM/PORTAL/PROGRAM_SPACET/FAMILY_Q10/VARIANT_GEN/VERSION_PLUS/SYSTEM_ATA-00_Spacecraft/BLOCK_10_Operational_Systems/MODEL_SOFTWARE/LC02_SYSTEM_REQUIREMENTS/

LC02_SYSTEM_REQUIREMENTS/
├── SCHEMAS/      — requirement record schemas, controlled vocab dictionaries
├── ENGINES/      — parsers, normalizers, ID services, baseline managers
├── VALIDATORS/   — quality checks, constraint checks, contradiction detectors
├── TRACE/        — trace graph builders, link resolvers, impact analyzers
├── INTERFACES/   — ICD candidate extraction and cross-ATA coupling tools
├── EXPORT/       — converters to SysML/ReqIF/CSV/JSON, portal registry writers
├── CI/           — LC02 gate scripts for GitHub Actions / pipelines
└── FIXTURES/     — small deterministic test fixtures

References:

• Detailed documentation in LC02_SYSTEM_REQUIREMENTS/README.md
• Individual subdirectory README files for specific guidance
• ATA 93 (Traceability Graph) for trace tooling specifications
• ATA 99 (Master Registers) for schema and vocabulary standards