W1 — Open Questions

Unresolved design decisions. Each item references the relevant spec section and captures the current implementation state vs. the alternatives under consideration.

---

1. Ownership Evaluation Model

Spec reference: logic.md section 5

Current logic.md definition (as of 2026-02-24):

• valid — at least one active identifiable owner
• invalid — no active owners OR any one active owner is missing
• ambiguous — group-only ownership without individual accountability
• unknown — insufficient deterministic metadata

Current code implementation:

• orphaned_ownership fires when ANY owner is non-active (matches "invalid" in logic.md)
• ownership_ambiguous fires when all active owners are groups/teams (only if orphaned didn't fire)
• ownership_unknown fires when no OWNED_BY edges exist

Problem: The "invalid" definition conflates two very different scenarios:

Scenario	Current status	CISO urgency
3 owners, 1 left the company	invalid	Medium — 2 people still accountable
All owners gone	invalid	Critical — zero accountability

Proposed revision — 5-state model:

Situation	Status	Finding type	Severity	Rationale
At least 1 active individual owner	valid	None	—	Accountability exists
All owners active, but all are groups	ambiguous	ownership_ambiguous	low	Governance gap, not urgent
Some owners non-active, at least 1 still active	degraded	ownership_degraded	medium	Partial accountability loss, remaining owners should clean up
ALL owners non-active	orphaned	orphaned_ownership	high	Zero accountability, nobody to contact
No OWNED_BY edges at all	unknown	ownership_unknown	medium	Can't determine ownership

Key changes from current model:

1. Split "invalid" into "degraded" vs "orphaned" — partial loss (some owners left) is meaningfully different from total loss (all owners gone)
2. Reduce ambiguous severity — group ownership is a governance concern, not an active risk. A CISO with a team-owned workload has somewhere to start; with an orphaned one they don't.
3. ownership_degraded is a new finding type — would need to be added to the evaluator

Open sub-questions:

• Should ownership_degraded participate in risk clusters? Currently orphaned_sensitive, orphaned_external, and orphaned_sensitive_llm all require orphaned_ownership. Should they also match ownership_degraded, or should degraded paths only appear in their own cluster?
• For the "degraded" case, should the finding explanation name which specific owners are missing? (Current orphaned rule already does this.)
• Is "ambiguous" worth a finding at all, or should it just be metadata on the path without generating a finding? CISOs may consider team ownership acceptable.

---

2. Group Ownership — When Is It Acceptable?

Related to: Question 1 (ambiguous state)

In enterprise environments, group/team ownership is common and often intentional:

• Shared service accounts owned by "Platform Engineering Team"
• Automation owned by "IT Operations" with clear on-call rotation

Question: Should group ownership always trigger ownership_ambiguous, or only when the group itself lacks governance metadata (e.g., no manager, no active members)?

Current state: We don't have group membership or manager data from connectors yet. So we can't distinguish "well-governed team" from "abandoned DL." For now, flagging all group-only ownership as ambiguous is the safe default.

Future consideration: When connector data includes group governance metadata, ambiguous could be refined to only fire for groups without clear individual accountability.

---

Last updated: 2026-02-24