Platform
Managed documentation for Platform.
Platform Overview
Platform Overview
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Static release scan |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Mission
OpenSOF is an open, modular operational technology platform intended to connect sensing, data, semantic knowledge, collaboration, command-and-control, analytics, automation and effects without forcing every capability into one monolithic application.
Core design idea
The platform treats meaning, time, source, identity and correlation as first-class operational context. OpenBus provides exchange; OpenKnowledge provides shared meaning; domain modules can then collect, exploit, associate, share, collaborate, task and preserve information through common patterns.
Release evidence summary
| Measure | Observed |
|---|---|
| Files inventoried | 1383 |
| Text files inspected | 1004 |
| Detected components | 23 |
| REST/interface candidates | 11 |
| WebSocket candidates | 8 |
| Environment variables | 244 |
| Languages | PHP, JavaScript, Python, C, Shell, C++ |
| Framework indicators | — |
Operational value
- Integrate heterogeneous sensors, services and user workflows through explicit interfaces instead of one-off stovepipes.
- Use semantic types and relationships to guide analytics, automation and AI instead of relying only on unconstrained language-model inference.
- Process data at the edge and exchange the operational result, reducing bandwidth and decision latency.
- Keep components independently deployable so a customer can adopt the capabilities it needs and integrate them with existing systems.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Operational Workflow
Operational Workflow
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Static release scan |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Reference workflow
| Step | Action | Outcome |
|---|---|---|
| 1 | Collect | Acquire observations, messages, tracks, files, imagery, video, spectrum and telemetry. |
| 2 | Exploit | Extract useful features, metadata and operational signals at the source or edge. |
| 3 | Associate | Relate observations to entities, locations, missions, cases, tasks and prior evidence. |
| 4 | Share | Publish governed information through OpenBus, APIs, files and collaboration services. |
| 5 | Collaborate | Build shared understanding through COP, chat, annotations, knowledge and reviews. |
| 6 | Task | Convert understanding into assigned, acknowledged, executing and completed work. |
| 7 | Preserve | Retain evidence, provenance, decisions and replayable operational history. |
Why this matters
The workflow is deliberately cross-application. A sensor product should not terminate at a viewer; it should be associable with a track, shareable with a release group, usable as evidence, able to trigger analytics, and convertible into a task. The platform is strongest when these transitions are explicit and auditable.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.
Capability Map
Capability Map
| Field | Value |
|---|---|
| Distribution | BSS — OpenSOF |
| Product | OpenSOF |
| Release | 0.15.1 |
| Deployment | opensof.bss.dev |
| Source | /srv/bss/releases/OpenSOF-v0.15.0-20app |
| Evidence | Static release scan |
| Source fingerprint | cda583b42f2a0d296b268ab5b174932a378c8be6fb52ffa1af14af896e990f6e |
| Status | Generated baseline — human review required |
Verification boundary: This page combines platform design guidance with static evidence from the release. It does not prove that every detected interface is enabled, reachable, secure, or operational in the deployed environment.
Capability families
| Family | Components and scan status |
|---|---|
| Foundation & Data | OpenBus (detected), OpenKnowledge (detected), OpenData (detected), OpenPNT (detected), OpenFiles (detected) |
| Command, Control & Collaboration | OpenCOP (detected), OpenTrack (detected), OpenTask (detected), OpenChat (detected), OpenEyes (detected), OpenMail (detected) |
| Sensors & Spectrum | OpenRF (detected), OpenSSA (detected), OpenISAC (detected) |
| Analytics & AI | OpenAnalytics (detected), OpenLLM (detected), OpenDAA (detected) |
| Networks & Simulation | OpenNetworks (detected), OpenLVC (detected), OpenAAR-MR (detected) |
| Investigation & Security | OpenIIA (detected), OpenCyberSec (detected), AEGIS-SENTINEL (detected) |
Interpretation
“Detected” means the scanner found release-file evidence using names, paths or content. “Not detected” does not prove absence: a capability may be external, injected at deployment time, renamed, generated, or inaccessible to the scan. Component pages therefore distinguish catalog intent from release evidence.
Maintainer Notes
Add human-reviewed deployment notes, corrections, decisions, screenshots, and links here. Content outside the generated block is preserved on future runs.