Skip to content
← Governance

Invalid changes die before review.

A proposal is checked against the Blueprint before anything else touches it: required fields present, references that resolve, types that match, versions that line up. A change that fails comes back naming the check it failed, and no model is consulted about it. Structure is not a matter of judgement, so nothing at this stage is left to one. The same proposal produces the same verdict on any day, in any workspace.

Checking a known shape is arithmetic

A proposal names the entity, the field and the new value in the Blueprint's own vocabulary. Because the shape is known in advance, checking it is arithmetic rather than interpretation.

Checks run ahead of the reviewer

A malformed proposal is rejected on the spot instead of after a review cycle. The independent critic then spends its attention on intent — whether the change is a good idea — rather than on whether it points at things that exist.

Same input, same verdict

No model sits in this path, so there is nothing here to sample. Run a proposal twice and the result is identical, which is what makes a failed check something you can hang a release gate on.

In this capability

  • Blueprint structure checks
  • Reference and type integrity
  • Pre-review rejection
  • Reproducible verdicts

Stop managing prompts. Start managing software strategy.

Connect your repositories. Let Foundariq understand what you have already built. Then tell it what your portfolio should build next.

Read-only to start · Your code stays in your GitHub · [email protected]