Dashboard/PRISM/Wiki/Feature-Inventory-And-Build-Plan.md
PRISM

Wiki/Feature-Inventory-And-Build-Plan.md

Feature Inventory And Build Plan — PRISM

Date: 2026-05-08 Status: Draft updated with founder decisions

Product North Star

PRISM should feel like Claude Desktop or ChatGPT: the user works primarily through a chat-first copilot. The copilot understands the user intent, calls deterministic backend tools, monitors durable workflows, renders rich artifacts, and explains what matters. It should not rely on one long-running LLM skill chain as the source of execution truth.

Core principle:

Chat is the interface. Temporal is the execution brain. PostgreSQL is the memory. Typed module contracts are the boundary. The LLM synthesizes and explains; it does not own orchestration or state.

What Already Exists

Backend Foundation

  • FastAPI app with routers for accounts, audits, modules, freshness, evidence, benchmarks, and audit streaming.
  • Temporal workflow shell with wave-based audit execution.
  • PostgreSQL-oriented models for accounts, audits, module executions, deliverables, benchmarks, and Algolia customer evidence.
  • Database-first module result caching through module_executions.
  • SSE stream endpoint for audit progress.
  • Browser infrastructure with direct, stealth, and service tiers.
  • Customer evidence tables for customers, case studies, quotes, proof points, and advocates.

v2 Module Framework

  • Generic ModuleConfig + playbook + schema registry.
  • Generic ModuleExecutor for Perplexity-backed structured module execution.
  • Claim registry concept for factcheck consumption.
  • Playbook loader and execution strategies.
  • Agent API client for Perplexity research calls.
  • Registered v2 modules:
  • intel-company
  • intel-techstack
  • intel-traffic
  • intel-financial-public
  • intel-financial-private
  • intel-news
  • intel-hiring

Frontend Shell

  • Next.js app with assistant-ui and Vercel AI SDK.
  • Clerk dependency and sign-in route present.
  • Chat API route with zero-hallucination aRRIe system prompt.
  • Tool definitions for most planned PRISM modules, evidence tools, audit launch, and audit status.
  • Three-panel/dashboard components exist.
  • Rich PRISM cards exist for company, tech stack, traffic, financials, news, hiring, social, investor, partner, industry, queries, browser audit, business case, sales plays, campaign, factcheck, benchmarks, customer proof, score, and ROI.
  • Audit stream hook and progress components exist.

Documentation And Strategy Assets

  • Temporal technical specification.
  • Chat-first frontend architecture requirements.
  • Earlier dashboard-style IA.
  • Vault wiki now captures the skill-system baseline and module map.

Missing Or Incomplete Feature Inventory

A. Execution And Module Coverage

These skill-system modules still need first-class PRISM v2 backend implementations:

Module Priority Notes
intel-competitors P0 Needed for Golden Angle, competitor matrix, and many sales plays.
intel-queries P0 Required before browser audit can run deterministically.
audit-browser P0 Core search audit evidence, screenshots, and scoring.
audit-factcheck P0 Required quality gate before outputs are trusted.
audit-report P0 Final synthesis package and audit-data contract.
synth-business-case P1 Converts findings into ROI and deal rationale.
synth-sales-plays P1 Converts findings into AE actions.
campaign-abx P1 Activation layer after audit confidence exists.
intel-investor P1 High-value strategic quotes and Said-vs-Found inputs.
intel-industry P1 Vertical benchmark and market context.
intel-partner P2 Co-sell and SI ecosystem.
intel-social P2 Useful but operationally brittle due scraping dependencies.
audit-eval P2 Internal quality scoring, useful for regression and benchmark suites.

Important correction: the Temporal workflow already references the full module list, but the v2 registry only registers seven modules. The workflow and frontend currently assume more backend capability than exists.

B. Copilot Runtime

Needed to make PRISM feel like Claude Desktop/ChatGPT:

  • Durable conversation threads tied to account and audit.
  • Tool-call persistence: every chat tool call should produce a trace row or event.
  • Tool-result references instead of dumping raw JSON into chat context.
  • Parallel tool orchestration for read-only lookups.
  • Copilot state model: selected account, active audit, active module outputs, pinned artifacts, and user role.
  • Streaming “thinking” mapped to real backend events, not only frontend illusion.
  • Recovery behavior when the browser closes and reopens during an audit.
  • User-controllable refresh decisions: quick lookup, selective refresh, full audit, regenerate deliverable.

C. Backend APIs For Chat Tools

The frontend already defines tools for many capabilities. Backend endpoints need to fully support them:

  • Module execute endpoints for every registered and future module.
  • Read endpoints for latest module output by account/domain.
  • Audit event and trace endpoints.
  • Deliverable list/download endpoints.
  • Artifact mutation endpoints for editable ABX, sales plays, ROI assumptions, and leave-behind drafts.
  • Conversation/thread APIs.
  • Account search/list APIs suitable for 500-1000 accounts.
  • Bulk import APIs.
  • Admin/system health APIs.

D. Data Model

Current models are a good start, but PRISM needs additional first-class tables or JSONB conventions for:

  • Organizations/workspaces.
  • Users, roles, account assignment, and permissions.
  • Chat threads and messages.
  • Tool calls and tool outputs.
  • Workflow events and module trace steps.
  • Source/citation registry at field level.
  • Claim registry entries.
  • Factcheck corrections and verdicts.
  • Screenshots and browser observations.
  • Deliverable artifacts and versions.
  • Editable sales artifacts.
  • Audit run configuration and module dependency graph versions.

E. Enterprise Readiness

  • Clerk/Google Workspace login wired end-to-end.
  • Role-based authorization across backend and frontend.
  • Tenant/org scoping.
  • API key and provider secret management.
  • Rate limits, queue limits, and per-provider budget controls.
  • Admin dashboards for module health, cost, failures, and queue depth.
  • Audit logs for who ran, viewed, exported, or edited outputs.
  • Data retention policy and prospect-safe sharing policy.

F. UX And Artifact System

The chat should be primary, but structured artifacts still matter:

  • Inline cards for each module result.
  • Side-panel artifact viewer for full reports, screenshots, ROI calculator, competitive matrix, sales plays, and ABX editor.
  • Citation/evidence badge behavior across every card.
  • Artifact pinning from chat.
  • “Ask about this” affordance from any card/artifact back into chat.
  • Export/share flows for AE report, leave-behind, battle card, and ABX package.

Runtime Layers

  1. Copilot UI - Next.js, assistant-ui, Vercel AI SDK. - Handles chat, tool invocation, rich rendering, and artifact navigation. - Keeps conversation context light by storing references to backend state.

  2. Copilot Gateway - Next API route or backend BFF that exposes safe, role-aware tools. - Converts natural language intent into deterministic API calls. - Stores tool traces and maps results to UI cards.

  3. PRISM API - FastAPI, typed routers, authorization checks. - Owns accounts, audits, modules, evidence, deliverables, artifacts, freshness.

  4. Workflow Engine - Temporal workflows and activities. - Owns durable execution, retries, timeouts, wave dependencies, and recovery.

  5. Module Runtime - ModuleConfig + schema + playbook + deterministic fetchers. - LLM used only inside bounded module calls or synthesis steps.

  6. Data Plane - PostgreSQL for state, results, claims, events, threads, artifacts. - Object storage for screenshots, PDFs, and generated deliverables.

  7. Quality Plane - Factcheck, schema validation, source validation, screenshot gates, regression evals.

Sequencing Recommendation

Phase 0 — Stabilize Baseline

Goal: make the current state testable and honest.

  • Reconcile v2 registry vs Temporal workflow vs frontend tool list.
  • Decide canonical module names and waves.
  • Restore or retire deleted v1 modules/tests intentionally.
  • Add a visible module capability matrix endpoint.
  • Make quick audit pass reliably for intel-company, intel-techstack, and intel-traffic.
  • Wire audit status updates correctly into audits.status.

Exit criteria:

  • One local quick audit can be launched from API and observed through DB/SSE.
  • UI can show a real module status card from backend state.

Phase 1 — Chat-First Thin Slice

Goal: prove the Claude Desktop style experience with real deterministic execution.

Phase 1 must support both:

  • Quick audit / quick lookup: fast, chat-native account intelligence with rich grounded cards.
  • Full audit launch: durable Temporal workflow with module-by-module progress visible in chat.

The first wow moment is not a choice between the two. It is that the user can decide how deep to go from the same chat surface.

  • Durable account selection and chat thread.
  • check_account_freshness -> quick lookup -> rich cards.
  • run_full_audit starts Temporal and streams module events into chat/thinking panel.
  • Tool results are stored as backend references.
  • Evidence badges render for real sources.

Exit criteria:

  • User can type “Run a quick audit on X,” see real progress, and get three grounded cards.

Phase 2 — Complete Core Audit Loop

Goal: replace the original skill pipeline’s core audit path.

  • Build intel-queries.
  • Build audit-browser.
  • Build intel-competitors.
  • Build audit-factcheck.
  • Build audit-report.
  • Add screenshot/object storage.
  • Preserve current audit-data.json schema as compatibility contract.

Exit criteria:

  • PRISM can produce the same core audit evidence and report package as the skill workflow for one prospect.

Phase 3 — Sales Synthesis And Activation

Goal: turn audited evidence into AE action.

  • Build synth-business-case.
  • Build synth-sales-plays.
  • Build campaign-abx.
  • Integrate Algolia customer evidence deeply.
  • Add editable artifact versions and export/share flows.

Exit criteria:

  • User can move from audit findings to business case, sales plays, and ABX package without leaving PRISM.

Phase 4 — Enterprise Rollout

Goal: make it company-ready.

  • Clerk auth end-to-end.
  • RBAC and account assignment, optimized first for AE and BDR pilot users.
  • Admin module health, cost, queue, and audit logs.
  • Bulk import.
  • Rate/budget controls.
  • Tenant scoping and retention policy.

Exit criteria:

  • Pilot team can safely use PRISM on real accounts with visibility, control, and access boundaries.

Phase 5 — Scout And Discovery OS Integration

Goal: add higher-order capability after baseline reliability.

  • Scout becomes targeted crawl/fetch substrate for blocked or JS-rendered sources.
  • Discovery OS becomes the sales conversation reasoning layer over verified audit state.
  • Neither should replace the baseline audit execution engine.

Opinionated Risks

  1. Do not let chat own state. Chat should feel intelligent, but PostgreSQL and Temporal must own truth.
  2. Do not over-build dashboards before the copilot loop works. Cards and artifacts support chat; they should not become the primary app metaphor.
  3. Do not convert every skill as a generic LLM playbook. Each module needs deterministic fetchers, schema validation, source handling, fallback behavior, and tests.
  4. Do not bury factcheck until the end. The claim registry and citation model need to be designed early or retrofitting will hurt.
  5. Do not incorporate Scout/Discovery OS too early. They are valuable, but they will blur the product if baseline audit execution is not reliable first.

Founder Decisions Captured 2026-05-08

Question Decision
Phase 1 first wow moment Both quick audit/lookup and full audit launch must be available, with progress visible in chat.
Current report package compatibility Exact compatibility is P1, not P0. P0 should explore a better chat-native artifact package first.
Artifact UX Artifacts should be created and presented from chat, with a dynamic right panel opening like Codex/Claude Desktop.
Audit-browser vs competitors sequencing Build audit-browser after intel-queries; build intel-competitors after browser audit.
First pilot persona AE and BDR first.
Editable sales artifacts Editable artifacts are part of v1, not deferred to a later read-only phase.

First Strategic Questions

  1. What is the minimum artifact set for P0 chat-native output: pre-call brief, evidence board, screenshot gallery, ROI sketch, or something else?
  2. How editable should v1 artifacts be: simple text edits, structured field edits, regeneration controls, or collaborative comments?
  3. What is the minimum AE/BDR account workflow: start from domain, imported account list, CRM ownership, or uploaded CSV?
  4. Should quick audit reuse the same Temporal workflow in a smaller mode, or should it be a separate low-latency module bundle with shared result contracts?