What I’m Working On Now
I believe effective AI leadership requires understanding what happens beneath the management layer. I am developing the Engineering System, Personal Operating Environment (POE), and Phronesis—a modular, AI-enabled network and operational intelligence platform—to gain hands-on insight into how AI-enabled solutions are architected, governed, built, verified, and scaled. This experience strengthens the technical judgment, risk awareness, and informed oversight I bring to leading complex enterprise AI initiatives.
Building a Governed Engineering System for Enterprise AI
Artificial intelligence can dramatically increase the speed and scope of software engineering. But greater capability creates a corresponding enterprise challenge:
How do organizations accelerate with AI without surrendering architecture, quality, governance, evidence, accountability, or control?
That question is at the center of my current work.
I have developed an Engineering System for governed AI-assisted software development—an architecture-first engineering governance platform and methodology that defines how humans and AI collaborate across the software engineering lifecycle.
The Engineering System is designed to make AI a powerful participant in enterprise engineering without making the AI the authority over the engineering process.
THE ENGINEERING SYSTEM ESTABLISHES THE STANDARD.
POE PROVES THE STANDARD IN PRACTICE.
PHRONESIS EXTENDS THE STANDARD TO SCALE.
The Engineering System
Enterprise Discipline for Human + AI Engineering
The Engineering System began with a practical observation.
AI coding agents can do considerably more than generate snippets of code. They can analyze repositories, evaluate requirements, assist with architecture, implement substantial changes, develop tests, investigate defects, execute verification, prepare documentation, and reason across complex engineering problems.
That capability creates tremendous leverage.
It also raises questions that become increasingly important as AI assumes greater responsibility:
- Who determines the architecture?
- What is the AI authorized to change?
- How is implementation scope controlled?
- How do we independently verify AI-generated work?
- What evidence establishes what was tested and approved?
- Who has authority to advance the engineering lifecycle?
- How do we prevent technical capability from becoming implicit operational authority?
- How can these controls remain consistent as AI models and providers change?
The Engineering System is my response to those questions.
It provides a structured engineering environment in which AI can accelerate delivery while architecture, evidence, deterministic controls, and accountable human authority remain explicit.
The Governing Principles
Architecture Before Implementation
The ability to generate code is not authorization to implement it.
Engineering begins by establishing architectural intent: purpose, scope, exclusions, invariants, interfaces, dependency boundaries, acceptance criteria, and quality requirements.
Implementation occurs within those approved boundaries.
This shifts AI-assisted development away from “generate something that works” toward “implement the approved architecture and demonstrate conformance.”
Evidence Before Authority
A successful technical result does not automatically authorize the next action.
The Engineering System requires evidence appropriate to the lifecycle decision being made.
Implementation evidence supports implementation review. Test evidence supports verification. Certification evidence supports certification.
None independently grants authority assigned to another lifecycle stage.
This creates an explicit chain between:
Intent → Implementation → Verification → Evidence → Authority
Capability Is Not Authority
One of the most important principles emerging from the work is the separation of capability from authority.
An AI agent may be technically capable of modifying code, changing architecture, moving information, deleting data, advancing workflow, or performing another consequential action.
That capability does not mean the agent is authorized to do so.
The Engineering System establishes bounded authority so that AI can operate extensively within an approved responsibility without silently expanding its own scope.
Deterministic Controls Around Probabilistic AI
Generative AI is inherently probabilistic.
Enterprise engineering cannot depend exclusively upon an AI system’s assertion that its own work is correct.
Wherever practical, the Engineering System surrounds AI reasoning with independently reproducible controls, including:
Automated Testing | Static Analysis | Schema Validation | Deterministic Identity | Repository Verification | Immutable Contracts | Lineage | Quality Gates | Retained Evidence
The operating model is straightforward:
AI provides reasoning and acceleration.
Deterministic systems provide verification.
Humans retain accountable authority.
Negative Authority
Enterprise governance requires systems to understand not only what a result permits, but also what it does not permit.
The Engineering System explicitly preserves those boundaries.
For example:
Analysis ≠ Implementation Authority
Passing Tests ≠ Certification
Validation ≠ Acceptance
Acceptance ≠ Migration Authority
Migration ≠ Cleanup Authority
Duplicate Detection ≠ Permission to Delete
This concept of negative authority prevents successful completion of one responsibility from silently granting authority belonging to another.
That becomes increasingly important as AI systems become more capable of independently completing complex sequences of work.
Human Accountability
Human-in-the-loop cannot simply mean placing an approval button at the end of an otherwise autonomous process.
The Engineering System identifies where accountable human authority is actually required.
Automated evaluation, successful execution, or passing tests cannot substitute for a required human decision.
AI can provide analysis and evidence to inform that decision.
It does not inherit the authority to make the decision merely because it produced the underlying work.
An AI-Neutral Engineering Standard
Govern the Work, Not the Model
The Engineering System is intentionally independent of any single AI model or coding-agent provider.
I currently use AI coding agents extensively as engineering collaborators. But the governing architecture does not reside inside the agent.
It resides in the Engineering System through:
- architecture;
- lifecycle standards;
- schemas;
- repository controls;
- evidence requirements;
- quality gates;
- authority boundaries; and
- human decisions.
This distinction is important.
AI technology will continue to change rapidly. An enterprise engineering operating model should not have to be reinvented every time the preferred model or agent changes.
The agent performs authorized work.
The Engineering System governs the work.
From Methodology to Working Software
POE Backup Orchestrator — The Proof
A methodology becomes much more meaningful when it has to survive contact with substantive engineering work.
The POE Backup Orchestrator serves as the principal proving ground for the Engineering System.
POE began as a solution for governed information backup and preservation and evolved into a broader system addressing preservation, validation, restoration, storage management, classification, lineage, evidence, and controlled lifecycle transitions.
Its governing preservation principle is intentionally conservative:
“We do not restructure the only copy of anything.”
POE has provided a practical environment for exercising Engineering System principles against real architectural complexity, including:
- architecture-governed implementation;
- immutable domain contracts;
- deterministic identities;
- predecessor lineage;
- evidence generation;
- classification;
- explicit failure handling;
- fail-closed behavior;
- automated regression testing;
- human authorization;
- lifecycle certification; and
- retained engineering evidence.
The result is important for two reasons.
POE is a substantial software implementation in its own right.
More importantly for my current work, POE demonstrates that the Engineering System can govern substantial AI-assisted engineering rather than existing only as a theoretical methodology.
Evidence in Practice
Engineering Quality Must Be Demonstrable
I treat evidence as an engineering capability rather than administrative documentation.
A documented POE certification milestone completed on August 3, 2026 recorded: 1,075
Passing full-repository automated tests
along with:
186 combined Phase 6C-1 through 6C-3 tests
77 focused Phase 6C-3 tests
The certification also included formatting and static-analysis validation, repository-state checks, Git diff validation, implementation identity verification, and repository synchronization verification.
The milestone verified behaviors including deterministic construction, stable semantic identities, immutable result boundaries, predecessor lineage, policy-rule binding, fail-closed behavior, nonmutation, idempotence, and preservation of predecessor contracts.
The number of tests is not the central accomplishment.
The important point is that architecture conformance, implementation identity, verification, and evidence are designed into the engineering lifecycle rather than treated as assumptions after development is complete.
Evidence as Architecture
Traditional Systems Record Logs
For consequential AI-assisted engineering, I believe the enterprise should be able to establish considerably more.
Depending upon the lifecycle decision, the Engineering System can establish evidence concerning:
What was requested?
Which architecture governed the work?
What implementation was authorized?
What changed?
What was tested?
What exact artifact was tested?
What evidence supports the result?
What authority existed?
What authority did not exist?
What decision was made?
Who retained accountability for that decision?
This creates a reconstructable engineering lifecycle.
The objective is not merely to know what software exists.
It is to be able to understand how it came to exist, what evidence supports it, and under what authority it progressed.
From Product to Platform
Phronesis — The Scale
The Engineering System and POE have also informed a broader architectural direction: the Phronesis Intelligence Operational Platform.
Phronesis explores how enterprise information can progressively become actionable intelligence:
INFORMATION → KNOWLEDGE → UNDERSTANDING → ACTION
The emerging architecture considers capabilities such as:
- information preservation;
- repository intelligence;
- enterprise knowledge;
- provenance and evidence;
- semantic retrieval;
- AI reasoning;
- intelligence orchestration;
- governed automation;
- operational intelligence; and
- shared platform services.
Phronesis is an evolving platform architecture, not a claim of a completed production platform.
Its significance to the current work is different.
It demonstrates the scale at which the Engineering System methodology is intended to operate.
A multi-product AI-enabled platform requires more than good individual implementations. It requires a repeatable engineering standard capable of maintaining architecture, governance, evidence, and quality as the system grows.
The Engineering System provides that foundation.
Standard → Proof → Scale
How the Work Fits Together
THE STANDARD – Engineering System
Defines how human and AI contributors participate in governed enterprise software engineering.
Architecture | Authority | Verification | Evidence | Governance
THE PROOF – POE Backup Orchestrator
Provides a substantive product environment in which the Engineering System is exercised, tested, refined, and demonstrated.
Implementation | Testing | Certification | Lineage | Evidence
THE SCALE – Phronesis
Extends the underlying engineering principles toward an integrated operational-intelligence platform.
Information | Knowledge | Intelligence | Automation | Action
These are not three unrelated projects.
They represent three layers of the same development program.
Why This Matters for Enterprise AI
AI Adoption Is an Operating-Model Challenge
Access to powerful AI models is becoming increasingly easy.
Operationalizing them inside a complex enterprise is not.
Organizations must determine:
- what AI can access;
- what AI can change;
- where authoritative information resides;
- how implementation scope is controlled;
- how AI output is independently verified;
- where human authority is mandatory;
- how evidence is retained;
- how decisions are reconstructed;
- how failures are contained;
- how architecture is protected;
- how governance scales with increasing AI capability; and
- how greater development velocity translates into sustainable business value.
These are not primarily prompt-engineering questions.
They are enterprise transformation, architecture, governance, engineering, and operating-model questions.
That intersection is where my current work is focused.
Why I Am Building It
My career has repeatedly placed me at the intersection of business operations, technology, governance, automation, information, and execution.
The tools have changed considerably over that time.
The underlying challenge has not.
Organizations need to understand complex systems, recognize problems and opportunities, establish appropriate controls, and convert technology into measurable operational improvement.
Artificial intelligence introduces extraordinary new capabilities into that equation.
My objective is to understand those capabilities at the implementation level while applying the enterprise discipline required to operationalize them responsibly.
That is why I chose to build rather than simply study.
The Engineering System allows me to explore a question I believe will become increasingly important to large organizations:
How do we obtain the leverage of AI while raising—not lowering—the standard of engineering discipline?
Current Development Direction
Development continues across several related areas:
Engineering System
Expanding reusable lifecycle governance and governed AI execution capabilities.
Governed Agentic AI
Exploring bounded responsibilities, agent neutrality, explicit authority, and human-controlled lifecycle orchestration.
Enterprise Knowledge Architecture
Developing approaches to semantic retrieval, RAG, provenance, lineage, and trusted AI access to enterprise information.
Phronesis Platform Architecture
Continuing decomposition of operational-intelligence capabilities into coherent products and shared services.
Evidence & Operational Intelligence
Exploring how retained lifecycle and operational evidence can become a source of enterprise understanding rather than merely a historical record.
The work remains active, iterative, and evidence driven.
Professional Direction
From Enterprise Transformation to Enterprise AI Transformation
I am applying this work toward the next phase of my career: helping complex organizations move from AI experimentation toward governed enterprise capability.
My focus is not limited to the technology itself.
It includes the organizational questions required to make the technology useful:
Where should AI be applied?
What problem are we actually solving?
How should the capability integrate with existing operations?
What governance is appropriate?
Where must humans retain authority?
How will success be measured?
How do we move from demonstration to sustainable enterprise adoption?
The Engineering System is one concrete expression of that approach.
It combines hands-on AI engineering with the enterprise transformation discipline that has defined my career.
The Principle Behind the Work
The broader Phronesis vision is:
INFORMATION → KNOWLEDGE → UNDERSTANDING → ACTION
But before an enterprise can trust systems that make that progression possible, it must be able to trust how those systems are built.
That is the problem the Engineering System is designed to address.
Architecture before implementation.
Evidence before authority.
Deterministic verification around probabilistic AI.
Human accountability where judgment matters.
The objective is not simply to develop faster with AI.
It is to develop better because of it.