Skip to main content
The implementation graph is the foundation of Panaptico. It is a live, machine-readable representation of your entire implementation spanning three simultaneous dimensions. Everything in the product — checklists, diagrams, stakeholder maps, health scores, approvals, artifacts, audit logs — is a view over this single underlying graph.

System state

What actually exists in your environment — discovered through read-only provider connections.
  • Live infrastructure across AWS, Azure, GCP, Okta, Snowflake, Databricks, and other providers
  • Resources, configurations, and relationships
  • Mapping states: confirmed (verified by a human), inferred (AI-detected), or flagged (needs review)
  • Not assumptions from kickoff meetings — actual discovered state

Work state

What needs to happen, what’s blocked, and what’s completed.
  • Phased tasks with dependencies, acceptance criteria, and effort estimates
  • Evidence requirements and verification proofs attached to each task
  • Execution results and AI-assisted diagnostics
  • Approval chains with named approvers and routing
  • Risks and blockers with severity, ownership, and downstream impact
  • Generated artifacts — configs, manifests, exports, diagrams

Organizational state

Who owns decisions, who approves changes, and where gaps exist.
  • Stakeholder maps with relationship types (reports-to, approves, blocks, escalates, depends-on)
  • RACI matrix assignments per task per stakeholder
  • Ownership matrix with required functions and assignment status (mapped, confirmed, missing, blocker)
  • Readiness scoring and alignment gaps
  • Unresolved decisions with escalation paths and named owners

Why a unified graph matters

Traditional implementations scatter state across Jira boards, Confluence pages, Slack threads, consultant decks, and email. When something changes, every surface has to be manually updated — and they never are. In Panaptico, when discovery surfaces a missing dependency or configuration mismatch:
  • Relevant tasks reflect the change
  • Relevant risks surface automatically
  • Relevant owners see the impact
  • Relevant approvals route to the right people
  • Relevant evidence requirements adjust
Nothing has to be manually translated between project surfaces because there is only one underlying state.

What the graph contains

LayerWhat it models
Systems ontologyProviders, systems, resources, integrations, relationships, mapping states
Implementation checklistPhases, tasks, dependencies, owners, evidence, approvals, execution results
Process flowsCross-system workflows, actors, durations, variants, bottlenecks
Stakeholder mapRoles, RACI assignments, ownership matrix, unresolved decisions
Architecture diagramsTask dependency graphs, critical path, status visualization
GoalsSuccess metrics, measurable outcomes, target values
Post-implementation planSupport model, monitoring, adoption tracking, continuous improvement
Health historySnapshots, baselines, drift detection, scored domains
File vaultGenerated configs, exports, uploads, evidence artifacts
Audit trailEvery change, decision, approval, and state transition — timestamped and attributed

Reconciliation

The graph is not static. Panaptico reconciles discovered state against intended state and classifies each gap:
  • Ignore — cosmetic or expected variance
  • Watch — worth tracking but not actionable yet
  • Route to task — needs work, creates or updates a checklist item
  • Block dependent work — downstream tasks cannot proceed
  • Request approval — requires human decision
  • Re-baseline — the new state is the intended state
This is a state-transition layer, not a loud alerting layer. Mismatches become governed work — not just notifications.

Next steps

Systems Architect

Learn about the AI blueprint engine

Blueprints

Understand blueprint structure