Below is a refinement / validation pass on your plan, with strong concurrence, notable gaps, and a question list for Trio / Loop / AAPS implementers.

Strong concurrence
	•	Separating config vs runtime vs computed state is exactly right
	•	ProfileDefinition / OverrideDefinition (user-authored, versioned)
	•	ProfileSelection / OverrideInstance (runtime intent)
	•	PolicyComposition (effective “what’s in force”)
This is the cleanest way to make Nightscout a neutral control-plane and keep MDI as the always-valid fallback.
	•	Bridge mode from devicestatus is the correct migration strategy
	•	Synthesize canonical events from snapshots initially; let controllers move to native events over time.
	•	This preserves backward compatibility and lets Nightscout evolve without forcing every client to update immediately.
	•	Authority + audit trails as first-class concerns are non-negotiable
	•	Your requestedBy + authority fields are foundational for safe delegation/agents.

What’s missing / important to add

1) You’ll want an explicit Event layer (even if you store objects too)

Right now the plan describes objects; it should explicitly define:
	•	Event envelope (append-only stream)
	•	eventId (stable UUID)
	•	eventType (e.g., profile.definition.upserted, override.instance.activated, policy.composed, delivery.requested)
	•	issuer (controller/user/agent id)
	•	issuerSeq (monotonic per issuer) or (issuer, time, nonce)
	•	cursor (server-assigned monotonic global ordering)
	•	idempotencyKey (for retries)
	•	refs (IDs/hashes referenced)
	•	payload (object snapshot or delta)

This is what makes cursor-based sync and reconciliation robust.

2) Capabilities need a real model (not just an optional pointer)

Your capabilitySnapshotId? is good, but you’ll likely need:
	•	ControllerKindDefinition (declared schema + what it supports)
	•	ControllerInstanceRegistration (this phone/controller right now)
	•	CapabilitySnapshot (what it can do now, including degraded states)
	•	pump connectivity status
	•	automation enabled/disabled
	•	max basal/bolus ceilings effective right now
	•	CGM health / confidence
	•	time sync health

Without this, “smart forms” and “digital twin honesty” get shaky.

3) Delivery tracking objects (you alluded, but not in the schema list)

To complete “intent vs reality” you want the minimal trio:
	•	DeliveryRequest (controller intent)
	•	DeliveryObservation (pump-confirmed reality)
	•	Reconciliation (match/partial/blocked/unknown + why)

This is also how you keep “taking a shot” present: an injection is a DeliveryObservation from a human source.

4) Conflict rules & multi-writer semantics

Nightscout will see inputs from:
	•	controller app
	•	caregiver app
	•	agent(s)
	•	manual UI
	•	bridge-synthesized from devicestatus

Define in core:
	•	How concurrent OverrideInstance are merged (composition is authoritative record)
	•	What “superseded” means across issuers
	•	Whether Nightscout allows multiple active overrides of same type
	•	How to prevent “flip-flop” loops (agent toggles override repeatedly)

5) Hashing/versioning rules need to be explicit

For ProfileDefinition:
	•	Canonicalization before hashing (sorted keys, normalized units/timezone)
	•	How to represent “same content” across clients
	•	Backward compatibility: allow “legacy profile name” mapping to hash/ID

6) Security / trust boundary (important for delegation)

At minimum:
	•	issuer identity model (API keys, OAuth identity, device identity)
	•	authority scopes (“override-only”, “suggest-only”, “can-approve”, “can-activate”)
	•	audit immutability expectations
Optional but valuable:
	•	signed events (controller signs with a device key)
	•	tamper-evidence (hash chain per issuer)

7) WebSockets: good idea, but make it optional

Real-time subscriptions are helpful, but:
	•	Start with cursor polling and/or SSE
	•	Add WebSockets after the event contract stabilizes
This reduces operational complexity early.

Questions to answer with Trio / Loop / AAPS going forward

These are the key “integration truth” questions that determine how cleanly they can emit native events and how well bridge mode works.

A) Profiles & overrides semantics
	1.	Do you have stable identifiers for a profile (beyond name)? If not, can you emit a content hash?
	2.	Can you represent overrides as:
	•	“template” (definition) vs “activation” (instance)?
	3.	What override dimensions exist today?
	•	target range vs single target
	•	sensitivity multiplier / autosens ratio
	•	carb ratio multiplier
	•	basal multiplier / max basal
	4.	How do you resolve multiple overrides? (precedence rules)

B) Composition
	5.	Do you compute an explicit “effective therapy settings now” object internally?
	6.	Can you emit:
	•	inputs referenced (profile hash + active override IDs)
	•	effective parameters (target range, effective ISF/CR adjustments, safety ceilings)
	•	controller version/build

If they can emit #5–#6, Nightscout’s digital twin becomes reliable without simulating their algorithm.

C) Delivery fidelity
	7.	Can you distinguish clearly between:
	•	suggested/recommended action
	•	requested command sent to pump
	•	pump-confirmed enactment
	8.	Do you have pump ACK/NAK/error codes that can be surfaced?
	9.	How do you represent “capped by limits” vs “could not enact due to comms”?

D) Timing and ordering
	10.	Can you provide monotonic ordering per controller? (sequence numbers)
If not, what clock guarantees exist?
	11.	How do you handle offline batching / delayed uploads?

E) Minimal payload commitment
	12.	What is the smallest “native event set” you’re willing to emit first?

	•	override activated/ended
	•	policy composed
	•	delivery observed summary

This determines Phase 1 adoption feasibility.

Net: plan is solid, but to be “complete” add these core pieces

If you add (1) Event envelope, (2) Capabilities model, and (3) Delivery request/observe/reconcile, you have a full, coherent control-plane that:
	•	stays neutral
	•	supports smart forms / CRD-like extensibility
	•	preserves MDI as first-class
	•	enables agents safely

If you want, I can turn this into a tight Phase 1–3 implementation plan with:
	•	collections/endpoints,
	•	bridge rules from devicestatus,
	•	and the minimal JSON Schemas (OverrideInstance + PolicyComposition + EventEnvelope) as actual draft-2020-12 schema files.