AI can take you further, faster. The real skill is knowing when to let it work, when to question it, and when to take back control.
State helps teams keep a reliable, up-to-date picture of what’s true in a project. It turns scattered evidence into proposed updates and open questions, while keeping a clear history of what changed. AI helps interpret new information, software enforces the rules, and people decide what actually becomes Current State.
I found a real governance and workflow gap, but the firms with the greatest need may be difficult to serve profitably one at a time. I’d validate the opportunity with customer discovery before proposing an offering.
I use AI where it creates real value, and I raise the evidence bar as its autonomy and consequences grow. Human involvement should be intentional: not automatic, and not automatically eliminated. Technically strong AI can still fail if it creates hidden work or overlooks the people whose work is changing.
This is a coverage map, not a course. I use it to see where I’m strong, where I’m thin, and what deserves deeper study as projects raise new questions.
Start with Durable AI Knowledge for the principles I expect to keep using, or AI Professional Edge for the changing landscape, techniques, and vocabulary I’m actively tracking.
Understand the business → identify the opportunity → design it → make it trustworthy → get it adopted → prove value → improve it.
Technical AI knowledge is one part of the map. The rest is the judgment needed to turn it into useful, trustworthy work.
The goal is to get enough evidence about the current workflow and its constraints to know whether a worthwhile problem exists. I should be able to explain what happens today, where it breaks down, who feels the pain, and what baseline I would use to judge improvement.
A real problem does not automatically justify an AI feature. I want to compare plausible interventions, make the tradeoffs explicit, and be willing to recommend a simpler approach or no build at all when the evidence points there. How much to automate is a product decision, not the default goal. I want to tell a genuine workflow improvement from automation for its own sake.
I do not need an engineering curriculum, but I do need a working mental model of what the model sees, how information and tools reach it, where state lives, and what software enforces around it. That lets me separate model behavior from surrounding system behavior and have better conversations with engineers.
I want to define good behavior before launch, test representative and high-risk cases, and diagnose failures at the right layer. Reliability also means knowing what happens when the model, retrieval, or tools are wrong or unavailable.
For consequential work, authority should be visible: the model can interpret, software can enforce, and people can authorize. The system should make that boundary clear before something goes wrong and leave a path to inspect, challenge, and recover from decisions. The more consequential the decision, and the less human oversight remains, the higher the evidence bar should be.
I want users to know what the AI is doing, what they still own, and what to do when the output is uncertain or wrong. Good AI UX should reduce cognitive load and make correction, approval, and recovery easier instead of hiding uncertainty behind a polished answer. Oversight has to be meaningful, not ceremonial: people need enough context, time, and authority to challenge the AI’s output. That means designing roles deliberately and watching for hidden work that automation quietly pushes onto people.
A working prototype does not create value if it does not fit the workflow or if people do not trust, understand, or own it. I want to diagnose adoption problems as product and operating signals, not assume more training is always the fix. Adoption is also role change. I want to understand what changes for the people doing the work, take their concerns seriously, and surface recurring ones to leadership, while staffing decisions stay with the employer.
I want to define meaningful product outcomes, make sure the right data is captured, and use product analytics and experiments to understand what users are actually doing. I also want to use AI to accelerate analysis while being able to verify the data, queries, and conclusions. For AI products, that means connecting model and eval performance to normal product and business outcomes.
Client work starts with understanding the business problem, not selling a predetermined AI answer. I want to explain technical tradeoffs in plain language, surface missing evidence, manage expectations, and guide decisions without pretending uncertainty has disappeared.
Evaluation as a client capability. I want to turn eval evidence into launch and scale recommendations, and help a client keep a quality loop running after launch: production failures become new eval cases, which feed regression testing and updated thresholds and decisions.
The landscape matters when it changes what is feasible, reliable, economical, or easy to adopt. I want enough awareness of major shifts to update recommendations, while keeping the rest of the Library organized around durable product work.
A reference for where businesses are applying AI beyond chatbots, and the recurring product patterns underneath those use cases.
I come back here to spot thin areas and choose what deserves deeper study next. Exercises stay in a separate learning plan so this page can stay a map rather than a curriculum.
I use AI for exploration, building, and review, but separate those phases and check outputs against evidence. Product judgment and consequential decisions stay mine.
The work here is less about collecting AI technologies and more about making decisions with imperfect evidence: what to build, what to constrain, and when to change course.
A project-context experiment about maintaining a reliable current understanding by combining AI interpretation, software-enforced rules, and human control.
I investigated a documented governance and workflow gap and found that the firms with the clearest structural need may be the least attractive clients to pursue one at a time. My recommendation: do not propose an offering until direct customer discovery changes that commercial picture.
A simulated support pilot where discovery changed the design and weak evidence changed my first measurement recommendation.
Validation & debuggingHow I combined hands-on QA with AI-assisted automated coverage to locate the failure before choosing a fix.
Agent tracing & authorityTracing showed the agent found the right evidence but overstated what it established, so I fixed the authority rule rather than changing retrieval.
AI eval designHow I turned State’s highest-risk behaviors into practical eval cases, then used the results to decide what needed fixing.
Architecture & costI revisited the architecture and cost assumptions I made before integrating AI into State and compared them with what the working State prototype taught me about where AI added value and where deterministic software was the better choice.