The story behind the research
Welcome. If you opened this library and thought "that's a lot of documentation," you're right. Sorry about that.
None of this started as a research program. It started as notes, diagrams, architecture changes, and working documents I needed while building Nexus. At some point the system became too much for one person to carry in their head, so I kept the documentation. What I ended up with was a record of the adventure — not just what worked, but how the thinking changed as the system grew.
I also didn't want to oversell it. AI makes it easy to believe your system does more than it actually does. I needed to separate what I *thought* was happening from what I could show. What was implemented vs. what was tested. What still needed evidence.
That's why the work spread into a book, architecture papers, an audit methodology, technical references, and an evidence library. They're all connected. They just have different jobs.
A little about me
My name is Chris Campbell... I'm not a computer scientist. I'm a manufacturing logistics analyst. My background is warehouses, shipping, Oracle ERP, SQL, ISO 9001, process mapping, and continuous improvement.
Looking back, I didn't change how I solve problems. The material changed. Instead of tracking inventory, I track information. Instead of writing work instructions, I write runtime architecture. Instead of investigating why a shipment failed, I investigate why an AI forgot context, repeated itself, or used the wrong tool.
Before Nexus, I built things like an eight-approver Management of Change workflow in Smartsheet and an open purchase-order report that connected planning data with ERP data. Those projects taught me the same lesson:
A good system should be easy to inspect, easy to repair, and easy to upgrade.
How I think
I learn through relationships. Once I can connect something new to a process I already understand, it clicks. SQL made sense through warehouse data. Software architecture made sense through process flow. AI made sense when I stopped looking at it as one model and started looking at it as a system.
ADHD plays a role. I don't call it a superpower... it's more like a catch-22. The same wiring that gives me hyperfocus, rapid pattern recognition, and the ability to visualize material flow in my head also comes with real side effects. Mental and physical exhaustion after activation. Forgotten details. Connections that branch faster than I can document them. So I externalize my thinking through diagrams, workflows, checklists, and clear handoffs. Not to hide the ADHD, but to make it sustainable.
A psychologist once pointed out that I think in layers — architecture, interactions, reactions, relationships, all at once. That observation helped inspire the dyad-node weighting idea inside Nexus. Some governance concepts came from conversations with an aerospace engineer.
Nobody should own the whole conversation. A process engineer, software engineer, psychologist, operator, auditor, researcher, and end user each notice different parts of the same problem. Everyone gets a seat at the table. The system gets stronger when those perspectives can actually influence the design.
It also reinforced something I've had to learn: different doesn't automatically mean wrong. Sometimes a process or architecture looks unfamiliar because it was built from a different way of seeing the problem.
Why the library is separated
Each artifact has a different responsibility:
- The book explains the thinking
- CRA explains the architecture
- CRAM explains the inspection method
- Nexus is the reference implementation
- The Technical Reference shows how the parts fit together
- The Evidence Library shows what's actually been demonstrated
The documentation follows the same design principle as the runtime: separate the responsibilities, make the handoffs visible, and don't ask one component to carry everything.