Product Owner Analysis: Automation Taxonomy for Phase 1 Pilot

Role: Product Owner, Automation-Analysis Team Date: 2026-02-12 Status: Proposal for cross-role review

---

1. Hypothesis

An "automation" in SecurityV0 is any configured artifact that can execute logic with standing authority, independent of whether it has recently run. The critical distinction is not "does it execute?" but "does it HAVE the capability to execute with consequences the organization has not accounted for?"

This means:

• A flow that touches sys_user and is wired to an external endpoint IS an automation worth tracking, even with zero executions in 30 days.
• A flow that runs 61 times a month but only shuffles internal Change approvals with no egress, no identity binding, and no sensitive data access is NOT a security-relevant automation for Phase 1 purposes.

The operating principle: standing authority + consequence surface = automation. Execution evidence escalates priority, not inclusion.

I reject the simpler hypothesis that "automation = has executions." That would exclude every dormant-but-armed flow -- precisely the zombie NHI scenario that is our core product thesis. A flow with an LLM endpoint, sys_user table access, and an expired owner is a finding waiting to happen regardless of whether it ran last month.

I also reject the broadest hypothesis that "every Flow Designer flow is an automation." The live data proves this is untenable: 77 of 92 identities are internal-only flows with zero egress, zero binding, and zero executions. Treating all of them equally buries the 15 that actually matter.

---

2. Tiered Taxonomy Proposal

Tier 1: ACTIVE EXECUTION -- Confirmed Running Automations

Definition: Has execution evidence in the last 30 days AND has at least one consequence signal (external egress, sensitive data domain, or identity binding).

Criteria (all must be true):

• execution_count_30d > 0
• At least one of:
  • egress_category in (external, llm, cloud)
  • data_domains intersects (hr, identity, customer, financial)
  • identity_binding_status == "bound"

From our live data (6 entities):

Entity	exec/30d	Egress	Data Domains	Binding
AI Triage via Azure OpenAI (Catalog Trigger)	3	llm	unknown	unlinked
Change - Normal - Authorize	61	none	unknown	unlinked
Change - Normal - Assess	1	none	unknown	unlinked
Validate Environments Job	14	none	unknown	unlinked
Run SC Notifications	53	none	unknown	unlinked
Service Catalog Request	5	none	unknown	unlinked

Honest assessment: Only the AI Triage flow (3 executions, LLM egress) truly qualifies for Tier 1 under my combined criteria. The other 5 have executions but no external egress, no sensitive data domains, and no identity binding. They are active but internal-only.

This reveals a gap in the taxonomy: we need to distinguish "active and dangerous" from "active and benign." I propose splitting Tier 1:

• Tier 1A: Active + Consequence Surface -- AI Triage flow (1 entity). This is the "your hair is on fire" tier.
• Tier 1B: Active + Internal-Only -- The 5 change/notification flows (5 entities). Operational monitoring, not threat surface.

MVP decision: Tier 1A is the default view. Tier 1B is shown with a single toggle. Enterprise customers care about 1A first.

Tier 2: CONFIGURED AUTHORITY -- Armed but Dormant Automations

Definition: Has a trigger configuration and at least one consequence signal, but zero executions in 30 days. The authority exists; the execution has not happened (or has not happened recently).

Criteria:

• execution_count_30d == 0
• At least one of:
  • egress_category in (external, llm, cloud)
  • identity_binding_status == "bound"
  • data_domains intersects sensitive domains AND execution_mode in (autonomous, operator_assisted)

From our live data (9 entities):

Entity	Egress	Binding	Risk Group
Auto-route identity tickets-Enta-no-own	external	bound	RG3
AzureGraphRouterNoOwner	external	bound	RG3
AzureGraphRouter	external	bound	RG3
Auto-route identity tickets via Entra	external	bound	RG3
sn-ticket-router (Graph)	-	bound	-
Azure Graph OAuth Client	-	bound	-
Azure OpenAI OAuth - sm	-	bound	-
Knowledge - Approval Publish	none	unlinked	RG4
[~2 more with dormant_authority classification]	varies	varies	varies

Product significance: These are the zombie NHIs. External egress endpoints configured. OAuth/SP bindings established. Zero recent activity. Either they stopped being used (so why do they still have permissions?) or they run infrequently and our 30-day window missed the cycle. Either way: they hold standing authority that has not been recently validated.

The Knowledge - Approval Publish flow is an edge case: execution_mode: unknown, triggers on sys_user (identity domain), owned by admin. Under the current classifier it is internal_inventory. But it TOUCHES IDENTITY DATA. I will address this in Section 4.

Tier 3: STATIC CONFIGURATION -- Template or Internal-Only Artifacts

Definition: No external egress, no identity binding, no execution evidence, no sensitive data access. These are standard business process workflows or unconfigured templates.

Criteria (all must be true):

• execution_count_30d == 0
• egress_category in (none, internal, unknown)
• identity_binding_status == "unlinked"
• data_domains does NOT intersect sensitive domains

From our live data: ~65-70 entities (the bulk of the 77 internal_inventory flows, minus any that touch sensitive tables)

Examples: "Procurement Process Flow - DEFAULT", "Incident - Close", "SLA Flow" -- standard out-of-box ServiceNow ITSM workflows.

Product significance: Zero for Phase 1. These are not automations in the security sense. They are platform configuration artifacts. No enterprise customer wants to review 65 procurement workflows when investigating NHI risk.

Tier 4: DORMANT -- Previously Active, Now Idle

Definition: Has historical execution evidence (from a prior sync or time window) but no current executions. Status may be active or disabled.

Criteria:

• execution_count_30d == 0
• Has prior execution evidence (from temporal comparison or status = disabled with prior activity)
• OR: status == "disabled" and has any consequence signal

From our live data: We cannot currently distinguish Tier 4 from Tier 2 because we only have a single 30-day execution window. We have no "was active, now idle" temporal signal.

Important for product roadmap: This tier requires the temporal model (Phase 4A in the reconciled roadmap). For Phase 1, Tier 4 collapses into Tier 2. I note this explicitly because "was active, now idle" is exactly the dormant authority finding -- and enterprise customers will ask for it in the first demo.

---

3. MVP Definition: What Enterprise Customers Need vs. Nice-to-Have

MUST HAVE (Phase 1 Gate)

1. Tier 1A entities visible by default. The AI Triage flow -- any automation with active execution AND external/LLM egress -- must be front and center. Sergey is right: homepage must show TOP RISKS BY BLAST RADIUS, not inventory counts.

2. Tier 2 entities visible with one click. The 4 business rules and 3 OAuth apps with dormant authority and external bindings -- these are the "zombie NHI" headline. Enterprise security teams will immediately ask: "Who owns these? When did they last run? What can they reach?" We must answer all three.

3. Per-automation evidence chain. For each Tier 1A/2 entity: trigger -> automation -> identity binding -> egress endpoint -> data domains touched. This is the execution path visualization. It already exists in the automation detail page (flow diagram + 6 info cards).

4. Ownership status per automation. Is there an active owner? Did the owner depart? Is it orphaned? The ownership_status property is already computed. Surface it prominently.

5. Risk group assignment (RG1-RG5). The egress x origin matrix. Already implemented in risk_grouper.py. Enterprise customers need this for triage.

6. Execution mode classification. autonomous vs operator_assisted vs human_triggered vs unknown. Already implemented. Customers need to know HOW automations trigger to assess remediation priority.

7. "Show all" toggle for full inventory. Tier 3 must be accessible but not default. Compliance teams need to prove they enumerated everything (PRD Section 1: "enumerate all automation constructs independent of execution"). The security_relevance filter handles this.

NICE-TO-HAVE (Phase 1 polish, not gate)

8. Delta view ("was -> is"). Sergey's request for risk reduction over time. Requires temporal model. Not Phase 1.

9. Remediation advice with inactive "Create Ticket" button. Sergey wants this. We can stub it: "Recommended: reassign owner, review permissions, rotate credential." Inactive button signals future capability.

10. Data sensitivity labels on entities. Sergey's "sensitivity of data is KEY" feedback. We have data_domains but not table-level sensitivity classification beyond the 4 default domain patterns. Expanding the origin classifier to include sensitivity (from the Resource entity's sensitivity property) is a Phase 2 enhancement.

11. Risk Class Reduction table. Sergey's monthly trend view. Requires multiple syncs over time. Not Phase 1.

EXPLICITLY OUT OF SCOPE (Phase 1)

12. business_flow entity type. The two-level model (template vs instance) is architecturally sound but too heavy. An automation IS its current configuration. Flow continuity across credential rotations is a post-MVP problem.

13. Platform-side security_relevance computation. Currently connector-side. Correct for Phase 1. Moving it platform-side is Phase 4I (after import-by-type ingestion).

14. Script-parsed table references. GlideRecord analysis from business rule / flow action code. Phase 2+ at earliest. First-party config fields only for Phase 1.

---

4. The 77 Internal Inventory Question

Are we hiding risk by filtering them?

Short answer: Mostly no, but with two exceptions that need attention.

The 77 flows classified as internal_inventory share these characteristics:

• ALL have execution_count_30d: 0
• ALL have egress_category in (none, internal, unknown)
• ALL have identity_binding_status: "unlinked"
• ALL are flow_designer_flow subtype
• 54 are status active, 23 are disabled
• 45 are execution_mode: autonomous, 10 operator_assisted, 22 unknown

The 45 "autonomous" internal_inventory flows are the most important to interrogate. These are event-driven or record-change-triggered flows that ServiceNow classifies as autonomous -- they WILL run when their trigger condition fires. They just happen to have no external egress, no identity binding, and no recent executions.

Risk assessment by subgroup:

Group	Count	Risk of hiding?
Autonomous + no egress + no sensitive data	~35	LOW. Standard ITSM workflows (Change, Incident, Request management). No path to external systems. No sensitive table access via first-party config.
Autonomous + no egress + touches sys_user	~5-8	MEDIUM. These write to or trigger on the sys_user table (identity data). Even without external egress, modifying identity records internally is a governance concern. The Knowledge - Approval Publish flow is in this group.
Operator-assisted + no egress	10	LOW. Human-initiated, internal-only. Service Catalog flows, approval workflows.
Unknown execution_mode	22	MEDIUM. These have trigger types our classifier does not recognize ("knowledge management", "created", "updated", "sla task"). We literally do not know how they execute.

Two specific risks of the current filtering:

Risk 1: The 22 "unknown" execution_mode flows. These are flows with trigger types we did not map: knowledge management, created, updated, sla task. The classifier defaults them to execution_mode: "unknown" and -- because they have no egress and no binding -- they get security_relevance: "internal_inventory" and are filtered out.

But "unknown" should not mean "safe." The trigger type created is almost certainly a record-create event trigger (autonomous). The trigger type sla task is likely autonomous (SLA timers fire on schedule). We are classifying unknowns as internal_inventory when we should be classifying them as "unknown_authority" -- a separate bucket that warrants human review.

Recommendation: Add created, updated to the _AUTONOMOUS_TRIGGERS set in transformer.py. Add sla task, sla_task to the same set. Re-evaluate knowledge management -- it appears to be a ServiceNow Knowledge Management module event trigger, which is autonomous (fires on article state change).

After this fix, the 22 "unknown" flows should collapse to <5 genuinely unknown, and the rest reclassify as autonomous. This does not change their security_relevance (still no egress/binding), but it gives us accurate inventory data.

Risk 2: Flows that touch identity tables without external egress. The Knowledge - Approval Publish flow TRIGGERS_ON sys_user. It touches identity data. Under the current classifier, it gets security_relevance: "internal_inventory" because:

• egress_category: "none" (no external endpoint)
• identity_binding_status: "unlinked" (no SP/OAuth binding)
• execution_count_30d: 0

But Sergey's feedback is explicit: "sensitivity of data is KEY." A flow that writes to sys_user -- even internally -- is modifying identity records. If it is owned by a departed admin, that is a finding.

Recommendation: Amend the security_relevance classification to promote flows touching sensitive data domains to dormant_authority regardless of egress/binding. The logic change in _enrich_automation_properties():

Current:
  No egress + no binding + no execution -> internal_inventory

Proposed:
  No egress + no binding + no execution + sensitive data domains -> dormant_authority
  No egress + no binding + no execution + no sensitive data -> internal_inventory

This would move an estimated 5-8 flows from internal_inventory to dormant_authority, surfacing them in the default view.

Bottom line on the 77:

Action	Count	Rationale
Keep as internal_inventory (hidden by default)	~62	No egress, no binding, no execution, no sensitive data. Standard ITSM noise.
Reclassify to dormant_authority	~5-8	Touches sensitive data domains (sys_user, hr_, customer_)
Fix execution_mode classification	~17-22	"unknown" trigger types that are actually autonomous or operator-assisted
Keep as genuinely unknown	<5	Truly unrecognizable trigger types

We are not hiding catastrophic risk. The 77 flows do not have external egress or identity bindings. But we ARE losing governance visibility on the 5-8 that touch identity data, and we ARE misclassifying 17-22 trigger types that have known semantics.

---

5. Sergey's Feedback Integration

"Homepage must shift to TOP RISKS BY BLAST RADIUS"

This fundamentally changes what counts as worth inventorying. Under the current model, we show 92 identity entities and let the user filter. Sergey wants the opposite: show the 1-3 highest-blast-radius automations and let the user drill down.

Implication for taxonomy: The tier system must feed directly into a "blast radius score" that is NOT the risk group (RG1-5). Risk groups are about egress x data sensitivity. Blast radius is about reachable resources. An RG3 entity (external egress, non-sensitive data) might have a larger blast radius than an RG2 entity (sensitive data, external egress) if the RG3 entity has 12 reachable resources vs. 2.

Recommendation for Phase 1: Surface the top 5 entities by blast radius on the homepage. Blast radius = count of resources reachable via EXECUTION_PATH (materialized paths). This already exists in the platform API (GET /api/v1/entities/:id/blast-radius). We need to sort by it.

"was -> is delta view"

Requires temporal model. Not Phase 1. But we CAN stub it: show the current risk distribution (RG1: 1, RG2: 0, RG3: 4, RG4: 5, RG5: 5) and note "Trend data available after second sync." This sets the expectation without blocking.

"Remediation advice + inactive Create Remediation Ticket"

For each tier:

Tier	Remediation Template
Tier 1A (Active + consequence)	"Review execution logs. Validate owner. Confirm egress endpoint is authorized. Rotate credentials if ownership gap found."
Tier 2 (Dormant authority)	"Verify whether this automation is still needed. If not, disable and revoke identity binding. If yes, assign active owner and document business justification."
Tier 3 (Internal inventory)	"No action required. Included for inventory completeness."

The inactive "Create Remediation Ticket" button is a 2-hour UI stub. Ship it.

"Origin should change to data domain"

Agreed. Rename "Origin" column to "Data Domains" in the Automations list page. Show data_domains values instead of source system. The origin_classifier already computes this.

"Sensitivity of data is KEY"

This validates the recommendation in Section 4 to promote sensitive-data-touching flows to dormant_authority. It also argues for enriching the origin classifier with a sensitivity tier:

data_domains: ["identity"]
data_sensitivity: "confidential"   // sys_user table

Phase 1: derive from the DEFAULT_DOMAINS mapping in origin_classifier.py (HR/identity/customer/financial = sensitive). Phase 2: customer-configurable sensitivity labels per table.

"Graph entity types need clearer labeling; data domains must be visible"

Two specific UI changes:

1. Node labels in the graph should show identitySubtype not just nodeType. "flow_designer_flow" is more informative than "identity."
2. Add a data domain badge to automation nodes in the graph (similar to finding badges).

---

6. Challenge Questions for Other Roles

For CISO: Does a dormant automation with access to identity data (sys_user) warrant inclusion?

My position: Yes, absolutely.

The Knowledge - Approval Publish flow triggers on sys_user, is owned by admin, has execution_mode: "unknown", and has zero executions. Under the current classifier, it is internal_inventory -- hidden from the default view.

But consider the scenario: the admin account is a shared account (common in ServiceNow). The actual humans behind "admin" may have turned over. Nobody knows this flow exists. It has a trigger that fires when knowledge articles are approved -- and it touches the sys_user table. If someone activates this flow (intentionally or via a configuration change), it modifies identity records with no human review.

The question for the CISO: Is the ABSENCE of execution evidence a comfort or a concern? I argue it is a concern -- dormant authority on identity tables is exactly the governance gap SecurityV0 is designed to surface. The flow may not have run because its trigger conditions have not been met, not because it is safe.

Specific data point: 54 of the 77 internal_inventory flows have status active. They are not disabled. They are armed and waiting for their trigger. That 8 of them (estimated) touch identity tables makes them governance-relevant even without external egress.

Challenge: If you agree, do we require ownership validation for ALL automations touching identity/HR/customer tables, or only those with additional risk signals (egress, binding)?

For Architect: Is the current execution_mode classification sufficient or do we need more categories?

My position: It is insufficient in two ways.

First, the unknown bucket is too large (22 flows, 24% of all identity entities). The trigger types created, updated, sla task, and knowledge management have known ServiceNow semantics that we have not mapped. This is not a fundamental architecture gap -- it is an incomplete trigger catalog. Fix: expand _AUTONOMOUS_TRIGGERS and _OPERATOR_ASSISTED_TRIGGERS in transformer.py.

Second, execution_mode is a TRIGGER classification, not an AUTHORITY classification. A flow with execution_mode: "operator_assisted" (service_catalog trigger) can have security_relevance: "active_external" (LLM egress + active executions). The two dimensions are orthogonal, which is correct architecturally. But we have no combined classification that answers: "What is the AUTHORITY MODEL of this automation?"

Proposed new dimension: authority_model

Value	Definition
standing_autonomous	Autonomous trigger + identity binding (SP/OAuth). Can execute anytime with standing credentials.
standing_delegated	Any trigger + identity binding. Executes under delegated authority (human initiates, SP executes).
session_inherited	Any trigger + "User who initiates the session" run-as. Authority borrowed from whoever triggers it.
unconfigured	No identity binding, no run-as configuration. Authority model unknown.

This would let us distinguish "flow that runs as service principal with admin role" from "flow that runs as the clicking user" -- a critical distinction for blast radius computation.

Challenge: Is this a Phase 1 addition or a Phase 4 design doc? I lean toward Phase 4 design doc, Phase 2 implementation, because the data to compute it (RUNS_AS edge targets) already exists.

For Integrator: Are the 22 "unknown" execution_mode flows a product problem or a data gap?

My position: Both, and the fix is in the connector, not the platform.

It is a data gap because the connector's _AUTONOMOUS_TRIGGERS set does not include trigger types that ServiceNow emits in practice. The values created, updated, sla task, and knowledge management are real trigger types from our live scan that fall through the classification logic.

It is a product problem because we present execution_mode: "unknown" to the customer without explaining what it means. "Unknown" suggests uncertainty, which undermines the deterministic evidence promise. The customer sees "unknown" and asks: "Don't you know how this runs?" We should know -- we just did not catalog all ServiceNow trigger types.

Fix (connector-side, pre-pilot):

1. Add created, updated to _AUTONOMOUS_TRIGGERS (these are record-event triggers)
2. Add sla_task, sla task to _AUTONOMOUS_TRIGGERS (SLA timer-based)
3. Add knowledge management, knowledge_management to _OPERATOR_ASSISTED_TRIGGERS (module event)
4. Any remaining unmapped types: keep as unknown but add a trigger_type_raw property so the customer can see exactly what we could not classify

Expected result: 22 "unknown" -> ~3-5 genuinely unknown, 17-19 reclassified.

Challenge: When we add new connectors (GitHub Actions, AWS Lambda), each will have its own trigger taxonomy. Should we standardize a cross-platform trigger type vocabulary now, or per-connector?

For Developer: What API changes would support this taxonomy?

Current state: The API already supports filtering by security_relevance and execution_mode via the entity query system. The GET /api/v1/entities endpoint accepts these as filter parameters.

Needed changes for Phase 1:

1. Blast radius sort. GET /api/v1/entities?sort=blast_radius_count&order=desc -- sort by number of reachable resources. Requires adding blast_radius_count as a computed/cached field on identity documents, or computing it at query time from execution_paths.length.

2. Tier filter. GET /api/v1/entities?tier=1a,2 -- shorthand for the combined criteria. Alternatively, keep it as composed filters: security_relevance=active_external,dormant_authority&execution_count_30d_gt=0.

3. Homepage summary endpoint. GET /api/v1/dashboard/risk-summary -- returns:

   {
     "topRisksByBlastRadius": [...top 5 entities...],
     "riskDistribution": { "RG1": 1, "RG2": 0, "RG3": 4, "RG4": 5, "RG5": 5 },
     "tierCounts": { "1a": 1, "1b": 5, "2": 9, "3": 65, "4": 0 },
     "totalAutomations": 92,
     "securityRelevant": 15
   }

4. Remediation template endpoint. GET /api/v1/entities/:id/remediation -- returns templated remediation advice based on the entity's tier, risk group, and ownership status. Stub for Phase 1: returns static text per tier.

Challenge: Should the tier classification live in the connector (current approach for security_relevance) or the platform? If the platform, the evaluator needs the tier rules. If the connector, we duplicate logic across connectors. My recommendation: connector emits the raw signals (execution_mode, egress_category, identity_binding_status, execution_count_30d, data_domains), platform computes tier at ingestion time. This is Phase 4I in the roadmap.

---

7. Phase 1 Gate Criteria

For the Phase 1 pilot to ship to enterprise customers, the following must be true:

P0 -- Hard Gate (ship cannot proceed without these)

#	Criterion	Current Status	Gap
G1	Every Tier 1A and Tier 2 automation is visible in the default view	PARTIALLY MET	Need blast-radius sort for homepage. Automations page shows them but not prioritized by risk.
G2	Per-automation evidence chain is complete and walkable	MET	Automation detail page shows trigger -> identity -> egress -> data domains. Flow diagram + info cards.
G3	Ownership status is visible and accurate	MET	ownership_status property computed. Displayed in automation detail. Orphaned/degraded findings fire correctly.
G4	Execution mode is classified for >90% of automations	NOT MET	22 of 92 (24%) are "unknown." Target: <5%. Fix: expand trigger catalog.
G5	No sensitive-data-touching automations are hidden in default view	NOT MET	~5-8 flows touching sys_user/HR tables are classified as internal_inventory. Fix: amend security_relevance logic to promote sensitive-data flows.
G6	"Show all" toggle exposes full inventory	MET	security_relevance filter on Automations page. Filter OFF shows all 92 identities.
G7	Evidence completeness declared per finding	MET	evidence_completeness block on every evidence pack. Categories: current_roles, role_history, execution_evidence, ownership_records, approval_records, credential_state.

P1 -- Soft Gate (should have, can ship without)

#	Criterion	Current Status
G8	Homepage shows top risks by blast radius	NOT STARTED. Dashboard shows summary counts, not prioritized risk list.
G9	Remediation advice per automation	NOT STARTED. Can stub with static templates per tier.
G10	Data domain labels visible in graph	NOT STARTED. Node labels show entity type, not data domains.
G11	Risk Class Reduction table stub	NOT STARTED. Needs "available after second sync" placeholder.

P2 -- Post-Pilot (explicitly deferred)

#	Criterion	Rationale for deferral
G12	"Was -> is" delta view	Requires temporal model (Phase 4A)
G13	Create Remediation Ticket (functional)	Requires ticketing integration
G14	Tier 4 (Dormant) distinction from Tier 2	Requires temporal baseline comparison
G15	authority_model classification	Design doc now, implement Phase 2
G16	Cross-platform trigger type vocabulary	Design doc now, implement per-connector

Specific Delivery Items to Clear P0 Gates

1. Expand trigger catalog (clears G4): Add created, updated, sla task, sla_task, knowledge management, knowledge_management to the appropriate trigger sets in transformer.py. Estimated: 2 hours + tests.

2. Promote sensitive-data flows (clears G5): Amend _enrich_automation_properties() in transformer.py to check data_domains before assigning internal_inventory. If data_domains intersects SENSITIVE_DOMAINS, classify as dormant_authority. Estimated: 2 hours + tests.

3. Blast radius sort on homepage (clears G1 fully): Add blast_radius_count computed field or query-time computation. Sort dashboard entities by descending blast radius. Estimated: 4-6 hours.

Total estimated effort to clear all P0 gates: 8-10 hours of engineering time.

---

Summary Position

The Phase 1 pilot should ship with a 4-tier taxonomy where the default view shows Tier 1A (active + consequence) and Tier 2 (dormant authority). The 77 internal_inventory flows should remain hidden by default, with two corrections: (a) fix the 22 misclassified trigger types, and (b) promote the ~5-8 flows touching sensitive data tables to Tier 2.

The MVP definition for enterprise customers is: show me what can hurt me, prove it with evidence, and tell me who is accountable. Tier 1A and Tier 2 answer that. Everything else is inventory for compliance.

Sergey's "top risks by blast radius" vision is correct and should drive the homepage redesign. The tier taxonomy feeds directly into a blast-radius-sorted risk view. The 8-10 hours of engineering work to clear the P0 gates are the highest-leverage investment before pilot delivery.