Research / Living questions
How we deliver software, and how we govern systems whose behavior relies on model judgment — including AI agents in production.
01 / Research
01 How we deliver software
What happens across review, testing, security and maintenance when generating code gets easier? This research synthesis studies AI-assisted software delivery as a complete system: verification capacity, code quality, technical debt and long-term ownership, with an inspectable evidence library and adaptable operating protocols.
02 What we build
How do we design and operate software whose behavior depends on probabilistic Model Judgment? Uncertainty Architecture develops an engineering vocabulary and draft specification for Thinking Systems, AI control architecture, evaluation, decision authority, runtime control and correction.
The repositories hold the living research and its sources. My articles connect the ideas across both directions.
Two engineering lenses
Where is the bottleneck, and does speeding up one step improve the whole system? The Subprime Code Crisis uses Goldratt’s Theory of Constraints as a lens for verification capacity, work in progress and delivery throughput.
Read the delivery-system interpretation ↗What do we observe, who can act, and how do we correct behavior? My AI governance writing connects feedback, operating boundaries and corrective action to the design of model-mediated systems.
Read the control-theory article ↗Research themes
The technical system and the human operating model have to work together. These are the questions behind my writing.
In UA, Thinking Systems are identified by material runtime responsibilities that depend partly on probabilistic Model Judgment. The category is about an engineering condition, not consciousness or a guarantee of reliability.
Judgment Nodes locate where model judgment influences behavior; Uncertainty Boundaries connect deterministic responsibilities with that judgment.
Read the current UA vocabularyMy AI governance work applies control-theory ideas to boundaries, evidence, decision authority and corrective action. UA's AI Control Plane is a distributed capability model across software, evaluation, release decisions and human workflows — not necessarily a central platform.
Explore the control capabilitiesWhich model-mediated outputs, decisions or actions can materially affect outcomes, constraints, authority or downstream people and systems? That question helps connect AI architecture with evaluation, release evidence and accountability.
Read the responsibility boundaryI study the socio-technical stack around AI: how team roles, review practices, decision rights, evaluation and incident ownership fit together. AI governance is not only a model setting; it also concerns how people operate and change the system.
Read about operating models & deliveryThese Reddit exchanges include practical suggestions, alternative explanations and technical criticism.
Practitioners discuss verification gates, specifications and ownership, including where bounded agent workflows can help and where costs move downstream.
r/softwarearchitecture
≈48K post views · 55 comments
A discussion of review capacity and delivery bottlenecks, with challenges to using code volume or release counts as measures of value.
r/softwarearchitecture
≈13K post views · 30 comments
An early discussion of control-theory framing, including questions about controller responsibilities, technical specificity and latency.
r/learndatascience
≈34K post views · 41 comments
Counts from author-supplied Reddit snapshots reviewed 7 Oct 2026; capture dates were not recorded. Views are approximate, not unique readers; comments include replies by the author and other participants.
Advisory context & public responses
UA project advisors and public contributions, with the context and source for each relationship.
CPMAI Lead Coach | PMI AI Standards Core Team
Focus: project-management standards, organizational alignment, and the operationalization of AI governance.
Connected the UA control-theory framing with CPMAI practices in a public discussion of constraints, sensors, roles and governance gates.
Read the public recordProfessor of Intelligent Systems at the University of Waterloo
Focus: control-theoretic research and practical engineering governance.
Shared his Social Responsibility Stack paper in the public discussion of UA under Michael Risch’s post, bringing a related control-theoretic perspective into the conversation.
Read the public recordThese advisory roles are with the UA project. They do not imply institutional endorsement, certification or adoption. Sources and contribution context ↗
Chief Technology Officer · Taller
Supported the changed-engineering-object framing, emphasizing boundaries, evidence, authority, correction loops and the return of human judgment.
Principal Founder & Executive Chairman · EPAM
Recommended a full reading of Thinking Systems and extended the argument toward new addressable problems, domain-specific bounding architecture and runtime control.
Separate formulation credit: “Thinking Systems” provenance.
Founder & CEO · Taller
Christophe cited UA in his explanation of agentic-system control. Taller’s public visual explainer also draws on UA to connect probability distributions, control signals and feedback.
Read the public recordAI Platform & Developer Acceleration · Corning
Hosted the Corning Learn-AI-Palooza discussion and publicly reflected on UA’s relevance to system-level risks, team behavior, ownership and governance.
Read the public recordSenior Project Manager
Developed a public operational interpretation of UA, connecting control loops to roles such as Prompt Steward and Evaluation Owner, evaluation signals and governance practices.
Read the public recordFounder · Conflux; co-author of Team Topologies
Reshared Michael Risch’s discussion of my AI governance and control-theory article, quoting its framing of governance as bringing business intent back into the system.
Read the public recordMichael Risch’s original discussion
He also offered public encouragement for UA’s development in the project’s milestone discussion.