pAIchart — high-level design in, reviewed low-level design out

— source-available: self-host, modify, redistribute; not as a hosted service to third parties.

Across network devices, Terraform, Kubernetes, and observability stacks (Prometheus / Grafana / OpenTelemetry) — on an open MCP hub. Give pAIchart a requirements.md and a topology.json at any fetchable location — and it returns a reviewed low-level design: per-device config, the exact commands that prove it worked, and a rollback. Your team applies it, idempotently and out of band. pAIchart designs and reviews the change; it never applies it.

The LLD is the bottleneck it removes. Producing one today means a senior engineer reading live state across every box, writing config in each vendor's language, and hand-reconciling the values that cross domains. pAIchart does that work as a graph of specialist agents, checks it in three tiers, and hands you one reviewed result to approve. You stop authoring across every system and start approving one package.

The directed acyclic graph (DAG) coordinates agents

Other solutions give you a DAG of tasks. pAIchart gives you a DAG of reviewed changes.

Every node is a domain pipeline of agents harvest live state → design → author → review and every edge carries a value that did not exist until runtime. Legs with no edge between them run in parallel; a dependency edge forces order and hands the real derived value forward.

                    ┌──▶ [firewall leg] ──┐
[network leg] ──────┼──▶ [cloud leg] ─────┼──▶ [integration review] ──▶ release gate
                    └──▶ [k8s leg] ───────┘
     derived range                              checks all legs against
     exists only after                          the one shared contract
     this leg runs

That's the difference between a graph and a script: the cloud leg authorises exactly the address range the network leg derived, because the cloud leg reads the content the network leg created. There are no pre-defined values in the high level design.

• multiple legs, parallel or sequenced, with context chaining and dependencies
• Four infrastructure domains today — network devices, Terraform, Kubernetes, observability config (Prometheus / Grafana / OpenTelemetry) — plus artifact synthesis, and the shape is extensible: the observability domain was added as a configuration exercise (a protocol, four role templates, a read-only service descriptor), not an engine change
• The graph is declared with the work, in a single PIPELINE task, not in a separate scheduler you also have to operate
• Approval gates release from your AI client or the web UI, over one common code path
• Live state comes from your devices, harvested read-only through per-device MCP servers

How correctness is checked using three tiers, and a lower one can't be overruled

Tier 1 — arithmetic, in code. Where appropriate pAIchart uses code to do a deterministic check rather than an LLM reviewer's confidence. Every derived value is tagged with a kind, and the engine runs the arithmetic for that kind against the harvested evidence — never against the package's restated copy of it:

• cidr — does the derived range cover exactly its declared members? Catches too wide (an already-allocated address swept in) and too narrow (a claimed member falling outside).
• asn — is the AS number inside the private range, and does the harvested state authorize it? The relation deliberately inverts here: the harvest is the allowlist — an AS number the design sets must be one the devices already run, or one the objective explicitly names.

And when a kind isn't implemented, the platform says so. It records the value as not mechanically covered and escalates it to the integration reviewer — it never counts an unchecked value as a passed one. That path is verified end-to-end in VT-14: the reviewer named the uncovered value, traced its provenance, found it had no device config behind it, and blocked over two green legs and its own approval.

Tier 2 — independent reviewers. One per leg against its own contract, plus an integration reviewer across all legs against the shared contract — running the domain's own validators over the composed set (whole-topology Batfish, terraform plan, kubeconform). It consumes those validators; it does not reimplement them.

Tier 3 — the release gate. A deterministic AND: every leg approved AND no containment violation AND any unchecked value carries a benign reason AND the integration reviewer approved AND coverage complete. No confidence number appears in it.

A Tier-1 violation blocks regardless of who approved above it.

The proof is we publish the rounds we failed

Most of this category asks you to trust a demo. We provide 21 verification documents, each stating its expected observables before the run, then recording what actually happened.

See also the ones that went wrong. VT-12: a program self-certified programReleasable: true while shipping an authorization widening. Five tiers passed it, so minimality is now checked in code rather than in prose.

• Two byte-identical review runs scored 45 and 92 on the same input. So confidence was demoted to a recorded fact at every tier, and the release gate decides on verifiable facts alone — there is no confidence number in it.
• A check that couldn't run is a block, not a pass. "We couldn't verify it" never rounds up to "it's fine."
• Three correct change packages were refused because a reviewer judged something it structurally could not see — one wrote "I cannot independently re-verify this comparison" and asserted the conclusion anyway. Better prose closed one lane and the class reappeared in the next, so the comparison is now computed where the evidence lives and handed to the reviewer — who still keeps every judgement the fact does not make (VT-21).

→ Verification pack · every claim linked to its machine record · Protocols · the agent-facing contracts those runs are held against, published verbatim and byte-parity-checked against the platform seed

Five domains, one harness

• Network Provisioning : "add a Loopback0 per switch and advertise it into BGP" → an approved change package the provisioning team applies idempotently: self-provision a read-only device service from a descriptor, harvest real running state, design, author per-device config + validation + rollback, independent reviewer gates it. → example change report
• Kubernetes / GitOps: "add an HPA and resource requests/limits to the orders-api Deployment" → a declarative kustomize overlay from live cluster state, validated offline (kubeconform / kustomize build / OPA and we never kubectl diff). Read-only, RBAC-scoped; secret names surface, values never leave the cluster. → example (includes an earned NEEDS-REVISION — the reviewer refusing to approve what it couldn't verify) · second example (a PodDisruptionBudget in three runs — the first package's own gap list became the objective, the reviewer refused the first attempt on availability arithmetic, and the revision was approved for choosing a different field)
• Observability Config: "add a memory_limiter processor, first in the collector's metrics pipeline, sized for a 256 MB container" → a whole-file desired-state config for a live Prometheus / Grafana / OpenTelemetry stack, harvested read-only from the collector's as-deployed file and Prometheus's running config, with a deterministic pre-apply validation, a presence-shaped post-apply check, and the harvested file as the rollback. → example (the first published package that was also applied, with what the running system displayed afterwards — and the first where the reviewer read a platform-stamped rollback-provenance fact instead of guessing whether a quote was a quote)
• Terraform / Cloud IaC: "add versioning and a public-access-block to the acme-app-logs bucket" → an HCL change package as a PR, from a scoped state pull (no providers launched, no state lock), with validate / plan / tflint / OPA expected-facts and rollback. → example (shows the layered defense: a secret-shaped tag redacted, a prompt-injection tag refused)
• Artifact Synthesis: source material (git history, execution logs, a POV's delivery history, external MCP services) → a publishable deliverable via harvest → author → review. → example

Reaching your live systems safely — the MCP hub

The harvest step is a Hub call, and the same machinery is open to anyone: register a service, discover it by capability, orchestrate it — with per-user identity and no shared API keys.