> ## Documentation Index > Fetch the complete documentation index at: https://panaptico.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Implementation graph > The unified data model powering Panaptico 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 | Layer | What it models | | ---------------------------- | ----------------------------------------------------------------------------------- | | **Systems ontology** | Providers, systems, resources, integrations, relationships, mapping states | | **Implementation checklist** | Phases, tasks, dependencies, owners, evidence, approvals, execution results | | **Process flows** | Cross-system workflows, actors, durations, variants, bottlenecks | | **Stakeholder map** | Roles, RACI assignments, ownership matrix, unresolved decisions | | **Architecture diagrams** | Task dependency graphs, critical path, status visualization | | **Goals** | Success metrics, measurable outcomes, target values | | **Post-implementation plan** | Support model, monitoring, adoption tracking, continuous improvement | | **Health history** | Snapshots, baselines, drift detection, scored domains | | **File vault** | Generated configs, exports, uploads, evidence artifacts | | **Audit trail** | Every 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 Learn about the AI blueprint engine Understand blueprint structure