Validation Report

Why validation matters

AI-generated code can look correct while being subtly wrong — a misconfigured entry in a routing manifest, a schema field with the wrong type, a file placed at a path the CLI does not expect. These errors are not always visible at generation time, but they reliably cause failures at pull time or during project setup.

Logic64 addresses this by treating every generation output as untrusted until it passes schema validation. The validation layer runs before any file is written to the bundle archive. If validation fails, packaging is aborted and the error is surfaced to Studio immediately. No partial bundles are ever delivered.

This is the guarantee that makes Logic64 a Hallucination-Constrained platform: what reaches the developer is what passed the schemas. The model output that did not pass never leaves the server.

What gets validated

Validation covers six distinct output categories. Each is checked independently; a failure in any one of them stops packaging.

Reading a passing report

When all validation checks pass, Logic64 Studio displays the bundle as ready. You will see a unique bundle_id and a status of Ready for download. The bundle remains available for 24 hours.

The passing state confirms that every file in the bundle was accepted by the schema layer, every path was cleared by the routing matrix, and the manifest is complete and internally consistent. At this point the bundle is safe to pull.

bundle_id:  a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc
status:     ready
validated:  true
files:      23
# Run this command to pull the bundle onto your machine:
$ logic64 pull a3f2bc89-4d1e-47a0-b8c6-2e5f91340abc

Reading a failing report

When validation fails, Studio shows a structured error panel instead of a bundle ID. The panel identifies:

• Category — which validation category failed (schema, structural, path, cross-file, etc.).
• Target — which specific file or output triggered the failure.
• Details — a human-readable description of the rule that was violated and, where applicable, the value that was found versus what was expected.
• Attempt count — Logic64 shows how many finalize attempts have been made (maximum 2 automatic retries).

No bundle ID is issued on failure. The generation is considered incomplete until either the platform resolves the issue on retry or you adjust your plan and regenerate.

Common rejection reasons

The following patterns account for the majority of validation failures. Understanding them helps you adjust your project description or plan approval to avoid them.

• Invalid manifest entry — A file listed in manifest.json is missing a required field (such as destination or target), has an incorrect type, or references a file that was not generated.
• Schema mismatch in a config file — An MCP config or governance file was generated with a field shape that does not match the expected schema. This often happens when the project description implies a tool that requires a non-standard configuration format.
• File routed to wrong destination — A generated file has a path that does not appear in the Smart Routing Matrix for the declared target_assistant. The CLI would not know where to place it, so the bundle is rejected before packaging.
• Internal contradiction — The approved plan locked a decision (for example, a specific framework or runtime), but a generated file references a different choice. The cross-file consistency check catches this disagreement and rejects the bundle.
• Missing required section in CLAUDE.md — The structural rules check requires certain sections to be present in the AI rules file. A truncated or incomplete generation triggers this failure.

Re-trying after a failure

Logic64 automatically retries bundle finalization up to 2 times when validation fails. Each retry re-runs the full validation chain from the beginning. If both automatic retries are exhausted without a passing result, the generation enters a fatal abort state and no further automatic attempts are made.

At that point, Studio surfaces the structured error from the final attempt. You have two options:

• Adjust your plan and regenerate — Return to the planning step, update the constraint or scope that is causing the contradiction, approve the revised plan, and start a new generation. This is the recommended path when the error points to a cross-file consistency failure or a routing mismatch.
• Simplify scope — If your project description implied a combination of tools or frameworks that produces an inherently ambiguous manifest, narrowing the scope (for example, removing an optional integration) can eliminate the source of the contradiction.

Retry attempts are recorded in the validation panel so you can see the full history of attempts before deciding how to proceed.

The 11-step chain (in plain language)

Every generated file passes through an 11-category quality chain before it is accepted into the bundle. These are not named steps in a visible interface — they are the quality categories that together make up the validation guarantee. In dependency order:

• Parse — The raw output is parsed and confirmed to be well-formed before any further check is attempted.
• Schema — The parsed output is checked against its declared JSON Schema. Required fields must be present and correctly typed.
• Structure — Structural rules specific to each file type are enforced (for example, required sections in governance files, prohibited content patterns).
• Path — Every declared file path is validated to confirm it is a legal path that the CLI can write.
• Routing — Paths are checked against the Smart Routing Matrix for the declared target assistant. Unrecognized destinations are rejected.
• References — Internal references within a file (for example, a file that imports another by path) are confirmed to point to real outputs in the bundle.
• Consistency — The generated stack is compared against the locked plan decisions. Any deviation from the approved framework or runtime is flagged here.
• Completeness — The manifest is checked to confirm every file it declares has actually been generated. No orphan entries are permitted.
• Policy — Output is scanned for content that violates the platform's generation policy (for example, placeholders left unresolved, debug output embedded in production files).
• Cross-file — The full set of generated files is analyzed together to detect contradictions that only appear when files are viewed as a group (for example, two files that declare conflicting values for the same setting).
• Final assembly — The bundle archive is assembled only after all prior checks pass. This step confirms that the archive is well-formed and that its contents match the validated manifest exactly.

A failure at any step stops the chain at that point. The error report identifies which category failed, so you always know where the issue lies without reading through all 11 categories manually.