Arguments from inside the workflow.

01 · Evidence is part of the system

I want a reviewer to be able to reconstruct an answer. That expectation changes what I build: the source path has to be part of the system, not a log kept for an incident.

It is tempting to treat provenance as an internal debugging feature. The model produces a conclusion, the UI presents a confidence score and a log is kept somewhere for the rare incident. That reverses the priorities. In a high-consequence workflow, the source path is part of the output. A reviewer needs to know which drawing, schedule row, model element or field observation supports the statement, what was in scope and what the system could not establish.

My decision is to keep the relations explicit. A requirement scopes a population. A source informs a room or element. A schedule supplies a value. A predicate evaluates it. A counterexample drives the finding. The graph gives me a path to correct when a summary would conceal the missing step.

The second half is authority. Language models are useful for broad retrieval, interpretation and candidate paths through an unfamiliar project. They are a poor place to hide a final “met” or “not met” decision. That determination should come from a fixed rule over an explicit population, with human review where the contract or consequence requires it.

The practical test is simple: if the system cannot answer “what did you check, against which elements, using which source, and what should I inspect next?” then it has produced an answer, not an engineering decision surface. The requirements validation workflow is a small synthetic version of that test.

02 · Forward deployed is a feedback architecture

My first forward-deployed loop did not involve AI. It involved photovoltaic systems. Find a customer, enter the environment, understand the electrical load and available space, design the system, model the economics, make the technical case, support installation and observe what happened. Discovery, engineering, selling and deployment were not separate departments; they were one responsibility.

The technology changed, but the value of the loop did not. Proximity to the customer matters because it changes what the technical owner can see: the mismatch between a written requirement and the working convention, the exception that appears only in one project, the handoff where a correct recommendation becomes unusable and the host version that quietly determines whether deployment is possible.

That exposure changes what a system means. A request for a chatbot may conceal a need for source normalization, population logic, review state and a report that fits an existing sign-off process. A request for automation may actually be a request to make a decision reproducible. The engineer who only receives the ticket sees features; the engineer inside the workflow sees the system boundary.

The pattern I carry forward is to let the work change the architecture. A failed UAT case can expose a missing entity; installation can expose a host boundary; field feedback can expose the wrong success measure. I keep those questions in the same loop because a correct recommendation can still be unusable.

A recommendation can be correct and still fail to change the work. A production system has to survive the host lifecycle, the data conventions, the release path, the people who review it and the messy state of the project under deadline. That is why I use Forward Deployed AI Engineering as an operating model, not a synonym for customer-facing development.

The AI for Engineering Field Guide formalizes the pattern; the engineering software example shows what it looks like when the loop reaches a Revit-integrated system.

03 · Five Revit failures that change the architecture

I use a successful command as the starting point for a harder question: will this survive a different host version, a changing document and installation on somebody else’s machine? These are the failure modes that change what I choose to build.

1. Treating the host like a database

Revit owns the document lifecycle, transaction boundary, external event queue and threading rules. Code that queries or mutates the model from the wrong context may work in a demo and fail intermittently in the field. The adapter is not ceremony; it is the seam that keeps host state explicit.

2. Letting version differences leak everywhere

Firms do not upgrade in lockstep, and a project can span multiple releases. If version-specific API changes leak into business logic, every feature becomes a compatibility fork. A stable internal interface and thin version adapters keep the model of the workflow coherent while the host seam changes.

3. Testing only the happy model

Real models contain deleted elements, missing levels, unloaded links, unconnected fixtures, stale parameters and partial work. QA needs model-health checks and fixtures that represent those states. “It worked yesterday” is not a test result.

4. Overwriting evaluation history

A live dashboard is not enough when a determination must be explained later. Each run should preserve the model state, population, predicate, evidence and outcome that produced it. Immutable evaluation runs turn “why did this pass before?” into a question with a trace.

5. Treating installation as a release detail

The installer, upgrade path, add-in manifest and orphaned DLL behavior are part of the system. A perfect command that cannot install cleanly across host versions is not a production capability. Release validation has to include the machine and lifecycle that will actually run the software.

The full implementation notes, lifecycle visual and adapter checklist live on Revit API engineering. The point is broader than Revit: stateful engineering hosts expose the architecture that a stateless prototype can hide.

04 · A field note should expose a decision

I keep a field note when an observation changes a decision. I record what I expected, what failed or changed, the implementation decision and the pattern I would try again. Without that sequence, I am restating the method rather than explaining what taught it to me.

New notes will extend these chapters only when they add a distinct claim. The Field Guide owns the operating model; the Work page owns the system evidence; the Revit reference owns the host constraints; a field note records the observation and decision that made one part of that architecture concrete.