Executive Overview

SCPN Phase Orchestrator is a synchronisation-analysis toolkit for systems with repeating behaviour, with a review-only control-proposal surface. It turns waves, events, and discrete states into phase variables; evaluates synchrony, coupling, lag, and causality; and produces reviewable control proposals for human review rather than opaque automation — it does not close a control loop on hardware.

The short operational question is:

Which parts of this system are locking together, should that lock exist, and what bounded change can be reviewed before anything reaches production?

Why This Exists

Modern organisations already collect cyclic telemetry, but it is usually split between dashboards, incident logs, notebooks, controller code, and domain tools. SPO provides a shared phase contract so different teams can discuss the same phenomenon with the same variables: theta, omega, K, alpha, zeta, Psi, R_good, and R_bad.

That matters when the wrong intervention is expensive. In grids, plasma, industrial operations, robotics, clinical research, and distributed systems, control proposals must be bounded, replayable, and rejectable. SPO is designed around that evidence boundary.

What It Is

Layer	Description	User-facing value
Domainpack compiler	YAML binding specs describe sources, oscillator families, channels, coupling, objectives, and boundaries	domain assumptions are explicit and versioned
Oscillator extraction	physical, informational, and symbolic signals become phase channels	heterogeneous telemetry becomes comparable
Dynamics engine	Kuramoto, UPDE, Stuart-Landau, delay, stochastic, simplicial, inertial, and related models evolve the phase state	synchrony hypotheses can be tested before deployment
Monitors	order parameter, PLV, PAC, Lyapunov, entropy, transfer entropy, Hodge, chimera, STL, and related metrics	operators see more than a single scalar dashboard
Supervisor	regime FSMs, Petri nets, policies, value guards, and projectors constrain proposed changes	actuation stays bounded and reviewable
Evidence layer	audit logs, replay, benchmark snapshots, Studio panels, and generated docs	decisions can be reproduced, explained, or rejected

What It Is For

SPO is most useful where a system has repeated behaviour and synchrony affects risk, performance, or diagnosis.

Domain	Typical use case	SPO contribution
Power and energy	generator/inverter oscillations, weak damping, cascading risk	inertial Kuramoto modelling and bounded stability proposals
Fusion and plasma	MHD modes, transport oscillations, actuator timing	multi-rate phase binding and review-only stabilisation evidence
Cloud operations	retry storms, queue cascades, heartbeat lock-in	harmful synchrony detection and desynchronisation proposals
Manufacturing	vibration, tool wear, cyclic defects, process drift	root-cause evidence across coupled process loops
Neuroscience/cardiology	band coupling, rhythm coherence, seizure or arrhythmia research	reproducible phase metrics without autonomous treatment claims
Robotics/swarms	gait, formation, leader-follower coherence	simulation-first phase-policy development
Traffic/logistics	signal coordination, platoon waves, queue waves	congestion-wave evidence before live signal changes
Digital twins	plant/twin drift and residual coherence	replayable mismatch and maintenance hypotheses
ML research	differentiable oscillator layers and inverse coupling	gradient-based topology, coupling, and policy search

What value this framing supports in practice

The same structure can reduce ambiguity in three organisational loops:

• engineering teams align on a shared interpretation of oscillatory behaviour before tuning,
• operators gain repeatable evidence before any proposal reaches review,
• executives get explicit boundaries between shipped surfaces and deferred research.

That is the practical difference versus monolithic monitoring stacks: a single source-of-truth contract from input channels to audit trails, rather than separate tool-specific evidence silos.

What Makes It Different

SPO is not only an oscillator simulator. The differentiator is the chain from source binding to bounded operational evidence:

1. Bind the domain assumptions.
2. Extract phase consistently across physical, informational, and symbolic data.
3. Simulate or infer coupled dynamics with explicit numerical contracts.
4. Measure synchrony, causality, and safety monitors.
5. Propose only bounded, rate-limited, review-gated actions.
6. Preserve replay and benchmark evidence for promotion decisions.

This is why the repository includes CLI, Python API, JAX layers, Rust kernels, notebooks, domainpacks, Studio panels, formal proof hooks, and benchmark gates. They are separate surfaces, but they serve the same review-first control path.

Adoption Routes

If you are	Start with	Then move to
Evaluating value	Use Cases and Value Map	Quickstart
Building a domain	New Domain Checklist	Raw Sources to Run
Embedding in Python	Python Facade API	Production Deployment
Training differentiable models	Differentiable Kuramoto	nn API
Reviewing operations	Notebook to Production	Release Hygiene
Checking roadmap maturity	Public Roadmap	benchmark and CI artefacts

Evidence and Safety Boundaries

• A domainpack is executable evidence only after its assumptions and boundaries are reviewed for the domain.
• Benchmark numbers are dated snapshots and must be reproduced before being used as current performance claims.
• Hardware adapters are opt-in and adapter-scoped; review-only quantum and neuromorphic compiler targets do not execute on hardware by default.
• The Python facade is for deterministic local simulation, not live actuation.
• Studio panels are operator review surfaces, not proof that a domain is calibrated.
• Frontier tracks such as safe RL, causal topology mutation, formal export, and hardware-native compilation remain evidence-bound until the relevant artefacts are published.

Where the value actually is

SPO's value is concrete and evidence-bound, not a slogan:

• An honest evaluator anyone can point at a detector. spo audit-detector (the evaluation package) scores any early-warning detector's event-vs-null skill at a matched false-alarm rate, with a permutation p-value and a hash-sealed record. A team can check whether a detector — theirs or a vendor's — beats chance before trusting it. Most published tipping-point indicators do not, and measuring that honestly is uncommon.
• One externally-validated niche: grid modal damping. SPO's growth-rate estimate tracks ANDES small-signal eigenvalues (Spearman ρ up to 0.87) on independent systems — a checkable physical quantity a grid team can act on, positioned as a complement to ANDES, not a competitor to commercial mode meters.
• Evidence continuity. One artefact chain — binding spec → phase state → coupling → regime → bounded proposal → deterministic replay log — so a control decision is reconstructible and reviewable end to end, across simulation and runtime.
• One representation across domains. The same phase model applies to a grid, a service mesh, or an EEG, because underneath they are coupled-oscillator systems, so a team reuses one toolchain instead of rebuilding per domain.

Where drift, lock-in, cascade, or unsafe control is expensive — energy, fusion, industrial operations, clinical research, robotics, cloud platforms — that combination of a checkable niche, an honest evaluator, and a reviewable proposal path is the point. It shifts the default from ad-hoc tuning to evidence-backed iteration.

How teams usually adopt this

Teams that deploy this platform successfully follow a common sequence:

1. encode the target process as a binding spec and set measurable objectives,
2. run a closed loop in simulation until replay matches domain expectations,
3. connect only the required adapter set and keep actuation clipped,
4. validate policy transitions and boundary checks with benchmark and replay,
5. promote to production controls only with explicit operator sign-off.

That sequence is why the repository keeps the same controls and metrics on both simulation and runtime surfaces. There are fewer hidden conversion steps and fewer places where telemetry semantics can drift.

Commercially, the value sits at the junction of reduced setup cost and reduced operational ambiguity: teams usually see faster pilot-to-production transitions when they can reuse the same evidence path for internal review and live rollout.

Operational positioning

The product is positioned for teams that already have telemetry and need a reusable control chain from data to policy proposals.

In practice, teams use it in three ways:

• as a simulation-first decision aid when introducing a new control strategy,
• as a bounded intervention planner when they already run review gates,
• as a common language for synchrony evidence across research, operations, and platform teams.

The platform is not intended to replace all domain control stacks in one change; it standardises phase contracts, evidence artifacts, and promotion gates where those control stacks already exist.

Why this is a commercial fit for regulated environments

In regulated settings, the differentiator is not a richer chart but evidence continuity:

• traceable bindings,
• deterministic replay, and
• policy proposals that can be reviewed before output is allowed.

These properties reduce ambiguity between simulation teams, safety teams, and production operators, especially when timelines are short and decisions are high-impact.