FIELD NOTES · DATAMIMIC CE AND EE
What architecture checks found during two agentic refactorings
Tests passed while imports crossed declared interfaces. In two DATAMIMIC refactorings, ArchKeel reported those boundaries so we could inspect and correct them.
Teams at rapiddweller use ArchKeel across projects and technologies, including DATAMIMIC CE, EE and platform projects. Alexander Kell develops both DATAMIMIC and ArchKeel. The cases below describe our own DATAMIMIC work; they are not independent customer testimonials or a productivity benchmark. The two original accounts contain the full context and limitations.
DATAMIMIC CE: four internal imports
In September 2026, an agent introduced four imports of invalid_locale_error from an internal Errors module. The imports worked, but the architecture contract required callers to use the public Errors interface.
from datamimic_ce.errors.factory import invalid_locale_error # introduced
from datamimic_ce.errors import invalid_locale_error # correctedArchKeel recorded four INTERFACES-ONLY violations. The correction removed all four without widening the contract or the baseline. The architecture check ran after the agent committed; focused tests, lint and type checks had run earlier. We identified pre-handover checking as a workflow change to try.
Introducing commit · Correction · Full CE account
DATAMIMIC EE: the public interface was already there
An Include helper imported DescriptorLocation from an internal Errors module even though the same class was available through the public API. This was one of three native interface findings in the package review. The focused candidate suite passed 123 tests; 340 architecture and 270 contract tests also passed.
from datamimic_ee.errors.context import DescriptorLocation # before
from datamimic_ee.errors import DescriptorLocation # afterThe import correction was type-only and left the runtime AST unchanged. The other two findings required publishing specific constants at their planned owner. The package was held until the findings were resolved; broader access was not granted. Read the full EE account.
What the checks did not establish
An early CE before/after comparison accidentally loaded some submodules from the wrong revision. The affected results were marked VOID and module origins were checked in later runs. An architecture check cannot establish which implementation a test process loaded.
In EE, a separate review reproduced mutation through a supposedly read-only Scripting API while the existing 13 API tests passed. ArchKeel's structural checks could not prove that runtime behavior; the team corrected the snapshot boundary and added behavioral cases.
Results still contained uncertainty
At the accepted CE revision, ArchKeel 2.0.0 observed 488 Python files and reported zero declared architecture violations alongside 286 UNKNOWN records. The original acceptance criterion of zero material UNKNOWN positions was revised; the UNKNOWNs remained and were assessed separately. The checker and target had changed during the work, so the earlier 91 violations and final zero are not a controlled before/after comparison.
At EE's final architecture report, declared violations were zero while the overall declared-rules result remained UNKNOWN. The report retained 92 UNKNOWN analyzer records and validation returned 427 advisories. The final pipeline reported 9,231 passing tests across 37 jobs; those tests cover different questions from the architecture report.
We did not measure an agent speedup or a complete count of autonomous pre-commit repairs. Neither project outcome proves every design choice or all runtime behavior correct.
Reproduce a forbidden import in a public Python fixture, inspect the finding, and run a baseline check.
Python architecture boundary guide →