Archive: SYSLUME's earlier technical-decision work. Current focus: AI agents for SME back-office work → Order Intake

Decision Library

Architecture checks for AI-generated code: what a passing gate proves

By SYSLUMEUpdated 13 September 20262 min read

A practical distinction between written instructions, executable controls and the evidence needed to accept a change.

Start with one falsifiable rule

“Keep the architecture clean” cannot directly become a gate. “Billing may import Workflow only through api or contracts” can be checked against a defined source layout. Name the modules, rule, language and allowed surface before choosing a tool.

Our fictional Python demonstration uses AST parsing to identify static imports. It reads source without running the inspected application. The full walkthrough includes source, commands and expected results.

Three different statements

StatementEvidence required
The policy existsA versioned policy artifact
The selected source follows the import policyA scoped, successful check on the source revision
The system meets the business and security requirementsAdditional behavior, operations and security evidence; the import check is insufficient

Negative controls prevent misleading confidence

A passing fixture is not enough. Include a private cross-module import and require a failure. Include an empty source directory and a syntax error: these must not quietly look like success. Include a valid same-module import so the checker is not simply rejecting everything.

Our supplied controls cover each of those cases, several private import forms and a recognized dynamic import mechanism. They do not cover all runtime dependency paths or obfuscation. Stating that boundary makes the evidence useful rather than pretending the tool understands the entire system.

Keep the gate downstream of the decision

When ownership or deployment constraints change, review the ADR before editing the policy. A gate can enforce an outdated rule perfectly. Record why an exception is needed, who accepted it, how long it lasts and which evidence will close it.

Use the result in a delivery review

  1. Identify the source revision, command and policy version.
  2. Collect actual output, including findings.
  3. Distinguish failures from checks that did not run.
  4. Record actions and owners for gaps.
  5. Recheck only the agreed changes and evidence cutoff.

A local demonstration run is not a remotely executed CI result. The example includes a GitHub Actions workflow for reuse, but does not claim that workflow has already run in a customer's repository.

What to try next

Download the demo, reproduce its deliberate failure, then inspect its correction. If your team needs the equivalent rule in another language, first agree the adapter's coverage and failure cases.

Download the runnable pack Check fit for a repository handoff

Reference

Thoughtworks: Building Evolutionary Architectures discusses fitness functions and automated governance. The Python example and its limits are SYSLUME's own demonstration.