NOC-Scoped Does Not Mean NOC-Owned

architecturedomainoperations

The mistake is easy to make: a system creates one Twilio subaccount per NOC, stores that SID on the NOC tenant, and then everyone starts saying the NOC owns Twilio.

That sentence is too strong. It turns an isolation boundary into an ownership claim.

The cleaner model is this: Strike owns telephony as managed product infrastructure. A NOC may have NOC-scoped phone-number context, reporting, and callout identity, but it does not administer Twilio, choose webhooks, manage credentials, or tune the low-level call machinery. The NOC’s job is to express operational intent. Strike’s job is to execute that intent reliably.

This matters because ownership language tends to become product behavior. If the docs say the NOC owns Twilio, the UI will drift toward exposing Twilio as tenant configuration. Support will talk as if Twilio problems belong to the NOC. Security review will ask why tenant operators can touch a platform account surface. Eventually the architecture has to claw back a boundary the language already gave away.

The boundary is scope, not ownership

ADR-003 makes two statements that have to be read together.

First, NOC tenants have their own Twilio subaccount for phone numbers. Second, the Twilio integration requires a per-NOC subaccount SID, but the subaccount does not use separate credentials; billing rolls up to the main account; access happens through main credentials plus the subaccount SID.

That is not NOC ownership. It is Strike-owned infrastructure partitioned by NOC context.

The distinction is the same one teams make in other multi-tenant systems. A customer may have a tenant-scoped database row, bucket prefix, queue name, or API key reference. That does not mean the customer owns the database cluster, the storage account, the queue service, or the secret manager. Scope answers “which tenant is this for?” Ownership answers “who is accountable for operating and changing this surface?”

For Twilio in Strike, those are different answers.

Strike owns telephony execution

Strike should treat Twilio the way a product treats payment processing, search indexing, or audit logging: as infrastructure behind a product contract. Tenants may see outcomes and tenant-scoped identifiers. They should not inherit the infrastructure surface.

Strike owns:

• Twilio account and subaccount administration,
• credentials and secret handling,
• webhook endpoints and validation,
• call-flow templates and execution code,
• default timeouts and retry mechanics,
• failure handling and alerting,
• auditability and operational support,
• billing-root and usage-accounting integration.

That ownership line also matches the current product shape. The frontend exposes NOC configuration only through the shared NOC config access predicate, which is intentionally narrower than ordinary NOC membership. The implementation already treats this area as a system/admin surface, not ordinary NOC operator workflow.

That is good. A NOC operator should not have to understand Twilio to create an emergency callout. They push “Create ECO” and Strike does the rest.

If a call fails because a webhook is misconfigured, a credential expired, a callback was rejected, or the call-flow state machine wedged, that is not a NOC configuration problem. It is a Strike product/infrastructure problem.

System Configuration is a nav signal, not a full rename

Strike has now changed the sidebar label from “NOC Configuration” to “System Configuration,” which is the right product signal for a page that contains Twilio instances and other system-managed surfaces. The underlying route remains /noc/{id}/config, transitional loading and error states still say “NOC Configuration,” and the loaded page header resolves to the tenant name after the short NOC identifier is mapped to the canonical tenant ID.

That mixed wording is acceptable only if the ownership story remains clear. The sidebar label should carry the main product signal: this is system configuration scoped to a NOC, not a NOC-owned Twilio administration console.

That surface also now includes callout-policy fields for ring timeout, maximum call attempts, and an escalation phone number. The per-field reset behavior matters: clearing one of these fields returns it to not-configured instead of pretending every tenant must own a number.

Those fields still need careful framing. They belong on a system/admin surface as bounded policy, not in a story where NOC operators own Twilio.

NOCs own engagement intent

This does not mean the NOC has no ownership. It means the NOC owns a different layer.

The NOC owns the operational decision to start the callout. It owns which OSP relationship is appropriate for the ECO, what cross-OSP failover should mean, and what retry policy makes sense for its operating model. A rule like “retry after 20 minutes” is not Twilio plumbing. It is an engagement policy that tells the product how persistent the callout should be.

That intent should be modeled as product configuration or policy, then executed by Strike. The NOC should not have to open Twilio, change a Studio flow, edit a webhook, or inspect a call list to express that intent.

A good product boundary lets the NOC say what it wants to happen without giving it the tools to accidentally own how telephony happens.

OSPs own reachable people

The OSP owns the people side of reachability.

That includes who can be called, the order of contacts, regional coverage, substitutions, and the operational expectation for who is responsible when an ECO lands. Those are not Strike’s people and they are not the NOC’s staff. They are the OSP’s field-response capacity.

This fits the rest of the two-tenant model. The NOC creates and tracks the ECO. The OSP receives and works it. Pager lists are part of the OSP execution surface because they identify the people who can actually respond.

Three settings now sit explicitly on the System Configuration boundary:

• Maximum call attempts: how many times the system should cycle through the list before calling the attempt exhausted.
• Ring timeout: how long each person gets before the system moves on.
• Escalation phone: the fallback route when the configured callout path needs another human endpoint.

Maximum call attempts smells more like incident engagement intent. A NOC may reasonably say, “Try this hard before failover,” while the OSP supplies input about what is operationally realistic for its team.

Ring timeout smells more like a Strike-owned system guardrail. It affects call UX, costs, worker timing, callback behavior, and failure predictability. The product now exposes it as a bounded policy field, and the reset behavior matters: clearing the value returns the instance to the system default instead of pretending every tenant must own a number.

Escalation phone is not a Twilio control-plane setting, but it is also not ordinary roster data. It is an operational escape hatch. Keeping it beside the other callout-policy fields is reasonable if the docs keep saying what it is: a system-managed fallback endpoint, not proof that the NOC owns Twilio.

This is more settled than it was when the article first shipped, but it still needs pressure-testing. The useful move is to document the policy fields explicitly instead of hiding them inside generic “callout policy” language.

The policy split to validate

The working split is now:

Layer	Likely owner	Why
Twilio account, numbers, credentials, webhooks, flow mechanics	Strike	This is platform plumbing and support responsibility.
Create ECO, OSP selection, cross-OSP failover, retry-after-20-min	NOC intent, Strike executes	These are engagement rules, not Twilio administration.
Contact roster, order, coverage, substitutions	OSP	These are the OSP’s reachable people and field-response model.
Maximum call attempts	Likely NOC intent with OSP input, bounded by Strike	It defines how hard to pursue this engagement before escalation or failover.
Ring timeout	Strike default/guardrail with bounded override	It touches telephony behavior, cost, timing, and failure semantics.
Escalation phone	System-managed fallback endpoint	It is routing policy for an exception path, not Twilio account ownership or OSP roster management.

The table is deliberately not an ADR yet. It is a validation model, updated to match the System Configuration UI.

The next question is not “who wants this knob?” Everyone can make a plausible claim to some knobs. The better question is “what kind of thing is this knob?” If it changes product reliability or low-level telephony behavior, Strike probably owns the guardrail. If it expresses incident engagement strategy, the NOC probably owns the intent. If it describes which humans can respond, the OSP probably owns the data.

The docs should track the product wording

The current documentation should use four phrases consistently:

• NOC-scoped Twilio context for subaccount identity, phone-number context, reporting, and tenant attribution.
• Strike-owned telephony plumbing for credentials, webhooks, account administration, billing root, execution flows, and failure handling.
• OSP-owned contact rosters for the people, order, regional coverage, and substitutions used during ring-down.
• System Configuration callout policy for ring timeout, maximum attempts, and escalation phone, including reset-to-default behavior.

When the UI has to mention the old page shape, it should distinguish the route or tenant context from the ownership model: NOC-scoped route, system-owned configuration surface.

That change preserves ADR-003’s partitioning decision without turning it into a false ownership claim.

It also gives product and support a crisp answer when someone asks who owns Twilio: Strike does. The NOC owns engagement intent. The OSP owns its reachable people. The system keeps those responsibilities connected without pretending they are the same thing.

1. NOC-scoped is not NOC-owned. A Twilio subaccount SID gives Strike tenant context; it does not hand Twilio administration to the NOC.
2. Strike owns telephony execution. Credentials, webhooks, flows, defaults, failure semantics, support, and billing-root behavior are platform responsibilities.
3. NOCs own engagement intent. They decide when and how the incident should engage field response, while Strike executes through product behavior.
4. OSPs own reachable people. The roster and order belong with the organization whose people are being called.
5. Callout-policy fields need explicit framing. Ring timeout, maximum attempts, and escalation phone belong on a NOC-scoped System Configuration surface with bounded reset behavior, not in a story where the NOC owns Twilio.

• Which callout settings are engagement intent, which are telephony reliability guardrails, and which are fallback routing policy?
• Does the System Configuration label keep Twilio setup clearly in the system/admin category as more policy fields are added?
• What evidence would move maximum attempts, ring timeout, or escalation phone from one ownership bucket to another?

1. Two Tenants, One ECO - The deeper tenancy model this cairn refines.
2. The Shape of the System - The architectural overview where the Twilio ownership wording needed correction.
3. Three Gates, One Identity - Related trust-boundary framing for browsers, webhooks, and upstream APIs.
4. Boundary Objects for Operational Software - Why shared operational objects can carry different meanings for different teams.
5. Twilio REST API: Subaccounts - Twilio's subaccount model, useful background for the scope-versus-ownership distinction.