SC-OES architecture and event semantics
SC-OES is SynapseCommand's draft public semantics layer for stating what kind of operational assertion a canonical event represents and what evidence, confidence and verification context travels with it.
Meaning after translation
SC-OES is applied after a source-format adapter has translated a record into the Canonical Data Model. It is an optional semantic block on the existing CDM Event, not a second event envelope and not a replacement for the source format.
It identifies the kind of assertion being made, its governed event type, confidence and verification context, applicable interval, provenance, evidence, relationships and security markings. A CDM event without an SC-OES block remains a valid CDM event.
The block is additive within the CDM event. That is not a promise that every existing reader accepts records produced against a later schema: what a specific consumer tolerates depends on that consumer, and is a question for its own acceptance testing.
- Canonical Data Model
- What shape does the normalised record take?
- Operational Ontology
- What does the operational term or relationship mean?
- SC-OES
- What kind of operational assertion does the event represent?
- Adapters
- How does an external format map into or out of the canonical layer?
Shape, meaning and decision logic remain distinct
This is a conceptual separation of responsibilities. A deployment does not need to exercise every adapter or semantic feature for every record.
- External layer
External systems, standards and feeds
Source formats remain authoritative for their own wire semantics.
- Public layer
Public adapters
Translate source records into the public canonical layer and, where supported, back out.
- Public layer
Canonical Data Model (CDM)
Defines the normalised record shape.
- Public layer
SC-OES + Operational Ontology
Define assertion semantics and governed operational meaning.
- Private layer
SynapseCommand decision runtime
Applies proprietary reasoning, fusion, scoring and decision support.
The public repository exposes the integration contract and semantic vocabulary. It does not publish the SynapseCommand reasoning, inference, correlation, fusion, scoring or course-of-action runtime.
Eight assertion classes
The assertion class says what kind of claim an event makes. An observation must not silently become an assessment, and an assessment must not silently become a recommendation, a decision or an action. Recording a DECISION or an ACTION documents that somebody decided or authorised something; it does not authorise or perform execution.
- OBSERVATION
- A producer reports an occurrence it observed, measured or directly detected.
- STATE_CHANGE
- The represented operational state of something changed.
- CONSTRAINT
- An operational condition limits behaviour.
- ASSESSMENT
- An interpreted judgement, based on information or evidence, about something not itself directly observed.
- IMPACT
- An assessed operational consequence: what some condition means for an activity.
- RECOMMENDATION
- A proposed course of action. It asserts that something should be done, not that it was decided or done.
- DECISION
- A recorded decision.
- ACTION
- An authorised, initiated or completed operational action.
Source: spec/sc-oes/02-event-classes.md at the pinned release commit.
13 governed event types
Every row is read from the packaged event-type registry at the pinned release. No type, class or profile association is inferred.
| Identifier | Assertion class | Domain | Profile | Maturity |
|---|---|---|---|---|
| sc.pnt.gnss_interference.v1 | OBSERVATION | pnt | PNT | DRAFT |
| sc.air.air_track_observed.v1 | OBSERVATION | air | Air | DRAFT |
| sc.air.runway_availability_changed.v1 | STATE_CHANGE | air | Air | DRAFT |
| sc.air.airspace_restriction_changed.v1 | CONSTRAINT | air | Air | DRAFT |
| sc.logistics.supply_threshold_reached.v1 | STATE_CHANGE | logistics | Logistics | DRAFT |
| sc.logistics.route_availability_changed.v1 | STATE_CHANGE | logistics | Logistics | DRAFT |
| sc.isr.threat_assessment_updated.v1 | ASSESSMENT | isr | ISR | EXPERIMENTAL |
| sc.c2.system_availability_changed.v1 | STATE_CHANGE | c2 | C2 | DRAFT |
| sc.mission.mission_status_changed.v1 | STATE_CHANGE | mission | Mission | DRAFT |
| sc.mission.operational_impact_assessed.v1 | IMPACT | mission | Mission | EXPERIMENTAL |
| sc.decision.recommendation_created.v1 | RECOMMENDATION | decision | Decision | EXPERIMENTAL |
| sc.decision.decision_recorded.v1 | DECISION | decision | Decision | EXPERIMENTAL |
| sc.decision.action_authorized.v1 | ACTION | decision | Decision | EXPERIMENTAL |
Sources: event-type specification, packaged registry (raw), event-type process.
Seven profiles, one reference producer
Profiles are versioned independently of the package and of SC-OES itself. In this baseline only PNT has a reference producer, through the ingest-only pntmap adapter. The remaining six are specification only: published event-type membership without a shipped producer.
| Profile | Version | Maturity | Implementation status | Governed types |
|---|---|---|---|---|
| PNT | 0.1.0 | DRAFT | PRODUCER_BACKEDReference producer is the ingest-only pntmap adapter. | 1 |
| Air | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 3 |
| C2 | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 1 |
| Decision | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 3 |
| ISR | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 1 |
| Logistics | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 2 |
| Mission | 0.1.0 | DRAFT | SPECIFICATION_ONLYSpecification only in this baseline. No shipped producer. | 2 |
Sources: profile documents, conformance specification.
Five independent semantic dimensions
These five dimensions are reported separately, with PASS, FAIL or SKIP verdicts and no combined score. SKIP means not assessed and is never presented as PASS. They are distinct from the fifteen adapter dimensions A to O and from the six fixture checks reported on the interoperability pages.
- ACDM Conformance
- BSC-OES Core Syntax Conformance
- CSC-OES Semantic Type Conformance
- DSC-OES Profile Conformance
- EOntology Conformance
Governance and conformance
Version 0.1.0 is a draft maintained within the SynapseCommand project by Decent Cybersecurity. Its public governance records how event types, ontology terms, profiles and deprecations are proposed and recorded.
SC-OES conformance reports five independent dimensions, A to E, with PASS, FAIL or SKIP verdicts and no aggregate score. SKIP means not assessed and is never presented as PASS. Existing adapters can remain CDM Conformant without being SC-OES semantic producers.
Status and limits
SC-OES is not a NATO standard. It has not been submitted to, reviewed by, ratified by or approved by NATO or any external standards body. It is not a third-party certification scheme. Publication does not expose SynapseCommand reasoning, inference, fusion, scoring or course-of-action generation.
Inspect the public material
The repository contains the normative SC-OES documents and governance processes. The rendered documentation is an orientation; the repository text and packaged registries remain the inspectable authorities.