Founder Feedback Plan - Authority Path and Persistent Exposure Model

Date: 2026-02-18 Status: Proposed architecture pivot for review Context: Founder feedback after live implementation walkthrough (Florida, 2026-02-18 10:55:58)

---

1. Problem Statement

Founder feedback identifies a mental-model mismatch in the current implementation:

1. Risk Cluster drill-down should show Authority Paths with execution magnitude and ownership status, not a flattened exposure list.
2. Authority Path is the durable object; Exposure is a time-bound issue on that path.
3. Exposure requires temporal semantics (at minimum effective start date).
4. Chains should function as the Authority Path inventory and drill into path details.
5. Findings/Exposure views should be reorganized around cluster -> path -> exposure timeline.

This conflicts with current W1 docs that define Exposure as a non-persistent derived projection and explicitly exclude temporal persistence.

---

2. Multi-Role Analysis (Team Synthesis)

Role	Key Conclusion	Architecture Impact
Architect	The durable investigation anchor must be Authority Path (current chain concept), not Exposure.	Promote path object as primary first-class runtime object for investigation and lifecycle.
CSO	CISO workflow is cluster-first, then path review, then issue history on a path.	Replace exposure-first list navigation with path-first drill-down under cluster context.
Product Owner	Exposure is an incident/finding over time, not the inventory row itself.	Define Exposure as persistent timeline records with open/close semantics.
Developer	Current computed exposure route is insufficient for historical reasoning and lifecycle state.	Add persistent storage, idempotent upsert logic, and lifecycle transitions.
Integrator	Path identity must be stable across sync cycles and connector refreshes.	Formalize stable path fingerprint strategy and path versioning rules.

---

3. Proposed Concept Model (Revised)

Canonical concepts

1. Workload Executable artifact (Business Rule, Script Include, Scheduled Job, Flow, etc.).

2. Authority Path (external canonical) / Authority Topology (internal alias) Durable execution-authority route: workload -> identity -> destination -> data_domain.

3. Exposure Persistent, time-bound risk state on one Authority Path.

4. Risk Cluster Ephemeral grouping of active exposures and/or active paths by compound condition.

Temporal interpretation

1. Path exists with no issues: zero exposures.
2. Condition appears (for example owner departed): open Exposure A on that path.
3. New condition appears later (for example sensitive domain reach): open Exposure B on same path.
4. Risk Cluster groups active exposures across paths at query time.

---

4. Data Model Delta (Required)

4.1 Authority Path (durable)

Use existing execution_chains foundation, but product-surface as Authority Paths.

Minimum required fields:

• path_id (stable deterministic id)
• composition_hash (normalized full-path hash for mutation/change detection)
• tenant_id
• workload_id
• identity_id (nullable for unknown binding)
• destination_id (nullable)
• data_domain
• path_fingerprint (normalized deterministic hash)
• current_state snapshot (execution_30d, ownership_status, egress_category, max_sensitivity)
• first_seen_at
• last_seen_at
• status (active, removed)
• removed_at (nullable)
• sync_version
• created_at
• updated_at

4.2 Exposure (persistent)

Add a dedicated exposures collection.

Minimum required fields:

• exposure_id (stable deterministic id per path + exposure_type + open interval)
• tenant_id
• path_id
• exposure_type (maps to canonical finding types)
• severity
• status (active, resolved, acknowledged, false_positive)
• effective_from (required)
• effective_to (nullable)
• detected_at (first time our system observed the condition)
• last_evaluated_at
• resolution_reason (nullable)
• evidence_refs
• evidence_completeness
• sync_version

4.3 Relationship to findings

Keep findings as canonical issue engine for backward compatibility.

Mapping rule:

• A W1 finding for a path condition becomes an exposure record event/state.
• Exposure list and timeline read from exposures.
• Findings page can be retained as legacy diagnostic surface during transition.
• Rules may continue evaluating at entity level initially, but output must be path-bound (thin adapter maps entity condition to affected path set).

4.4 Merged Design Decisions (from both analyses)

1. Path granularity Primary record grain is one path per (workload_id, identity_id, destination_id) with data_domain as path metadata.
2. Exposure/finding transition Transition model is additive: persistent exposures + backward-compatible findings until UI/API migration is complete.
3. Temporal honesty for effective_from Phase 1 uses effective_from = detected_at unless historical reconstruction is available. Do not imply exact historical start without evidence.
4. Path lifecycle Path disappearance is represented by status=removed and removed_at; history remains queryable for investigations and audits.

---

5. API Contract Delta (Required)

5.1 Cluster-first workflow

1. GET /api/v1/posture/risk-clusters Returns cluster summary built from active exposures and path state.

2. GET /api/v1/risk-clusters/:cluster_key/authority-paths Returns path rows with:

   • execution magnitude (30d)
   • ownership status
   • active exposure count
   • latest exposure start date

5.2 Path inventory and detail

1. GET /api/v1/authority-paths (alias from /chains during migration)
2. GET /api/v1/authority-paths/:id
3. GET /api/v1/authority-paths/:id/exposures Returns exposure timeline for the selected path.

5.3 Backward compatibility

1. Keep /api/v1/chains as alias for one release window.
2. Keep /api/v1/exposures but redefine as persistent exposure records, not computed projections.

---

6. UX / Navigation Delta

Target workflow:

1. Homepage: Top Risk Clusters.
2. Cluster click: Authority Path rows (not exposure rows).
3. Row content: execution magnitude + ownership status + active exposures.
4. Row expand: compact active exposure summary.
5. Detail view: full path detail + exposure timeline.

Navigation adjustments:

1. Promote Chains to Authority Paths in UI copy (route alias preserved).
2. Keep Findings page as legacy/diagnostic during transition.
3. De-emphasize standalone exposure dashboard in default investigation flow.

---

7. Documentation Change Plan

Docs that require explicit scope update:

1. docs/product/wedges/w1-exposure/scope.md Remove exclusion of temporal persistence/chains for revised scope.

2. docs/product/wedges/w1-exposure/logic.md Add exposure lifecycle semantics and path-linked temporal states.

3. docs/product/wedges/w1-exposure/ux.md Update primary flow to cluster -> authority path -> exposure timeline.

4. docs/architecture/01-data-model.md Add persistent Exposure entity definition and Authority Path durability semantics.

5. docs/architecture/03-database.md Add exposures collection schema and indexes.

6. docs/architecture/04-api-layer.md Add authority-path and exposure timeline endpoints.

7. docs/glossary.md Clarify distinction: Authority Path (durable) vs Exposure (time-bound record).

---

8. Implementation Plan (Phased)

Phase A - Decision lock (1 day)

1. Approve concept model pivot and terminology.
2. Create ADR: "Exposure Persistence and Authority Path Primacy".

Phase B - Storage and lifecycle foundation (2-3 days)

1. Lock storage strategy for paths: adapt existing execution_chains vs introduce dedicated authority_paths collection.
2. Add exposures collection and indexes.
3. Persist Authority Paths with explicit lifecycle (active / removed) and deterministic composition_hash.
4. Implement exposure upsert/open/resolve lifecycle worker logic (idempotent keys).
5. Add path fingerprint stability checks.

Phase C - API transition (2-3 days)

1. Add cluster -> authority-path drilldown endpoint.
2. Add authority-path detail + exposure timeline endpoints.
3. Preserve aliases for old routes.

Phase D - UI transition (2-3 days)

1. Convert cluster drilldown table to Authority Path rows.
2. Add path detail page with exposure timeline.
3. Re-label Chains as Authority Paths (copy-level migration first).

Phase E - Migration and validation (1-2 days)

1. Backfill initial exposure records from current active findings.
2. Validate open/close behavior across two sync cycles.
3. Run founder walkthrough on revised flow.
4. Validate effective_from semantics are labeled honestly (detected_at baseline unless reconstructed).

---

9. Risks and Mitigations

Risk	Impact	Mitigation
Path identity churn due unstable fingerprinting	Exposure history fragmentation	Canonical fingerprint schema + migration utility + regression tests
Duplicate exposures from evaluator re-runs	Inflated counts and noisy clusters	Idempotent upsert key: tenant + path + exposure_type + active interval
Route and UI transition confusion	User trust loss	Route aliases + progressive relabeling + release note callouts
Scope expansion from original W1	Delivery delay	Mark as W1.1 architecture revision with explicit cutline and staged rollout
Misleading exposure start dates	Trust erosion with CISO/founder	Use detected_at baseline initially; upgrade to reconstructed start dates only when evidence supports it

---

10. Acceptance Criteria for This Pivot

1. Clicking a Risk Cluster shows Authority Paths as primary rows.
2. Each row shows execution magnitude and ownership status before detail click.
3. Path detail displays exposure timeline with effective_from and status changes.
4. Exposure can be opened/resolved on the same path across time without losing history.
5. Cluster aggregation is computed from active exposures and current path state.
6. Removed paths and resolved exposures remain historically queryable.

---

11. Open Questions for Decision Lock

1. If RUNS_AS target changes, is that a new path identity or a mutation event on existing path lineage?
2. Should clusters remain computed-only in W1.1, or do we also persist cluster snapshots for temporal reporting?
3. What is the user-facing canonical term in product UI: Authority Path or shortened Auth Path?
4. What is the exact auto-resolve policy per exposure type (for example ownership restored, egress removed, sensitivity downgraded)?
5. Should path persistence be implemented by evolving execution_chains, or by introducing a new canonical authority_paths collection?

---

12. Recommendation

Adopt this as a W1 architecture revision (W1.1) rather than incremental patching of computed exposures.

Reason:

1. It aligns directly with founder and CISO mental model.
2. It matches long-term "system of record" vision.
3. It avoids repeated semantic churn between findings, exposures, and chains.