Vision Alignment Analysis — CISO Perspective on Docs 06/07 vs W1 Product Vision

Date: 2026-02-17 Author perspective: CISO / CSO advisory lens Scope: Evaluate alignment between docs 06/07 (definition-vs-runtime separation model) and Sergey's W1 product vision, UX spec, and feedback.

---

1. Alignment Assessment

Where docs 06/07 align with W1 vision

The 4-concept separation model in doc 06 is structurally sound and maps well to the W1 vision in several important ways:

1. Deterministic evidence chain. The separation between "topology answers CAN" and "run answers DID" directly supports the vision's requirement that every finding be backed by first-party evidence. A CISO reviewing W1 output needs exactly this distinction: what authority is configured vs what has been exercised.

2. Unknown as first-class output. Doc 06's proven/unproven execution status and the W1 logic doc's unknown handling are aligned. Both refuse to infer. This is the right posture for a CISO audience — a system that says "we cannot prove this executed" is more trustworthy than one that guesses.

3. W1-first phasing. Doc 06 correctly identifies that AutomationRun persistence is not needed for W1, and that the primary surface should be a deterministic exposure projection. This matches W1 scope (no chain versioning, no drift, no fingerprinting).

4. ExposureUnit projection shape. The proposed ExposureUnit in doc 06 section 5 maps directly to the W1 UX finding row: Automation -> Identity -> Destination -> Data Domain plus execution status, egress category, and ownership status.

Where gaps exist

1. Authority governance framing is absent from docs 06/07. Sergey's vision and the W1 UX spec consistently frame the product as authority governance, not inventory. The homepage "must feel like authority governance, not inventory" (UX spec section 1). Docs 06/07 are written in a data modeling and architecture voice — they separate concepts cleanly but do not adopt the authority governance language. This is a gap: the CISO-facing model needs to carry the governance framing through every layer, including internal architecture naming.

2. Risk clusters are not addressed. The W1 UX spec defines "Top 5 Autonomous Authority Risk Clusters" as the primary homepage surface. Docs 06/07 do not account for how the 4-concept model supports cluster formation. The implementability matrix in doc 06 section 6 flags this as "Medium" feasibility but does not define how clusters relate to AutomationDefinition, Topology, or Evidence.

3. Execution magnitude is underweight. Sergey's feedback and the W1 UX spec emphasize execution count (30d) as a core signal — not just binary proven/unproven, but how active the authority is. Doc 06 defines execution_status as binary (proven | unproven). The W1 UX requires quantitative magnitude (e.g., "Executions (30d): 4,712"). This is not a conflict, but doc 06 should acknowledge that magnitude is a required W1 attribute alongside status.

4. "Since Last Refresh" delta is not modeled. The W1 UX spec requires a delta line showing "+X new autonomous identities" since last refresh. Docs 06/07 do not address how definition-vs-runtime concepts support delta computation. This belongs in the W1-A implementation phase.

5. Standing Authority is not a named concept. The W1 UX spec prominently features "Standing Authority" as a section in every finding detail view (Execution Model: Autonomous / Authentication Type: Client Credentials / Human Session Required: No). Docs 06/07 do not name or define "Standing Authority" as a concept despite it being the central governance assertion W1 makes.

---

2. Terminology Recommendations (CISO Lens)

2.1 Language convergence assessment

The vision and W1 docs use a specific vocabulary:

W1 / Vision term	Doc 06/07 equivalent	Alignment
Autonomous Authority Risk Cluster	Not named	Missing
Standing Authority	Not named	Missing
Active Non-Human Execution Identity	Partially covered by execution_status: proven	Incomplete — missing magnitude
Dormant Authority	Partially covered by execution_status: unproven	Semantic mismatch (see below)
Execution Model: Autonomous	Not named	Missing
ExposureUnit	Defined in doc 06 section 5	Aligned
AutomationTopology	execution_chains renamed	New internal term
AutomationRun	Deferred to W2	Correctly scoped

Critical mismatch: Dormant Authority. In the W1 UX spec, "Dormant Authority Identities" means "no execution in last 30 days; authority still present." In the existing evaluator, dormant_authority is a finding rule with a 90-day threshold. Doc 06's binary proven/unproven does not capture the temporal nuance of "has authority, has not recently exercised it." This needs reconciliation before W1 ships — the CISO audience expects "dormant" to mean "standing authority without recent activity," not "structurally unreachable."

2.2 Which naming serves a CISO audience

A CISO consuming W1 output does not think in platform data model terms. They think in governance questions:

• "What authority exists?" (not "what topology is configured")
• "Is it exercised?" (not "did an AutomationRun occur")
• "What can it reach?" (not "what is the data reachability classification")
• "Who is accountable?" (not "what is the ownership_status enum value")

The 4-concept model is correct as an internal architecture model. But the external / CISO-facing naming should use:

Internal concept	CISO-facing term	Rationale
AutomationDefinition	Automation	Familiar, no change needed
AutomationTopology	Authority Path (or Authority Chain)	"Authority" anchors the governance narrative; "path" matches the W1 UX linear diagram
AutomationRun (W2)	Execution Instance	Standard; deferred
ExecutionEvidenceEvent	Execution Evidence	Drop "Event" — CISOs think in evidence, not events
ExposureUnit	Exposure (or Exposure Finding)	Already aligned with W1 definition
(not named)	Standing Authority	The governance assertion: this identity has persistent autonomous execution capability

2.3 Audit/compliance narrative impact

The current naming in doc 07 creates a subtle but real compliance risk: "Execution Chain" sounds operational. An auditor reading "Execution Chain" will ask "when did this chain execute?" — which is the wrong question for a topology artifact. Renaming to "Authority Chain" or "Authority Path" shifts the auditor's mental model to "what authority does this chain grant?" — which is the correct W1 question.

For SOC 2 or ISO 27001 narratives, the distinction between "configured authority" and "exercised authority" is directly mappable to control effectiveness assessment. The 4-concept split in doc 06 supports this well if the naming carries the governance framing.

---

3. Evidence and Control Framing

3.1 Configured topology vs runtime execution — does it match W1's evidence model?

Yes, with refinement. The separation is exactly what a deterministic evidence model requires:

• Configured topology ("can this path exist?") produces the standing authority assertion: this automation has an execution identity, that identity has roles, those roles grant access to these resources. This is the structural exposure that persists regardless of whether anything ran.

• Runtime execution ("did this path execute?") produces the activity assertion: this authority was exercised at time T with outcome Y. This is the proof that the standing authority is not merely theoretical.

W1's deterministic model needs both, presented as a unified finding with layered evidence — not as separate views that a CISO must mentally join.

The finding row format in the W1 UX spec (Automation -> Identity -> Destination -> Data Domain with execution magnitude and ownership) is the correct unified presentation. The underlying 4-concept model supports it. But the implementation must ensure the W1 projection assembles both topology evidence and execution evidence into a single coherent finding, not two side-by-side artifacts.

3.2 CISO framing under "authority governance, not inventory"

Sergey's feedback is explicit: the homepage must feel like authority governance. The current docs 06/07 are framed as inventory rationalization ("here are 4 concepts, here is where each lives in the data model"). For a CISO, the reframing is:

From: "We separated automation definition from execution chain from runtime run from evidence event." To: "We distinguish between what authority is configured, whether that authority is active, what it can reach, and what proof we have."

The CISO narrative should be:

1. Standing authority exists (automation + identity + roles + resources = configured path)
2. Authority is active/dormant (execution evidence present/absent within window)
3. Authority reaches sensitive domains (data domain classification)
4. Authority crosses boundaries (egress classification)
5. Accountability is valid/broken (ownership status)

Each of these is a deterministic, binary or enumerated assertion backed by specific evidence artifacts. This is the W1 value proposition: not "we found vulnerabilities" but "we can prove the governance state of every autonomous authority path."

---

4. Gaps and Risks

4.1 What is missing in docs 06/07 that the vision demands

1. Standing Authority as a named concept. The W1 UX spec features "Standing Authority" as a visually dominant section in every finding detail. Docs 06/07 do not define it. It should be defined as: the deterministic assertion that an automation has persistent execution capability through a specific identity with specific roles, without requiring human session approval at runtime.

2. Risk cluster logic. The W1 UX defines compound governance conditions (e.g., "Sensitive + LLM + Active + Invalid Owner") as the primary navigation structure. Docs 06/07 do not describe how the 4-concept model feeds cluster computation. The ExposureUnit shape in doc 06 section 5 has the right fields, but no cluster aggregation logic is defined.

3. Execution magnitude. Binary proven/unproven is necessary but insufficient. W1 requires Executions (30d) as a quantitative field. This is present in the current platform (via execution_count_30d) but not modeled in doc 06's ExposureUnit shape.

4. Delta computation. W1 UX requires "Since Last Refresh" delta indicators. Neither doc addresses how the 4-concept model supports snapshot comparison.

5. Remediation framing. Sergey's feedback explicitly requests remediation advice surfaced at the top of findings, plus an inactive "Create Remediation Ticket" button. Doc 06/07 do not address remediation presentation even as a placeholder. This is a UX gap, not an architecture gap, but the analysis documents should acknowledge it.

4.2 Terminology conflicts that would confuse a CISO

Conflict	Risk	Resolution
"Execution Chain" implies runtime	Auditor/CISO asks "when did this execute?" for a topology artifact	Rename to Authority Chain or Authority Path
"Topology" is network jargon	CISO associates it with network diagrams, not authority mapping	Use "Authority Path" externally, keep "topology" as internal architecture term
"AutomationRun" vs "Execution Evidence"	If both appear in W2, a CISO may ask "what is the difference between a run and evidence?"	Clearly distinguish: a Run is a bounded instance (start/end/outcome); Evidence is a discrete proof event. A Run may contain multiple Evidence events.
"ExposureUnit" is abstract	A CISO wants to see "findings" or "exposures," not "units"	Use "Exposure" or "Exposure Finding" in user-facing surfaces
proven/unproven vs active/dormant	proven means "evidence exists"; active means "recently executed." These are different axes.	Make both explicit: execution_proven: true/false and authority_status: active/dormant

4.3 Governance/compliance blind spots

1. No attestation workflow in W1. This is correctly out of scope, but Sergey's feedback hints at future attestation ("ownership assignment / attestation could be pushed to other tools"). Docs 06/07 should note that the 4-concept model must support future attestation linkage (e.g., "this Standing Authority was reviewed and attested by [owner] on [date]").

2. No evidence chain integrity for topology. The platform has SHA256 integrity hashing for evidence packs, but topology artifacts (execution chains) are recomputed per sync with no integrity seal. If a CISO presents a topology finding to an auditor, the auditor may ask "how do I know this path was accurate at the time of the finding?" W1 should stamp the sync timestamp and source graph version on each finding.

3. Group ownership ambiguity. The W1 UX shows "Inherited Owner: present / none" and the logic doc defines ambiguous ownership, but docs 06/07 do not discuss how group-only ownership (e.g., a distribution list owns an automation) maps to the accountability assertion. The vision doc explicitly states that "Autonomous execution without accountable ownership is structural risk." Group ownership without individual accountability should be treated as a governance gap, not a valid ownership state.

---

5. Concrete Naming Recommendations for Q1-Q5

Q1: What should we call Concept 2 (currently "Execution Chains")?

Recommendation: Authority Chain

Reasoning:

• "Authority" directly anchors the W1 governance narrative. The vision doc's central question is "on what authority?" The W1 UX spec calls them "Autonomous Authority Risk Clusters." Using "Authority Chain" keeps the chain concept (familiar to the team) while shifting the semantic frame from "execution happened" to "authority is granted through this path."
• "Authority Path" is also strong but "Chain" preserves continuity with the existing codebase term, reducing migration confusion.
• "Topology" is technically precise but reads as network infrastructure jargon to a CISO audience. It should remain an internal architecture term only.
• "Configured Chain" is vague — "configured by whom?" is the immediate follow-up, and the answer ("by the platform at sync time") is confusing.

CISO test: "Show me the authority chains for this automation" reads naturally in a governance review. "Show me the execution chains" reads like an ops/incident investigation.

Q2: What column header for observed execution count?

Recommendation: Executions (30d)

Reasoning:

• The W1 UX spec uses "Executions (30d)" in both the finding row and the finding detail evidence section. Adopting the same term ensures consistency between the automations table and the W1 findings view.
• "Observed Runs (30d)" from doc 06 introduces "Runs" terminology before AutomationRun exists as infrastructure, which creates a forward-compatibility naming collision.
• "Activity (30d)" is too vague — activity could mean configuration changes, not execution.
• "Executions (30d)" is unambiguous: it means "this many times something verifiably executed."

Q3: What timestamp label on chain detail pages?

Recommendation: Last Computed

Reasoning:

• "Last Computed" accurately conveys that the chain/path is a platform-derived artifact recalculated at sync time, not an observation of runtime activity.
• "Last Synced" is technically accurate but may confuse users who think "synced" means "data was pulled from source" rather than "chain was recomputed."
• "Last Observed" is actively misleading — it implies the chain was observed executing, which is the exact semantic confusion docs 06/07 are trying to resolve.

For W1, if authority chains are secondary/internal, this label matters less for the primary user flow. But if chain detail pages remain accessible, "Last Computed" prevents misinterpretation.

Q4: Should the glossary upgrade from 3-concept to 4-concept model?

Recommendation: Option B — Add the 4th concept now as "planned"

Reasoning:

• The glossary is an internal reference document, not a user-facing product surface. Adding "Automation Run (planned — W2)" sets correct mental models for the team and for anyone reviewing architecture docs.
• Omitting it risks the team continuing to conflate topology and runtime in casual discussion, which is the problem doc 06 identified.
• The entry should be clearly marked as not yet implemented to avoid confusion: "Automation Run — A bounded runtime instance of an automation execution. Not yet implemented as a first-class platform concept; deferred to W2. Currently, runtime proof is captured through Execution Evidence records."

Q5: Nav item for the chains/topology page

Recommendation: "Authority Chains" with Shield icon

Reasoning:

• Follows directly from Q1 resolution.
• Shield icon reinforces the governance/security framing over the link/chain visual metaphor.
• For W1, this page should be secondary to the primary risk cluster flow. Consider placing it under a "Discovery" or "Explore" nav section rather than top-level, to keep the primary navigation aligned with the W1 investigation flow (Homepage -> Risk Clusters -> Findings -> Detail).

---

6. Summary of Recommendations

Area	Recommendation
Internal architecture model	Keep the 4-concept separation from doc 06. It is architecturally sound.
External / CISO-facing naming	Use authority governance language: Authority Chain, Standing Authority, Execution Evidence, Exposure.
Missing concept	Define "Standing Authority" as a named concept in the W1 model.
Execution status	Separate two axes: execution_proven (binary evidence question) and authority_status (active/dormant temporal question).
Execution magnitude	Add execution_count_30d to the ExposureUnit shape. Binary proven/unproven is insufficient for W1 UX.
Risk clusters	Define cluster aggregation logic as a W1-A deliverable. It is the primary CISO navigation surface.
Delta computation	Define "Since Last Refresh" delta logic as a W1-A deliverable.
Glossary	Upgrade to 4-concept model with AutomationRun marked as planned/W2.
Chain page naming	"Authority Chains" with Shield icon, secondary to risk cluster flow.
Compliance posture	Stamp sync timestamp and source version on topology-derived findings for audit defensibility.