Vision vs Delivered - Combined Realignment Plan (Best of Both)

Date: 2026-02-11
Status: Draft - combined version for team selection

---

1. Which Plan Is Better?

There is no single winner. Each plan is stronger in different areas:

1. 2026-02-10 plan is better for immediate pilot execution

   • Strong UI framing
   • Concrete screen-level proposals
   • Clear quick wins and prioritization matrix

2. 2026-02-11 codex plan is better for platform correctness and scalability

   • Strong temporal model (effective_at, observed_at, ingested_at)
   • Better ingestion/correlation architecture target
   • Better continuity model (automation_instance vs business_flow)

3. Best practical path: combine both

   • Ship automation-first UX quickly
   • In parallel lock data/temporal semantics to avoid rework
   • Then land staged architecture upgrades

---

2. Combined Diagnosis

2.1 What is already strong

1. Deterministic ingestion -> diff -> evaluation -> evidence pack pipeline is in place.
2. Cross-system graph model and execution-path materialization exist.
3. Focus-mode graph and temporal endpoints exist.
4. Connector outputs rich MVP1 per-automation properties.

2.2 Primary gaps

1. Product framing gap (P0): UI starts from findings, not automations.
2. Flow readability gap (P0): execution chain is hard to read end-to-end.
3. Temporal correctness gap (P0/P1): event ordering can reflect ingest time rather than source time.
4. Semantic consumption gap (P1): MVP1 automation properties are not consistently first-class in evaluator/UI.
5. Continuity gap (P1/P2): business process continuity is not modeled separately from technical identities.
6. Ingestion evolution gap (P2): limited platform-side correlation and incremental update model.

---

3. Target Product Shape

3.1 Automation-first navigation

New primary journey:

1. Automation Overview (default landing)
2. Automation Detail (flow + evidence + risk)
3. Findings (triage queue from automation context)
4. Graph Explorer (deep investigation)
5. Entities (technical explorer)

3.2 Automation Overview (must include)

Columns should map to PRD outputs:

1. automation_type
2. identity_binding_status
3. execution_count_30d and latest execution timestamp
4. egress_category and destination
5. data_domains and origin tables
6. ownership_status
7. risk_group, risk_group_label, risk_group_priority
8. finding count and severity summary

3.3 Automation Detail visualization approach

Adopt the dual best option:

1. Option D from 2026-02-10: simple step flow diagram (trigger -> automation -> auth -> authority -> resources -> egress) for readability.
2. Option B from 2026-02-10: improve existing graph with path highlighting and authority/provenance edge distinction for deep-dive.

Future evolution:

3. Option A lane layout once canonical flow semantics are stable.

---

4. Target Data and Architecture Shape

4.1 Temporal model (adopt now)

Add explicit timestamps:

1. effective_at - when event happened in source
2. observed_at - when connector observed/fetched
3. ingested_at - when platform persisted

Rules:

1. Timeline sorting defaults to effective_at.
2. Event replay and continuity analysis use effective_at.
3. Operational latency views use observed_at and ingested_at.

4.2 Canonical flow semantics (adopt now)

Execution-flow mode should follow deterministic templates:

1. Forward: origin -> trigger -> automation -> run-as/auth -> role/permission -> resource -> egress
2. Reverse: egress/resource -> ... -> automation -> origin

Do not mix generic neighborhood expansion with canonical flow mode.

4.3 Continuity model (adopt in phased way)

Separate business continuity from technical identity churn:

1. automation_instance (technical runtime objects)
2. business_flow (stable business process)

Linkage:

1. INSTANCE_OF (instance to flow)
2. SUPERSEDES (instance evolution over rotations/replacements)

Deterministic matching keys (priority order):

1. Same automation artifact IDs (e.g., sys_id)
2. Stable OAuth entity IDs
3. Stable trigger + destination + operation signatures

4.4 Ingestion evolution target

Move to staged pipeline:

1. Import source facts
2. Resolve/correlate
3. Reconcile edges and controlled deletions
4. Project execution/flow views
5. Evaluate and build evidence
6. Publish impacted graph slices

Add durable idempotency ledger and persistent cursor usage for incremental + webhook modes.

---

5. Combined Delivery Plan

Wave 0 - Pilot-facing UX wins (1-2 weeks, P0)

1. Add Automations Page and Automation Detail Page.
2. Redesign dashboard to include automation/risk group perspective.
3. Add automation-centric filters and navigation defaults.
4. Show PRD outputs as badges/columns, not hidden in raw properties.

Deliverable focus: better story for operators and design partners without waiting for heavy backend refactor.

Wave 1 - Correctness foundations (1-2 weeks, P0/P1)

1. Define and implement multi-timestamp event contract.
2. Fix timeline contract mismatches between backend and UI models.
3. Clean relationship type taxonomy in graph filters/styles.
4. Enforce canonical execution-flow traversal semantics in API mode.

Deliverable focus: remove ambiguity in order-of-events and chain interpretation.

Wave 2 - Semantics and evaluator alignment (1-2 weeks, P1)

1. Treat MVP1 automation fields as first-class evaluator and evidence inputs.
2. Add per-automation state computation endpoints if needed.
3. Improve evidence-pack sections to include explicit origin->egress chain view.

Deliverable focus: align reported findings with PRD per-automation semantics.

Wave 3 - Continuity and ingestion evolution (2-4 weeks, P2)

1. Introduce business_flow model and instance linking.
2. Add platform-side correlation service and rule registry.
3. Introduce incremental entity update endpoints + webhook ingestion adapters.
4. Recompute only impacted neighborhoods on change.

Deliverable focus: long-term scalability and continuity across technical churn.

Wave 4 - Hardening and rollout (1 week)

1. Backfill/migration scripts.
2. Regression suites for chronology, continuity, and flow traversal.
3. Pilot acceptance checks with deterministic replay evidence.

---

6. Prioritization Matrix (Combined)

Item	Impact	Effort	Priority
Automations Page + Detail	Very high	Medium	P0
Dashboard automation/risk framing	High	Low	P0
Timeline timestamp model fix	Very high	Medium	P0
Canonical execution-flow mode	High	Medium	P1
Graph authority/provenance styling + highlighting	Medium	Low	P1
MVP1 property first-class evaluator consumption	High	Medium	P1
Business-flow continuity model	High (long-term)	High	P2
Platform-side correlation engine	High (long-term)	High	P2
Incremental/webhook ingestion	High (long-term)	High	P2

---

7. Acceptance Criteria

1. Automation inventory can be reviewed without going to generic entities page.
2. Any automation can be traced origin -> egress and reverse within three interactions.
3. Timeline order reflects source chronology, not just ingestion order.
4. Credential/client/SP rotations do not automatically fragment business process history.
5. PRD per-automation outputs are visible and actionable in the core workflow.
6. Findings remain deterministic and evidence-backed after all changes.

---

8. Notes on Source Plans

This combined plan intentionally keeps:

1. The 2026-02-10 plan's concrete UI artifacts, pragmatic sequencing, and PRD visibility emphasis.
2. The 2026-02-11 codex plan's temporal rigor, canonical flow semantics, and continuity/correlation architecture.

It is intended to be the execution baseline unless the team decides to split into separate Pilot and Platform Architecture tracks.