Use Cases and Value Map¶
SCPN Phase Orchestrator is a synchronisation-analysis toolkit with a review-only control-proposal surface. It turns cyclic, event-driven, and state-machine behaviour into phase variables, runs those variables through coupled-oscillator dynamics, and produces reviewable control proposals for systems where synchrony is useful, harmful, or diagnostic — for human review, not automated actuation.
The practical question it answers is:
Which parts of this system are locking together, which parts should not be locking together, and which safe control knob can move the system back toward the intended regime?
The Short Explanation¶
Most complex systems contain repeating processes: heartbeats, queues, retry storms, grid frequency, machine vibration, market cycles, sleep stages, traffic lights, robotic gaits, plasma modes, or software-service heartbeats. SPO maps those processes into three oscillator channels:
| Channel | What it captures | Example inputs |
|---|---|---|
| Physical | Continuous measured waves | voltage, pressure, vibration, EEG, PPG, temperature |
| Informational | Timed events and decisions | requests, retries, trades, alarms, messages |
| Symbolic | Discrete states and modes | sleep stage, machine state, traffic phase, workflow state |
Once every relevant signal has a phase, SPO can compute order parameters, phase-locking metrics, causal coupling evidence, regime transitions, and bounded control proposals with deterministic replay evidence.
Where It Creates Value¶
Read the Evidence column honestly: exactly one domain — the power grid — is
externally validated (SPO's growth-rate estimate tracks ANDES small-signal
eigenvalues, ρ up to 0.87). Every other row is a reusable scaffold: a working
binding that parses, runs, and gives you a starting point, not a validated
detector for that domain. Generic early-warning detection is at chance on real data
outside the grid, and SPO reports that rather than overclaiming. Use the
spo audit-detector auditor to check any detector
before you trust it.
| Market or domain | Operational problem | SPO value path | Evidence |
|---|---|---|---|
| Power and energy | Grid oscillations, weak damping, inverter coordination | detect harmful coherence, test coupling policies, produce audit-backed control proposals | Validated — growth rate vs ANDES eigenvalues (ρ≤0.87) |
| Fusion and plasma | MHD mode coupling, transport oscillations, control timing | map multi-rate observables into coupled phase channels and review stabilising proposals | Scaffold — not yet validated |
| Cloud and platform operations | Retry storms, queue cascades, service-heartbeat lock-in | detect synchronised failure modes and desynchronise overloaded layers | Scaffold — not yet validated |
| Manufacturing and machinery | Vibration, process drift, cyclic defects, SPC patterns | expose phase coupling between process variables and control loops | Scaffold — not yet validated |
| Cardiology and neuroscience | rhythm coherence, seizure precursors, band coupling | analyse phase locking, PAC/PLV/ITPC, and multi-scale synchrony without hidden actuation | Scaffold — review-only, no clinical claim |
| Robotics and swarms | gait coordination, leader-follower locking, swarm consensus | prototype phase policies before physical deployment | Scaffold — not yet validated |
| Traffic and logistics | signal timing, platoon waves, queue waves | simulate coordination policies and detect unstable synchronisation patterns | Scaffold — not yet validated |
| Finance and markets | regime coupling, sector synchrony, crash precursors | review cyclic coherence and coupling shifts as risk evidence, not trading advice | Scaffold — diagnostic, not prediction |
| Digital twins | plant/twin drift and residual coherence | bind real telemetry to phase-state twins with replayable audit records | Scaffold — not yet validated |
| Research platforms | differentiable oscillator models and inverse coupling | optimise coupling matrices and infer topology from trajectory data | Toolkit — numerically validated vs analytic solutions |
How to Recognise a Good SPO Use Case¶
A good candidate has all of these properties:
| Question | Good sign | Poor fit |
|---|---|---|
| Is there repeated behaviour? | waves, cycles, retries, rotations, stages, heartbeats, events, or state loops | one-off static records with no temporal phase meaning |
| Can each source be timestamped or ordered? | samples, events, and states can be aligned to a common clock or sequence | measurements have no reliable ordering or cadence |
| Does synchrony matter? | some coherence is desirable, harmful, diagnostic, or causal | the domain only needs scalar threshold alerting |
| Can assumptions be written down? | coupling, lag, forcing, and safety boundaries are reviewable | the domain requires undocumented black-box decisions |
| Is actuation sensitive? | proposals need replay, audit, rate limits, and human review | a simple uncontrolled script is acceptable |
Why the Market Angle Matters¶
Many organisations already collect cyclic telemetry but keep it split across signal dashboards, incident logs, notebooks, and controller-specific tools. SPO turns those fragments into a common phase contract. That matters because the same questions reappear across sectors: which components are phase-locked, what coupling path caused it, whether the lock is good or bad, and which bounded knob could move the system without violating review policy.
The commercial value is highest where wrong control is expensive: energy, industrial operations, clinical research, cyber-physical infrastructure, robotics, aerospace, and high-value simulation. In those settings the audit surface is as important as the mathematics. A proposal that cannot be replayed, rejected, or traced should not reach production.
Core User Journeys¶
| User | First useful path | Production path |
|---|---|---|
| Domain expert | identify oscillators and boundaries | maintain a domainpack with cited assumptions and validation evidence |
| ML researcher | use differentiable Kuramoto layers and SAF losses | train coupling/topology proposals with accelerator checks and reproducible seeds |
| Platform engineer | run QueueWaves or a minimal domainpack | wire metrics to bounded policies, audit replay, and dashboard review |
| Control engineer | inspect K, alpha, zeta, and Psi knobs | keep actuation behind rate limits, safety tiers, and human review gates |
| Documentation reader | start with this page and the quickstart | follow the tutorial sequence and API reference for the selected surface |
| Investor or product reviewer | inspect use cases, evidence boundaries, and roadmap | review validated capabilities, commercial licensing path, and open frontier items |
Expected value pattern¶
Across domains, value is most predictable when teams keep the same sequence:
- define what should synchronize and what should remain decoupled,
- represent inputs consistently across physical, informational, and symbolic channels,
- test bounded control candidates in replay-first mode,
- keep only candidates with explicit regime, metric, and evidence gates.
This produces a consistent operating language for operators, platform owners, and product reviewers because "good coherence", "harmful coherence", and "bounded response" are handled in the same contracts for different sectors.
What SPO Is Not¶
SPO is not a black-box automation system. Hardware writes are adapter-scoped, review-gated, and disabled for quantum or neuromorphic compiler targets until a verified external execution pipeline exists.
SPO is not a generic time-series dashboard. It specifically models phase, coherence, coupling, synchronisation, desynchronisation, and safe control proposal boundaries.
SPO is not a claim that every cyclic system is identical. Each domainpack must state its measurement source, phase extractor, coupling assumptions, safety boundaries, and validation evidence.
Capability Map¶
| Capability | What to read | Why it matters |
|---|---|---|
| Binding specs | Binding API | makes domain assumptions explicit and reviewable |
| Oscillator extraction | Oscillators API | maps physical, informational, and symbolic data to phase |
| UPDE engines | UPDE API | runs Kuramoto, Stuart-Landau, delay, stochastic, and higher-order dynamics |
| Supervisor | Supervisor API | classifies regimes and proposes bounded actions |
| Audit replay | Audit API | makes runs reproducible and tamper-evident |
| Differentiable dynamics | Differentiable Kuramoto | supports gradient-based topology and coupling optimisation |
| Autotune | Autotune API | extracts phases, identifies frequencies, infers coupling, and proposes replay-only policies |
| Hardware adapters | Adapter Bridges | keeps optional integrations explicit and safety-bounded |
| Notebooks | Notebooks and Demos | gives runnable learning routes for each major capability |
Learning Routes¶
| Goal | Route |
|---|---|
| Understand the product | This page -> System Overview -> Pipeline Execution |
| Run the first local simulation | Installation -> Quickstart -> Hello World |
| Build a domainpack | New Domain Checklist -> Oscillator Hunt Sheet -> Build K_nm Templates |
| Move from data to a run | From Raw Sources to Run -> Deterministic Replay |
| Work with ML surfaces | Differentiable Kuramoto Tutorial -> nn API -> SAF guide |
| Review production readiness | Production Guide -> Release Hygiene -> Roadmap |
Evidence Boundary¶
The repository contains a broad capability surface, but each claim must be read with its evidence boundary:
- committed tests demonstrate behavioural contracts, not universal domain truth;
- benchmark pages report dated local or CI snapshots, not guaranteed throughput on every machine;
- hardware adapters document safety boundaries and optional dependencies;
- roadmap items distinguish implemented surfaces from research or deferred tracks;
- domainpacks are examples until calibrated against real domain data and reviewed by the responsible domain expert.
That boundary is intentional. SPO is designed for systems where incorrect control claims are expensive, so documentation must separate executable capability, review-only evidence, and future research scope.
Adoption sequence by role¶
For each use case, apply this sequence before live recommendations:
- define the target coherence outcome (desirable lock, avoidable lock, or neutral synchrony),
- map signals into physical/informational/symbolic channels,
- run at least one audit-backed deterministic run,
- validate policy and monitor settings on replay,
- only then promote to review cadence with bounded actuation.
This keeps the evidence boundary explicit and prevents overreach from unvalidated inference.
Use this page to select a first domain¶
Before opening implementation guides, define:
- target signal class (continuous, event, state),
- expected control direction (synchronise, desynchronise, classify),
- and the first evidence package (minimal domainpack + replay file).
If those three items are not agreed, the remaining process should stay in evaluation mode and avoid actuator exports.
Use this page as the final business-value filter before any advanced engine choice is made.
For the three focus tracks — industrial predictive maintenance, critical infrastructure, and biosignal/clinical — with their lead domainpacks, runnable commands, validation status, and safety-tier posture, see Beachhead Verticals.