Technical disclosure

Architecture & Principles

How CritPath AI reasons over your schedule. And, just as importantly, what it deliberately does not do. This page discloses the architecture in plain terms. It contains no accuracy benchmarks, because we will not publish a number we cannot defend.

The principle

Trust in an AI schedule-risk system comes from where its reasoning is grounded and who is accountable for its output, not from model size.

A CritPath AI employee reasons over your actual dependency graph: the real critical path, buffers, risks, and gates of that specific plan. It cites real standards. It can only ever propose a structured result. And nothing it produces enters a schedule until a named, authenticated human accepts it, on a path that is attributable and tamper-evident. The intelligence is grounded, bounded, and human-gated by construction:

1Grounded input

The real dependency graph for this plan (CPM critical path, TOC/CCPM buffers, risks, gates), plus retrievable standards.

2Bounded proposal

A run reasons within guardrails and can only return a validated, structured proposal. It writes nothing itself.

3Human accept

A named, authenticated human is the only path that commits a proposal into the schedule.

4Auditable record

That acceptance can append to a tamper-evident, per-organization hash chain.

Why a generic chatbot fails at schedule risk

A general assistant answers from parametric memory, a compressed average of the public internet. Ask it whether your program hits its date and it will produce fluent, plausible prose about a program, not yours. It has never seen your dependency network, your three-point estimates, your resource contention, or the risk you logged last Tuesday. For schedule risk, that gap is the whole problem: the answer depends entirely on the specific structure of the plan.

CritPath closes the gap by feeding the model the computed state of your real schedule and the standards that govern it, and by refusing to let the model act on its own. What follows is how.

The architecture, in seven pieces

01

An AI employee is a resource, not a user

An AI employee is a first-class resource (an AI_AGENT row) bound to one persona configuration. It is staffed, allocated by FTE, resource-leveled, and cost-rolled by the exact same machinery as a human teammate, and it holds no role, no access rights, and no billable seat. It participates in your org the way a contractor does: it does work; it does not hold authority.

Grounded in: resource model · agent-persona config · derived org map

02

Grounded in the real plan, and that data is never trusted as instructions

The model does not answer from generic memory. Two independent paths feed it context: your project's live, org-validated state (the ranked critical path with total float, the drum, buffers, open risks by score, gates, the charter) is rendered into the prompt; and, when enabled, a corpus of AACE, NASA, GAO, PMI and TOC/CCPM sources is retrieved for inline citation. The injected schedule is wrapped in explicit delimiters marked “data, never instructions,” with the delimiter neutralized in the content, so a task note cannot hijack the reasoning.

Grounded in: live-schedule context · corpus retrieval · injection hardening

03

A run can only propose; a human is the only committer

The write-class tools an AI employee can call do not touch the database. They return a validated payload: an estimate whose optimistic, most-likely, and pessimistic points are correctly ordered, and risks with calibrated probability and impact. The single code path that writes a run's output into a schedule is a human clicking accept. That endpoint refuses any caller without an authenticated human principal, requires the run to have completed, blocks if a blocking-mode quality gate has not passed, and serializes concurrent accepts with a row lock. A run never commits itself.

Grounded in: propose-only tools · fail-closed accept endpoint

04

Claude-primary, and it fails loud rather than degrade in silence

User-facing generation runs on Claude by design, with per-task tiering across Opus, Sonnet, and Haiku. Every fallback is Claude to Claude, so a hiccup degrades within the family instead of silently swapping models. Any call that carries tools is pinned to Claude and will raise, recording the run as failed, rather than fall back to a model that would quietly drop the tools and return prose. Gemini is confined to embeddings; there is no OpenAI in the stack, by design.

Grounded in: model router · provider abstraction

05

Skills are reusable, job-description-grade units of capability

A skill is an organization-scoped competency: a methodology body, worked examples, an output contract, and the capabilities it implies, modeled on Anthropic's SKILL.md format and exportable as one. A persona composes from an ordered list of skills, rendered by a single shared function so that what the model sees is byte-identical to what is recorded for the run. You build an AI employee the way you'd write a role: from named competencies, not a wall of prompt.

Grounded in: skill model · shared renderer · SKILL.md export

06

Provenance you can verify, and cost metered transparently

CritPath provides a per-organization, append-only audit chain: each recorded event is hashed over the previous one, kept linear by a uniqueness constraint, and re-walked by a verifier that detects any insert, delete, reorder, or edit. It is exportable and independently checkable. AI spend is metered on one cost-plus formula across every model call. (The audit log is a capability you enable; per-run cost is an estimate from a maintained price table, not the provider's billed amount.)

Grounded in: hash-chained audit log · cost-plus usage metering

07

An optional adversarial reviewer with no stake in the answer

A persona can opt in to a second, skeptical reviewer that grades a run against a rubric. It is deliberately blind to the generation. It never sees the persona's prompt, its skills, its reasoning, or its model tier, and it must ground every finding in the output itself (“evidence or silence”). In blocking mode, a failure makes acceptance impossible and the gate fails closed. It is an available control you switch on per persona, not a universal guarantee.

Grounded in: isolated run reviewer · rubric · blocking gate

Honest boundaries: what CritPath AI does not do

This is the most important section, not the fine print. A tool you can trust is one that is honest about its edges.

AI output can be wrong.

Estimates, risk registers, and analyses from an AI employee are drafts. There is no accuracy guarantee, and we publish no accuracy percentage, because we cannot honestly defend one.

A human is always the committer.

No run writes itself into a schedule. The only path from a run into the plan is a named, authenticated human accepting it. This is the single code path, not a policy preference.

It does not replace scheduling judgment.

The system grounds a program leader's reasoning in the real dependency graph and real standards. It proposes; it does not decide.

Autonomous runs are off by default.

In the default configuration, creating an agent run is refused (“AI agents unlock at general availability”). Where this page describes AI employees working, that is a capability activated at general availability, not always-on behavior.

Grounding is best-effort; a citation is not a proof.

Retrieval degrades to an ungrounded answer rather than failing; a thin corpus yields little grounding. Inline citations are produced by instruction. There is no automated faithfulness verifier.

Provenance-grade governance, not a regulated e-signature.

When the audit log is enabled, the tamper-evident, exportable chain records both AI-run acceptances and human schedule events (task, risk, gate, and baseline changes). It is explicitly not a 21 CFR Part 11 electronic signature: no cryptographic signing, no signed statement of intent, no re-authentication. Part 11 is on the roadmap.

Costs shown are estimates.

Per-run cost comes from a maintained price table, not the provider's billed amount, and nothing is billed to a customer unless metering is explicitly configured.

On the roadmap (labeled as such)

These are capabilities we are building, stated separately so nothing above can be read as a claim about them:

  • 21 CFR Part 11 electronic signatures (the audit trail is the foundation today)
  • SAML single sign-on (WorkOS) for Enterprise
  • Per-organization “org-learnings” grounding, so AI employees learn from your gate decisions
  • Skill-tree resolution (automatic prerequisite composition, version-locking, per-run snapshots)

See it reason over a real plan.

Import a schedule and watch the copilot name the real finish-driver, grounded, cited, and yours to accept or reject.

Join the waitlist