Architecture — PRISM

Product Target

PRISM converts a local, file-based, multi-agent skill workflow into a SaaS platform.

The core transformation:

Claude skill orchestrator + scratchpad files + local scripts
  -> authenticated SaaS app
  -> deterministic workflow execution
  -> persisted account/audit/module data
  -> evidence-aware claim registry
  -> copilot-first interface
  -> enterprise rollout controls

Baseline Skill Architecture

The parent skill algolia-search-audit is a pure orchestrator. It does not do research itself. It spawns worker agents in waves and checks file-based gates.

algolia-search-audit
  Wave 1: intelligence collection
  Wave 2: test query generation
  Layer 2: browser audit
  Layer 3: synthesis/report
  Layer 3D: ABX campaign
  Layer 4: factcheck
  Step 5: local review + publish

Communication is file-based:

$ALGOLIA_AUDIT_DIR/{Company}/
  research/
  deliverables/
  deliverables/screenshots/
  audit-progress.jsonl

SaaS Architecture Translation

Skill-system primitive	PRISM SaaS primitive
$ALGOLIA_AUDIT_DIR/{Company} workspace	Account + Audit rows in database
research/*.md scratchpads	Module execution records + rendered narrative views
*.json sidecars	Typed module output JSONB
audit-progress.jsonl	Workflow event log / audit timeline
Parent skill wave orchestration	Temporal workflow
Worker skill invocation	Module activity or agent job
Verification gates	Workflow blockers + validation jobs
Browser screenshots on disk	Evidence artifacts in object storage / persisted local artifact store
audit-data.json	Composed audit view model
HTML/PDF deliverables	Generated report artifacts
Factcheck gate	Share/publish approval state

Current Repo Architecture

The current v2 direction already mirrors this:

• ModuleConfig = module identity / system prompt equivalent
• playbook.md = module instructions / research methodology
• schemas.py = Pydantic output contract
• ModuleExecutor = generic execution harness
• V2_MODULE_REGISTRY = module catalog
• Temporal run_module activity = module execution boundary
• FastAPI routers = API surface
• Next frontend = current dashboard/chat surface

Architectural Opinion

The v2 module pattern is directionally right, but it should be judged against the original skill system, not only against the newer PRISM docs. A module is complete only when it preserves the original skill's:

• data sources
• execution rules
• output contract
• evidence labels
• failure/degraded modes
• verification gate
• downstream consumers

Copilot-First Implication

If the UI becomes embedded-chat-first, the backend still needs deterministic state. The copilot should not replace workflow state; it should sit on top of it.

Likely model:

User asks copilot to audit a prospect
  -> copilot proposes/starts deterministic workflow
  -> modules run with visible progress and evidence
  -> copilot explains, compares, and helps generate deliverables
  -> user approves share/publish after factcheck gate