Vision Alignment Analysis — Product Owner Perspective
Date: 2026-02-17 Author: Product Owner perspective analysis Input documents: Docs 06, 07 (4-concept model + naming plan), Sergey's vision, W1 definition/scope/logic/UX, Sergey's feedback
1. Vision Alignment Assessment
Where docs 06/07 and W1 align strongly
The 4-concept model (doc 06) and Sergey's W1 vision share a core principle: the user-facing product must present deterministic, evidence-backed exposure — not graph internals. Both explicitly agree on:
- Execution authority is the unit of concern, not static identity inventory (vision.md line 73; doc 06 section 3.1).
- Proven vs unproven execution must be a first-class, explicit distinction — no inference allowed (W1 scope section 2.3; doc 06 section 4.1 CSO/CISO).
- Topology/chains are internal mechanics, not the primary W1 surface (W1 scope section 3: "W1 does not require execution_chains persistence"; doc 06 section 3.2: "AutomationTopology can remain internal/secondary").
- W1 defers runtime run persistence to W2 (doc 06 section 7; W1 scope section 3: "chain versioning" explicitly out of scope).
- Unknown is a valid result, not an error (W1 logic section 8; doc 06 section 3.1: "Unknown must be explicit").
Where they diverge
| Area | Docs 06/07 | Sergey's W1 vision | Tension |
|---|---|---|---|
| Primary user-facing unit | Proposes "Exposure Unit" as a new projection concept (doc 06 section 5) | Uses "finding" as the primary unit, grouped into "Autonomous Authority Risk Clusters" (W1 UX section 2) | Doc 06 introduces a new concept ("ExposureUnit") that W1 UX never mentions. W1 works with existing findings + cluster aggregation. |
| Navigation model | Implies topology and runtime as parallel views ("What can run?" vs "What did run?" — doc 06 section 4.5) | Mandates a single investigation flow: Homepage -> Risk Cluster -> Findings -> Expand -> Detail. "No alternate navigation. No graph browsing mode." (W1 UX section 4) | Doc 06/07 assume the user needs to see topology and runtime separately. W1 UX explicitly rejects multi-path navigation. |
| Language register | Uses engineering/architecture terminology: "AutomationTopology", "ExecutionEvidenceEvent", "AutomationRun", "ExposureUnit" (doc 06 section 5 table) | Uses CISO-facing governance language: "Autonomous Authority Risk Clusters", "Standing Authority", "Execution Mode: Autonomous", "Ownership Decay" (W1 UX throughout) | Doc 06/07 solve an internal architecture naming problem. W1 UX solves a buyer communication problem. These are different audiences. |
| Execution count label | Proposes "Observed Runs (30d)" (doc 06 section 4.5; doc 07 Q2) | Uses "Executions (30d)" (W1 UX section 2A, section 3C) | Direct conflict. W1 UX already decided on the label. |
| Risk velocity / delta | Not addressed | Sergey's feedback explicitly demands "was -> is" delta view, risk velocity table, monthly trend (feedback items 1, 2) | Doc 06/07 are silent on temporal delta. W1 UX includes "Since Last Refresh" delta. Sergey's feedback pushes further. |
Assessment: Docs 06/07 provide valid internal architecture clarity but their user-facing naming proposals are not aligned with the language register Sergey's W1 UX has already chosen. The architectural separation is correct; the proposed labels need to be adapted to W1's governance vocabulary.
2. UX Language Audit
Direct naming comparison
| Concept | Doc 07 proposal | W1 UX spec (Sergey) | Alignment |
|---|---|---|---|
| Execution count column | "Observed Runs (30d)" | "Executions (30d)" | Conflict. W1 UX uses "Executions (30d)" in finding rows (UX section 2A) and evidence panel (UX section 3C). |
| Chain page name | Options: "Authority Chains", "Configured Chains", "Automation Chains", "Topologies" | Not present in W1 UX. W1 has no chain/topology page in its navigation flow. | No conflict because W1 does not expose this page. The naming question is moot for W1. |
| "Last Seen" on chains | "Last Computed" or "Last Synced" | W1 UX uses "Last Refreshed" for sync timestamp, "Last Execution" for runtime (UX section 3C, section 6) | Partial alignment. "Last Refreshed" is the W1 equivalent of "Last Computed" — same intent, different words. W1 already resolved this. |
| Runtime vs configured badge | "Configured" vs "Observed" badges (doc 06 section 4.5) | Not explicit badges. W1 uses "Execution Mode: Autonomous" and "proven/unproven" as the relevant status indicators (UX section 2A, section 3B). | Different framing. W1 does not need configured/observed badges because it presents one unified investigation flow, not side-by-side views. |
| Path presentation | "Execution Chain" or "Automation Topology" | "Automation -> Identity -> Destination -> Data Domain" (UX section 2A, section 3A) | W1 never calls this a "chain" or "topology." It presents it as a linear deterministic path. No label for the path concept itself. |
What naming serves the W1 demo "wow" moment best
Sergey's demo moment (W1 definition section "Demo moment definition"):
A CISO opens the W1 view, clicks an automation they did not previously recognize, and immediately sees a deterministic path showing it runs as an unexpected identity, reaches sensitive data, and has LLM egress. Leading to: "I didn't know this existed" or "That can reach THAT?"
The naming that serves this moment:
-
"Executions (30d)" — better than "Observed Runs (30d)" because "executions" is action-oriented and immediately communicates magnitude. "Runs" sounds like test runs. A CISO hearing "this automation had 847 executions last month" reacts more strongly than "847 observed runs."
-
"Autonomous Authority Risk Clusters" — this is the W1 grouping mechanism. It tells the CISO story: these are not just findings, they are clusters of autonomous authority risk. No doc 06/07 equivalent exists.
-
"Standing Authority" — W1 UX section 3B makes this visually dominant. This is more impactful than any doc 06/07 terminology because it frames the problem as persistent governance risk, not technical graph state.
-
The path should remain unlabeled as a concept — "Automation -> Identity -> Destination -> Data Domain" is self-explanatory. Calling it a "topology" or "chain" adds jargon that dilutes the instant comprehension.
3. User Journey Coherence
W1 investigation flow (from UX spec)
Homepage (5-second control view)
-> Top 5 Autonomous Authority Risk Clusters
-> Findings View (grouped by cluster)
-> Inline Expand (evidence summary, ownership, completeness)
-> Finding Detail (standing authority, evidence panel, linkage proof)
"No alternate navigation. No graph browsing mode." (W1 UX section 4)
Does W1 need the topology/runtime separation exposed?
No. The separation should be hidden behind the scenes.
Reasoning:
-
W1 UX explicitly forbids multi-path navigation. There is one flow. Exposing "what can run" vs "what did run" as parallel views violates section 4's design constraint.
-
W1 already handles the proven/unproven distinction inline. The finding row shows "Last Execution" and "Executions (30d)" — if there is no execution evidence, the status shows "unproven." The user does not need to navigate to a separate topology view to understand this.
-
W1's path diagram is intentionally simplified. "Automation -> Identity -> Destination -> Data Domain" — no hop count, no chain depth, no credential posture (UX section 3A). Exposing topology as a separate concept works against this simplification.
-
Sergey's feedback reinforces simplification. "I'm also on the fence about simplifying it to 'automation -> auth (e.g. SP) -> destination -> data domain'" (feedback). The direction is toward fewer concepts, not more.
How the 4-concept model should map to W1's pages
| Doc 06 concept | W1 page | How it appears |
|---|---|---|
| AutomationDefinition | Homepage posture summary | Count of "Active Non-Human Execution Identities" + "Dormant Authority Identities" |
| ExposureUnit (proposed) | Finding row | Each finding row IS effectively an exposure unit: Automation -> Identity -> Destination -> Data Domain with execution status, ownership, egress |
| AutomationTopology | Not exposed | Internally used for path computation. Not a user-facing page or concept in W1. |
| ExecutionEvidenceEvent | Finding Detail, Evidence Panel section 3 | "Last Execution", "Executions (30d)", "Last action", "Outcome" — evidence surfaced within the finding, not as a separate view |
Key insight: Doc 06's "ExposureUnit" projection is conceptually identical to what W1 UX already defines as a finding row. There is no need to introduce "ExposureUnit" as new user-facing terminology. Internally, the platform may compute exposure projections, but the user sees findings grouped into risk clusters.
4. Naming Decision Matrix (Q1-Q5)
Q1: What should we call Concept 2 (currently "Execution Chains")?
Recommendation: Keep "Chains" internally but do not surface the concept in W1 at all.
W1 UX has no chains page. The investigation flow goes Homepage -> Risk Clusters -> Findings -> Detail. Chains are a computation mechanism, not a user-facing concept.
For non-W1 platform surfaces (developer tools, advanced views), "Authority Chains" is the strongest option:
- "Authority" is CISO language (aligns with "Standing Authority" from W1 UX section 3B)
- "Chains" is a familiar metaphor
- It answers the right question: "what authority does this automation chain through?"
Avoid: "Topologies" (network engineering jargon), "Configured Chains" (vague — configured by whom?), "Automation Chains" (still implies runtime).
Q2: What column header for execution count?
Recommendation: "Executions (30d)"
This is what W1 UX spec already uses (section 2A, section 3C). It is direct, action-oriented, and immediately communicates magnitude.
Reject "Observed Runs (30d)" — it introduces unnecessary qualification ("observed" implies there might be unobserved ones, which is true but distracting; "runs" sounds like test runs, not production execution).
A CISO needs to hear "847 executions in 30 days" — that communicates urgency. "847 observed runs" does not hit the same way.
Q3: What timestamp label on chain detail pages?
Recommendation: "Last Refreshed"
W1 UX already uses "Last Refreshed" as the sync timestamp (section 6). For any internal/non-W1 chain detail view, "Last Refreshed" maintains consistency.
Reject "Last Computed" — accurate but too technical. "Refreshed" is the W1 vocabulary. Reject "Last Synced" — internal engineering term. Users do not think in "syncs." Reject "Last Observed" — ambiguous, could imply runtime observation (the exact confusion doc 06 identified).
Q4: Should the glossary upgrade from 3-concept to 4-concept model?
Recommendation: B — Add the 4th concept now as "planned."
Rationale:
- The glossary is an internal/developer-facing document, not user-facing UX.
- Setting the conceptual framework now prevents future confusion when AutomationRun infrastructure lands in W2.
- Clearly marking it as "planned / W2" sets expectations without implying it exists today.
- The alternative (waiting) risks the 3-concept model calcifying and making the W2 transition harder.
Q5: Nav item for the chains/topology page?
Recommendation: Do not include this page in W1 navigation.
W1 UX section 4 is explicit: "No alternate navigation. No graph browsing mode." The W1 nav should be:
- Homepage (risk clusters + posture)
- Findings (grouped by cluster)
- Finding Detail
If a chains/topology page exists as a non-W1 advanced feature, use "Authority Chains" with a Shield icon. But it should not appear in the W1 experience.
5. Gaps and Contradictions
What Sergey's vision demands that docs 06/07 do not address
| Gap | Sergey's requirement | Doc 06/07 status |
|---|---|---|
| Risk Clusters | "Top 5 Autonomous Authority Risk Clusters" as the primary homepage unit (W1 UX section 1B). Clusters are compound governance conditions (e.g., "Sensitive + LLM + Active + Invalid Owner"). | Not mentioned in docs 06/07 at all. Doc 06 mentions "deterministic risk clusters" as "not implemented" (section 6 table) but provides no model for them. |
| Risk velocity / "was -> is" | Sergey's feedback demands delta view, risk velocity table, and monthly trend. W1 UX includes "Since Last Refresh" delta line (section 1A). | Docs 06/07 are entirely silent on temporal delta and risk velocity. |
| Execution Mode classification | W1 UX requires explicit "Execution Mode: Autonomous", "Human Session Required: No" on every finding (section 2A, section 3B). | Docs 06/07 do not address execution mode classification or the autonomous/operator-assisted/human-triggered taxonomy that W1 UX section 1A introduces. |
| Remediation placeholder | Sergey's feedback: "add a 'Create Remediation Ticket' button that's inactive." W1 UX section 3F includes disabled remediation button. | Not addressed in docs 06/07. |
| Egress classification in path | W1 UX makes egress category a first-class element in every finding row (section 2A). | Doc 06/07 mention egress only in the ExposureUnit shape (doc 06 section 5), not as a naming concern. |
| Sensitive domain emphasis | Sergey's feedback: "sensitivity of data is key — show it on the graph and in findings." W1 UX section 3E: "Sensitive Domains Reached." | Docs 06/07 do not address data sensitivity naming or presentation. |
Concepts in docs 06/07 that W1 explicitly excludes
| Doc 06/07 concept | W1 exclusion |
|---|---|
| AutomationTopology as a user-facing view | W1 scope section 3: "W1 does not require execution_chains persistence." W1 UX section 4: "No alternate navigation." |
| AutomationRun persistence | W1 scope section 3: explicitly out of scope. Doc 06 correctly defers to W2. |
| Topology drift/versioning | W1 scope section 3: "No drift detection." W1 definition: "Drift detection / change monitoring over time" explicitly excluded. |
| "What can run?" vs "What did run?" parallel views | W1 UX section 4: single investigation flow. No dual-view model. |
| Chain role naming alignment (doc 07 section 7, item 2) | Valid engineering fix but irrelevant to W1 UX. Can be done independently. |
What should be deferred vs resolved now
Resolve now (blocks W1 UX implementation):
- Adopt "Executions (30d)" as the canonical label (not "Observed Runs")
- Adopt "Last Refreshed" as the canonical sync timestamp label
- Do not expose chains/topology page in W1 navigation
- Define the risk cluster aggregation model (docs 06/07 are silent; W1 UX demands it)
- Define the execution mode taxonomy: Autonomous / Operator-Assisted / Human-Triggered (W1 UX section 1A)
Resolve now (does not block W1 but prevents confusion):
- Update glossary to 4-concept model with W2 placeholder (Q4 = option B)
- Fix stale API doc about automations stored as identities (doc 07 section 7, item 1)
Defer to W2:
- AutomationRun persistence
- Topology drift/versioning
- Chain fingerprinting
- "Authority Chains" page naming (no chains page in W1)
- "Was -> is" temporal comparison beyond "Since Last Refresh" delta (Sergey's full risk velocity table is aspirational — W1 UX limits it to the delta line)
Summary
Docs 06/07 solve a real internal architecture problem: the platform conflates configuration-time topology with runtime execution proof. The 4-concept separation is architecturally correct and should be adopted internally.
However, for W1's user-facing product, the naming proposals in docs 06/07 are misaligned with Sergey's chosen language register. W1 speaks in governance and authority terms ("Autonomous Authority Risk Clusters", "Standing Authority", "Execution Mode: Autonomous", "Executions (30d)"), not in engineering/architecture terms ("AutomationTopology", "Observed Runs", "ExposureUnit").
The right path forward:
- Adopt the 4-concept model as internal architecture vocabulary.
- Use Sergey's W1 UX vocabulary for all user-facing surfaces.
- Do not expose topology as a W1 concept — it is a computation mechanism.
- Focus naming decisions on what a CISO processes in 5 seconds, not what an architect models in a whiteboard session.
- Prioritize the gaps docs 06/07 do not cover: risk cluster model, execution mode taxonomy, and sensitive domain emphasis.