Naming Research Comparison — Three-Model Analysis Summary

Date: 2026-02-17 Purpose: Give Sergey a single document comparing three independent research analyses on the 4-concept naming model, so we can make a final decision.

Source documents:

#	Research	Model	Document
A	Gemini Research	Gemini 2.5	07-Gemini-Research-Clarifying Security Automation UI Concepts.md
B	Codex Research	Codex 5.3	06-Codex-5.3-Research-automation-definition-vs-runtime-separation-synthesis.md
C	Claude Team Synthesis	Claude Opus (4 agents: CISO, Product, Developer, Architect)	08-vision-alignment-synthesis.md + 4 perspective docs

---

1. What All Three Agree On (Universal Consensus)

These points are settled. All three analyses converge independently:

Area	Consensus	Notes
4-concept separation is correct	Separate definition, derived path, runtime instance, and evidence	All three derive this independently
Concept 1 = "Automation Definition"	The broad configured behavior keeps this term	No disagreement
Concept 3 = "Automation Run" (W2)	Runtime instance is a first-class concept but deferred	All three agree W1 doesn't need run persistence
Concept 4 = "Execution Evidence"	Raw proof events stay as-is	No disagreement
Deterministic only, no heuristics	Findings must be evidence-backed; "unknown/unproven" is a valid result	All three stress this
W1 defers chain drift, versioning, run persistence	These are W2 concerns	All three align with W1 scope docs
"Execution Chains" is the wrong name	Current name conflates sync-derived structure with runtime execution	The reason all three analyses exist
Atomic entity naming is unresolved	The narrow entity currently called automation needs a distinct term	New focus from founder + Gemini follow-up

Bottom line: The architecture is decided. The open naming questions are Concept 2 label and the atomic entity term currently called automation.

---

2. The Core Disagreement: What to Call Concept 2

This is the central naming decision. Here's what each research recommends:

2.1 Gemini: "Authority Topology" (or "Topology")

Argument: Topology is the technically correct term for describing the structural layout of nodes and connections in a graph. It is system-agnostic (not tied to ServiceNow or Azure vocabulary), aligns with the graph-based data model, and maps naturally to security concepts like blast radius and lateral movement.

Proposed hierarchy:

• Automation Entity (atomic) — the specific script/rule subtype
• Automation Definition (molecule) — the single configured unit of logic
• Authority Topology (system-level) — the chain of execution connecting triggers, definitions, connections, credentials, and identities

UI recommendation: Rename nav to "Topologies" or "Authority Topologies". Use "Topology" in page titles, detail views, and the linear path diagram.

Strengths:

• Most technically precise term for a graph structure
• Vendor-neutral (no ServiceNow/Azure baggage)
• Well-understood in network security context
• Gemini provides 37 external citations supporting this framing

Weaknesses:

• "Topology" sounds like network diagrams to non-technical users
• CISOs may not immediately connect "topology" to "authority risk"
• Gemini's analysis was written before Sergey's W1 UX spec — it doesn't account for W1's single-flow navigation constraint

Source: Gemini Research §Analytical Evaluation, sections on "Topology: The Superior Semantic" and "Strategic Conclusion"

---

2.2 Codex: "AutomationTopology" (internal) + "ExposureUnit" (W1 surface)

Argument: Agrees with Gemini that "Topology" is correct for the structural concept, but splits the answer into two layers. Internally/architecturally, use AutomationTopology. But W1 users should never see "topology" — they see an ExposureUnit, a deterministic projection (automation → identity → destination → data domain) that is the primary W1 surface.

Proposed hierarchy:

• AutomationDefinition — static config (Concept 1)
• AutomationTopology — internal/secondary, recomputed per sync (Concept 2)
• ExposureUnit — W1-primary deterministic projection combining graph + evidence
• AutomationRun — deferred to W2 (Concept 3)
• ExecutionEvidenceEvent — immutable proof (Concept 4)

UI recommendation: Keep topology internal. W1 primary surface is risk clusters + deterministic exposure rows. Nav does not expose topology as a page.

Strengths:

• Adopts "Topology" at the architecture level (agrees with Gemini)
• Introduces ExposureUnit as a new W1-specific projection shape
• Explicitly W1-scoped — accounts for founder vision and UX constraints
• Has a concrete ExposureUnit field spec (automation_id, execution_identity_id, execution_status, data_domains[], egress_category, ownership_status)

Weaknesses:

• Introduces a 5th concept (ExposureUnit) that may add complexity
• ExposureUnit is a projection, not persisted — could confuse developers about what's "real"
• "AutomationTopology" as a prefix is long and compounds two nouns

Source: Codex Research §5 W1-Aligned Canonical Model, §9 Gemini comparison, §11 Final Recommendation

---

2.3 Claude Team: "Authority Chains" (internal) + Not surfaced in W1

Argument: Four independent perspectives (CISO, Product Owner, Developer, Architect) analyzed the naming question against Sergey's W1 vision and UX. The CISO and Architect perspectives favor "Authority Chains" because "authority" is governance language that a CISO understands immediately. The Product Owner and Developer say: don't surface it in W1 at all — W1 has no chains page.

Proposed hierarchy:

• Automation Definition (Concept 1)
• Authority Chains (Concept 2, internal/docs name) — not in W1 UX
• Automation Run (Concept 3, W2)
• Execution Evidence (Concept 4)

W1 users see: Findings grouped into Autonomous Authority Risk Clusters. No chain/topology/path concept is named or exposed.

UI recommendation: Remove chains from W1 primary nav entirely. If retained for debug/power-user mode, label "Authority Chains" in a collapsed section with Shield icon.

Strengths:

• "Authority" is CISO-native vocabulary — immediately communicates governance
• "Chains" preserves the familiar metaphor from current platform
• Fully aligned with Sergey's W1 UX constraint ("no alternate navigation, no graph browsing mode")
• Avoids introducing any new concept to W1 users (no "topology", no "ExposureUnit" — just "findings")
• 3-of-4 agents independently chose "Authority Chains" or "keep internal"

Weaknesses:

• "Chains" still carries some sequential/runtime implication
• Less technically precise than "Topology" for describing a graph structure
• Doesn't scale well if W2 introduces true multi-branch topologies (chains implies linearity)

Source: Claude Synthesis §1 Q1, plus CISO, Product Owner, Developer, Architect

---

3. Side-by-Side Comparison Table

Question	Gemini	Codex 5.3	Claude Team (4 agents)
Concept 2 internal name	Authority Topology	AutomationTopology	Authority Chains
Concept 2 in W1 UX?	Yes — rename nav to "Topologies"	No — keep internal, surface ExposureUnit	No — not in W1 nav at all
New W1 concept introduced?	No (topology replaces chains)	Yes — ExposureUnit (projection)	No — uses existing "findings" + risk clusters
Execution count label	"Observed Runs (30d)"	"Executions (30d)"	"Executions (30d)"
Timestamp label	"Last Computed" for topology	"Last Computed"	"Last Computed" (3-of-4)
Glossary model	4-concept	5-concept (adds ExposureUnit)	4-concept + W2 placeholder
W1 navigation model	Topology page + findings	Risk clusters + exposure rows	Risk clusters + findings (single flow)
Accounts for W1 UX spec?	No (written before W1 UX)	Yes (sections 3, 5, 6, 7)	Yes (all 4 perspectives evaluate against W1)
External citations	37 industry sources	5 workflow/orchestration platforms	4 internal perspectives + W1 docs
Risk Clusters defined?	Mentioned in findings view	Mentioned but not detailed	Detailed spec + ADR recommendation
Standing Authority defined?	Referenced as "Standing Authority block"	Not as a named concept	Identified as critical gap, needs definition

---

4. Where Each Research Has Unique Value

Gemini's unique contribution

• Industry validation: 37 external sources (CrowdStrike, SailPoint, CyberArk, NHI Management Group, OWASP) establishing "topology" as the standard security term for graph-level authority structures
• Atomic Design analogy: Atoms (entity/subtype) → Molecules (definition) → Organisms (topology) — helpful mental model
• Cross-system traversal detail: Specific ServiceNow/Azure/Logic Apps mechanics for evidence extraction

Codex's unique contribution

• ExposureUnit shape: Concrete field specification for the W1 projection (automation_id, execution_identity_id, execution_status, data_domains[], egress_category, ownership_status)
• Implementability matrix: Maps every W1 capability against current platform state with feasibility assessment
• External pattern validation: Camunda, AWS Step Functions, Airflow, Kubernetes, Temporal all use the same definition-vs-instance split
• Gemini comparison section: Already compares itself against Gemini and resolves differences

Claude Team's unique contribution

• 4-perspective consensus process: CISO, Product, Developer, Architect independently evaluate, then synthesize
• Q1-Q5 decision matrix: Each naming question gets a per-perspective recommendation with a final voted decision
• Two-axis execution model: execution_proven (boolean evidence) + authority_status (active/dormant) — solves the single-binary-status problem
• 20-item phased implementation plan: Most actionable of the three
• Internal vs External vocabulary map: Clean separation of code terms vs CISO terms
• Risk Cluster gap analysis: Detailed spec for the missing concept W1 requires

---

5. The Real Decision for Sergey

The 4-concept model is settled. The W1 scope is settled. The only open question is:

What do we call Concept 2 — the sync-derived structural path from automation through identities to resources?

Option	Champion	Best for	Risk
Authority Topology	Gemini	Technical accuracy, industry alignment, graph semantics	"Topology" is jargon for non-technical stakeholders
AutomationTopology	Codex	Internal architecture clarity, pairs with ExposureUnit	Long compound name, adds a 5th concept (ExposureUnit)
Authority Chains	Claude Team	CISO-native language, minimal change, governance framing	"Chains" implies linearity; less precise for multi-branch graphs

My recommendation: Authority Topology

Here's why:

1. Gemini is right about the word "Topology." It is the technically correct term for what this concept represents — the structural layout of authority relationships in a directed graph. SecurityV0's data model IS a 9-entity graph. "Chain" implies a linear sequence; "topology" describes a graph structure. As the platform evolves into W2+ with multi-branch paths, topology scales; chains doesn't.

2. Claude Team is right about the word "Authority." Every CISO-facing document and Sergey's own W1 UX use "authority" as the anchor word (Standing Authority, Autonomous Authority Risk Clusters, Authority Governance). "Automation Topology" (Codex's choice) puts the wrong word first — a CISO cares about authority, not automation. "Authority Topology" puts the governance concept first.

3. All three agree it should NOT be in W1 UX. This makes the name primarily an internal/documentation term for now. We don't need to optimize for CISO readability of this specific term in W1 — W1 users see "findings" and "risk clusters," not topologies. So we can afford to use the technically precise term internally.

4. ExposureUnit (Codex) is useful but should stay informal. The projection concept is valuable for developer communication, but adding a 5th named concept to the glossary adds cognitive load. The W1 finding row IS effectively an exposure unit — we don't need to name it separately.

Proposed final vocabulary:

Concept	Name	Where it appears
1 — Static config	Automation Definition	Everywhere — code, docs, UI
2 — Derived graph path	Authority Topology	Internal docs, glossary, architecture. NOT in W1 UX. Code collection stays execution_chains.
3 — Runtime instance	Automation Run	Glossary as "planned — W2". Not implemented yet.
4 — Raw proof	Execution Evidence	Everywhere — code, docs, UI
W1 surface grouping	Risk Cluster	W1 UX only (Homepage, Findings View)
W1 finding row	Finding / Exposure	W1 UX only (each row = automation → identity → destination → data domain)
W1 governance assertion	Standing Authority	W1 Finding Detail (execution model, auth type, human session required)

Why not "Authority Chains"?

"Chains" works well today because the current execution_chains collection stores linear paths. But the word implies strict sequential ordering. When W2 introduces branching paths (one automation → multiple identities → multiple destinations), "chain" becomes misleading. "Topology" survives that evolution. Since this is an internal term and we're choosing it for the long run, technical precision wins.

Why not "AutomationTopology"?

Putting "Automation" first emphasizes the wrong thing. The CISO question is "what authority exists?" not "what automation exists?" Authority Topology answers the right question first. It also avoids the compound-noun problem — AutomationTopology reads like a class name, not a concept name.

---

6. Naming Decisions Summary (for Q1-Q5 from doc 07)

Question	Decision	Rationale
Q1: What to call Concept 2?	Authority Topology	Technically precise + governance-first. See §5.
Q2: Execution count column header?	Executions (30d)	2-of-3 models agree. Matches W1 UX spec.
Q3: Timestamp label on chain detail?	Last Computed	3-of-3 models agree. Prevents runtime misreading.
Q4: Glossary 3 or 4 concepts?	4 concepts, with AutomationRun as "planned — W2"	Unanimous across all three.
Q5: Nav item for chains page?	Not in W1 primary nav. If kept for debug: "Authority Topologies" with Network icon in collapsed section.	All three agree W1 doesn't expose this page.

---

7. What Happens Next (After Sergey Decides)

Once the naming decision is made, the implementation is straightforward:

Immediate (docs only, no code):

1. Update glossary to 4-concept model with "Authority Topology" for Concept 2
2. Define "Standing Authority" and "Risk Cluster" in glossary
3. Fix stale API doc migration note (04-api-layer.md:140)

Phase W1-A (small code + UI changes): 4. Rename "Execution" column to "Executions (30d)" on AutomationsPage 5. Rename "Last Seen" to "Last Computed" on chain detail (if page stays) 6. Restructure UI nav: W1 primary + collapsed debug section 7. Fix chain-role naming mismatch (types.ts vs ADR-008)

Phase W1-B (core W1 UX): 8. Build risk cluster aggregation API 9. Build W1 Homepage, Findings View, Finding Detail 10. Add new evaluator rules (identity binding, sensitive domains, egress classification)

All three research documents have detailed implementation plans that align on this sequencing.

---

8. Surface Proposal Analysis (Founder + Gemini Follow-up)

This section evaluates the proposal:

• keep the broad concept as Automation Definition
• rename the atomic automation entity to surface
• potentially stop using topology in favor of "regular automation"

8.1 Where the proposal aligns

1. It aligns with W1 wording already used in product docs: "autonomous execution surfaces."
2. It improves CISO framing by shifting from developer-centric "script/automation" language to exposure-centric language.
3. It cleanly removes the "automation inside automation" collision.

8.2 Where the proposal conflicts (if applied literally)

1. Renaming Concept 2 (derived path) to "automation" or "automation definition" collapses two distinct concepts:
   • configured behavior (definition)
   • derived authority structure (path/topology)
2. That collapse would reintroduce the same ambiguity we are trying to remove: users could not tell whether we mean intent/config vs computed structure.
3. Bare surface is semantically broad and could be confused with network attack surface unless scoped to execution.

8.3 CISO + Architect judgment

Use a two-level naming rule:

Layer	Recommended term	Why
Broad configured behavior (Concept 1)	Automation Definition	Stable, already adopted in docs and W1 narrative
Atomic entity type (current automation)	Execution Surface (UI label: "Surface")	Preserves security framing while staying specific
Derived structural concept (Concept 2)	Authority Path (external) / Authority Topology (internal architecture alias)	Keeps structural concept distinct from definition and runtime

Decision:

• Yes to renaming the entity from automation to a surface term.
• No to renaming topology/path into "automation" terminology.
• Keep 4-concept separation intact.

8.4 Practical implementation mapping

Current	Proposed	Scope
entity_type: "automation"	entity_type: "execution_surface" (or transitional alias surface)	Data model + APIs
"Automation" (when meaning atomic artifact)	"Surface"	UI copy
"Execution Chains"	"Authority Paths" (W1 internal/debug only)	Internal/docs/debug UI
"Automation Definition"	unchanged	Docs + UX core language

8.5 Why this is the best compromise

1. CISO language improves immediately ("execution surface" is risk-native).
2. Architect model remains coherent (definition vs path vs run vs evidence).
3. W1 UX stays focused on findings/risk clusters without introducing topology-first navigation.

---

9. Final Decision (2026-02-17)

Outcome: workload chosen. execution_surface / surface rejected.

After this document was produced, a separate 5-agent comparative analysis (CISO, Architect, Developer, Product Owner, Target Analyst) evaluated workload vs execution_surface vs surface. The team unanimously recommended workload based on:

1. Cloud-native familiarity — workload is a standard term in Kubernetes, GCP, Azure, and AWS. Developers and ops teams understand it immediately.
2. No ambiguity — unlike surface (attack surface? API surface?), workload has a clear, specific meaning: "a unit of work that runs as an identity."
3. Shorter, greppable — 8 characters, no underscores needed.
4. No collision — cleanly separates from "Automation Definition" (broad concept), "Authority Path" (derived structure), and "Automation Run" (runtime event).

The founder approved workload as the entity type rename. See ADR-010 for the formal decision record.

Revised implementation mapping:

Current	Decided	Scope
entity_type: "automation"	entity_type: "workload"	Data model + APIs
"Automation" (when meaning atomic artifact)	"Workload"	UI copy
"Execution Chains"	"Authority Paths" (W1 internal/debug only)	Internal/docs/debug UI
"Automation Definition"	unchanged	Docs + UX core language