Harnax Architecture: Compliance Layer, Discovery, Reflexive Loop, and Parallax

TL;DR

• Harnax compliance layer uses a Kuzu graph database that walks code, generates an AST, and maps it to specifications defined through human conversation with agents
• Discovery mechanism (Harnax Discover) walks an existing codebase to suggest/propose domains, letting you formalize and audit code against a spec without touching or needing end-to-end tests
• Reflexive loop is a planned feature where counterpointed skills assess diffs/code changes for robustness, efficiency, and performance, running after each build to catch subtle misunderstandings
• Parallax (possibly renamed Parallaxe) spins up parallel virtual work tracks (GDKs) that each focus on one issue/MR/feature, defined via question-answer to resolve ambiguity, enabling high throughput
• Each parallel work track goes through the validation harness and iterates before being pushed up and released

The Harnax Compliance Layer

This is an idea I’ve had for a while: the Harnax compliance layer I’ve been building uses a Kuzu graph database that walks the code, generates an abstract syntax tree, and maps it to specifications. It’s not perfect yet, but it’s getting there, and it allows agents to understand how the codebase’s implementation maps to specifications defined by humans through natural conversation and formalized by agents. You have a conversation with an agent about an idea, the agent asks questions to resolve ambiguity, then formalizes what you discussed, and begins the build process—building the code while mapping the spec-to-code relationships in the graph database. Everything is verifiable through validator chains and test harnesses within Harnax.

Discovery Mechanism for Existing Codebases

There’s also a discovery mechanism that lets you take advantage of an existing codebase by running the Harnax Discover runtime, which walks the codebase and discovers, suggests, and proposes domains. You can then formalize those domains and go through the same question-answer process to resolve ambiguity or explain why certain things exist the way they do when there’s conflict. This lets you audit your code against a spec regardless of what language it’s written in—you don’t even need to touch the code. It enables comprehensive end-to-end testing without needing a proper end-to-end implementation service, which is a massive risk reduction.

The Reflexive Loop (Planned)

The reflexive loop is a way to have the harness deploy various skills that are counterpointed against each other, examining diffs or code changes and assessing robustness, efficiency, performance, and other factors from different, subtle viewpoints. This increases confidence that the code matches the spec and follows the specification in the graph database, uncovering subtle misunderstandings, nuances, or edge cases. It’s a loop that runs after each build as part of the test/verification harness.

Parallax: Parallel Virtual Work Tracks

Once the reflexive loop is done, there’s another system I’ve built called Parallax, which I want to rename to Parallaxe to match Harnax. It spins up individual virtual work tracks, essentially GDKs, each focused specifically on one issue, one MR, or one new feature/improvement. These run in parallel without interfering with each other, so you can tackle several issues or feature implementations at once. Features are defined through a question-answer method to resolve ambiguity, running on separate work tracks in parallel to whatever issues and MRs you’re already working on—enabling large throughput. Each track goes through the validation harness, iterates on itself, and runs through additional loops to ensure high quality before being pushed up and released.