Hiroyuki Nakahata

Thanks for the comment! This has been a core concern since the beginning of ArchSig’s development: we explicitly distinguish an observed zero from something that has not been observed. If an agent cannot determine a value, it should mark it as unobserved, and the tool’s output preserves that distinction too.

Thanks for the comment! I agree. With AI writing code so quickly, I think it’s especially important to spell out the properties we want to preserve and check that they still hold.

Thanks for the comment! That’s exactly the issue. I’m currently developing a SKILL to help agents produce more accurate ArchMaps from code. The idea is to improve accuracy by having multiple agents observe the code using that SKILL. Problems that those observations cannot capture, such as runtime race conditions, are outside the scope of what AAT can establish from the resulting ArchMap.

Thanks for your comment! I’m glad you read the article. I chose to focus on refactoring AI-generated code, which I expect to become an increasingly important challenge in the age of AI. I’ll keep working on tools to bring Ariadne into everyday software development!

Thanks for the comment! Documentation is really important, but I think it also needs a clear management policy. In my project, I organize documents into four tiers. Tier 1 contains the canonical documents that affect the entire project. Tier 2 defines development rules and guidelines. Tier 3 contains task-level design documents and PRDs, while Tier 4 is for notes and informal working material. By separating documents into tiers, it becomes easier to define which source takes priority when documents conflict, and to keep the direction of dependencies between documents clear.

Thanks for the comment! That’s a really interesting point. For a general semantic layer, I agree that you’d need some form of cache invalidation or versioning to make sure stale references don’t remain in use. AAT is aiming to model the geometry of meaning in a codebase, so the idea is for ArchMap to be updated synchronously whenever the code changes. In other words, the operational assumption is that an AI agent should not end up reasoning from an outdated semantic model in the first place.

Great question — yes, false negatives happen, and the design accepts them deliberately. The auditor's verdicts distinguish unverified (evidence not found where it looked) from unmet, so the case you describe surfaces as the auditor's limitation and costs one round trip to resolve: point at the evidence, re-check. That asymmetry is intentional — a false "not done" costs a round trip; a false "done" corrupts the gate itself. The direction we actually had to iterate on was the opposite: the auditor trusting records produced by the loop it audits (ledgers, checklists). The fix was an evidence hierarchy — "satisfied" may only be grounded in primary evidence (reading the actual code/statements, running the checks), and one mismatch between a record and reality disqualifies that whole document as evidence. Your instinct is right: the auditor went through the same iteration as the loop — several discipline waves, plus an adversarial review that found fail-closed gaps in the auditor itself. The current rules are here if you want the details: prd-loop (https://github.com/iroha1203/AlgebraicArchitectureTheoryV2/blob/main/.codex/skills/prd-loop/SKILL.md)