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 to users with broad tenant-management permission. 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.

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.

The wording matters here too. “NOC Configuration” can be a misleading label when the page contains Twilio instances and other system-managed surfaces. A better label is “System Configuration” or an equivalent that makes the admin/system nature explicit.

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.

But two settings sit on the boundary:

• Loop count: how many times the system should cycle through the list before calling the attempt exhausted.
• Ring duration: how long each person gets before the system moves on.

Loop count 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 duration smells more like a Strike-owned system guardrail. It affects call UX, costs, worker timing, callback behavior, and failure predictability. It may need a bounded override, but it should start as a product default rather than an unbounded tenant knob.

This is not fully settled. The useful move is to document the pressure-test explicitly instead of hiding it inside generic “callout policy” language.

The policy split to validate

The working split is:

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.
Loop count	Likely NOC intent with OSP input	It defines how hard to pursue this engagement before escalation or failover.
Ring duration	Likely Strike default/guardrail with bounded override	It touches telephony behavior, cost, timing, and failure semantics.

The table is deliberately not an ADR yet. It is a validation model.

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 stop saying the wrong thing

The current documentation should use three 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.

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. Loop count and ring duration need validation. Treat them as boundary questions, not settled tenant knobs.

• Which callout settings are engagement intent, and which ones are telephony reliability guardrails?
• What product label best communicates that Twilio setup is system/admin configuration rather than NOC-owned configuration?
• What evidence would move loop count or ring duration 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.