A compilation walks through seven Stages, from parsing your natural-language declaration to producing the final commit-ready graph. When something goes wrong, the Architect's Ledger tells you which Stage stalled and why. This article shows you how to read the Ledger and figure out the next move.
Open the Architect's Ledger
- Open the workspace dashboard.
- Find your run in the runs list and open it. The URL pattern is
/<workspace>/runs/<run-id>. - The Ledger shows per-Stage status, timing, and any attached vendor errors.
Map the Stage to a likely cause
Stage 1 — parse + ambiguity normalization
Failures here usually mean the declaration is too vague or contradicts itself. Look at the Stage 1b output for the ambiguities the compiler asked about. Refine the declaration to resolve them and try again.
Stage 2 — Component decomposition
Stalls here are often a sign of declaration scope creep. If you are seeing far more Components than you expected, your declaration may be inadvertently asking for many subsystems. Try splitting into multiple smaller projects.
Stages 3 / 4 — Decisions and supporting entities
These are usually quick. Failures here typically surface vendor errors (rate limits, transient 5xx). Check your vendor status page and retry; if vendor outage is platform-wide, see our own status page.
Stage 5 — Tickets, tests, reconciliation
This is where most cost and most failures live. Common causes:
- Per-branch budget exhausted. A single Component is too large for the budget. Simplify the Component's scope in the declaration.
- Cycle detected. The Component or Decision dependency graph has a cycle. The Ledger names the cycle.
- Capability mismatch. Your declared fleet tier mix cannot perform some of the work; the Ledger says so and offers the option to revise either your declaration or your declared fleet capability.
Stage 6 — your review checkpoint
Stage 6 is by design — it waits for you to review the Architect's Ledger and accept, edit, or revise. Apply your edits as an RFC 6902 patch; the Ledger walks you through the allowed fields. Note that a small set of fields (such as fleet_override) is intentionally not editable at this stage.
Stage 7 — atomic commit + critic
We run a Layer 4 critic immediately before commit (operator-paid on our side, never charged to your BYOK key). If the critic flags the output, the commit is blocked and the Ledger explains the flag. Critic blocks are uncommon but real; the false-negative cost is high enough that we err toward false positives. Email support if you believe the flag is wrong.
Slow vs failing
A slow compilation is usually a vendor-side delay (frontier vendor latency or rate limiting). A failing compilation always leaves an explicit error attached to a Stage in the Ledger. If the Ledger shows no error and the Stage simply has not advanced in 15+ minutes, treat it as a platform issue and email support with the run ID.
When to ask us to look
Please email support if:
- The Ledger is empty or missing entries you expect to see.
- The error message is internal-looking or unclear.
- The same compilation fails consistently after retries.
We will normally start with read-only diagnostics. If we need to run a reproducer that requires looking inside your workspace, we use operator-impersonation, which always leaves an entry in your audit log so you can see exactly when and why we did so.
Paired with the SR-COMPILE-001 customer-support flow.