We audit the real flow of work — the fixups, the workarounds, the manual launch/restart practices, the teams that persist because no one has incentive to remove them — and produce PRISM, a transparent and repeatable specification of the process as it actually operates and as it should be redesigned.
For CTOs, CIOs, and operations leaders evaluating AI integration in processes that matter — and who would rather know what's actually broken before any model is selected.
A workflow drawn as A → B → C → D looks clean on paper. The reality is a tangle of silent fixups, undocumented exceptions, and errors that humans quietly absorb on their way to the next step. People accommodate. AI does not — and should not.
When an organization layers AI onto a broken map, it doesn't get a smarter process. It gets the old dysfunction, now automated at machine speed and with plausible deniability.
The reason C was never removed from the flow wasn't technical. It was that C had no incentive to remove itself.
Our work begins before any model selection, tooling decision, or agent framework. We reconstruct what the process actually does, separate accommodation from requirement, and identify the redesigns that would have been obvious if the org chart hadn't been in the way.
The arc applies a single methodology — the PRISM Method. PRISM stands for Process Resource and Interaction Specification, and refers both to the artifact (the canonical specification of a process) and to the discipline that produces it (authoring, closure review, simulation, settled output). The method is what gives every engagement below its repeatability and its measurable terminus. Each engagement is a defined application of it.
The starting engagement. A ground-truth reconstruction of how data and decisions actually move through a nominated process — including the undocumented fixups, the silent error handling, and the steps whose only purpose is historical. Most engagements begin here.
Building on the audit, a candid report on which parts of the workflow are actually suitable for AI or agentic automation, which parts need redesign first, and which are load-bearing human judgment that should not be touched.
Where the practice produces work product. The target architecture — the flow that should exist — with explicit rule specifications, error contracts, and handoff definitions that AI systems can actually be equipped with.
Independent review during rollout. We watch for the predictable failure modes: teams withholding the rules AI needs to succeed, role substituting for record, scope creep dressed as governance.
You nominate one process — typically one your organization is contemplating for AI integration, or one that has resisted a previous attempt. We apply the PRISM Method to it: reconstruct what the process actually does (not what the documentation claims), surface the gap-filler dependencies and silent accommodations, identify the integration risks that would arise if AI were introduced as currently scoped, and produce a draft PRISM for the assessed process.
Existing documentation, access to the process owner and two or three operators, and a brief working session at week one.
A written report and the draft PRISM. Closing working session with the process owner and any nominated stakeholders.
Two weeks from kickoff. Fixed fee. No follow-on commitment required or implied.
We don't sell AI. We don't take vendor referral fees. Our recommendation is frequently "don't automate this yet."
We don't wait for "100% requirements." That demand is usually a protective posture, not a technical one, and we'll say so.
We don't confuse role with record. If a team's output is a meeting rather than an artifact, that's the finding.
We don't optimize for headcount growth. If a layer can be removed, we name it — including, on occasion, ours.
Over twenty-five years of senior technical leadership at Tier-1 broker-dealers, in roles spanning hands-on information architecture, principal engineering, and management of technical teams ranging from ten to ten thousand technologists. Earlier work in biotech / bioinformatics and in geospatial systems involved similar information-architecture redesigns in different problem domains, before AI was part of the conversation.
Two patents in the software solutions space — one in security, one in distributed data systems. The practice is grounded in what has actually worked, and what has predictably failed, across real systems running real money under real regulators.
I know the practical limits of what can and cannot be done, and where "change risk" is inflated as a protective measure. I know the dynamics of management hierarchies: the drive to increase headcount and budget rather than reduce them, the resistance to rapid change, the pathological demand for complete requirements, and the substitution of role for record, particularly in devops and security review.
I have a personal architectural principle I return to often: how do you turn it off? Most systems cannot answer the question. Most should be able to.
If that description sounds like it was written by someone who has lived through it, that's because it was.
Designed and developed BondStudio, a bond portfolio analytics platform still used as a standard in fixed-income analysis 25 years on. Technical innovations included a runtime dynamic schema for strongly typed data (predating BSON and CBOR by two decades), the use of HTTP as an application-layer protocol for what later came to be called web services, and a strict separation of compute grid from calculator from application — long before any of those architectural moves were standard practice.
Brought in to a stalled cloud-migration program, I found the obstacle was neither security nor performance — both of which the team was prepared to debate at length. The actual problem was that the system had no operational process to turn on or turn off. It "always ran." Each release, and especially the annual HA/DR test, was a nail-biter requiring access privileges that the cloud target environment would never have permitted. The remediation was operational and architectural before it was technical, and it took longer than anyone wanted to admit.
Designed and built a working data-lineage system that combines fully deterministic record-and-API flow tracing with AI-assisted field-name mapping and transformation inference. The hybrid approach is the operating example, in my own work, of the methodology described in the field notes: AI is used where it is genuinely useful (semantic interpretation across heterogeneous schemas), and deterministic logic is preserved where correctness is non-negotiable. The two are not mixed casually.
Used Claude Code extensively to deliver real working systems — data-lineage tooling, full React frontends, native iPhone applications, complex web API construction, and use of structured narrative as the canonical source from which performant and testable implementations are derived in multiple languages. This is not theoretical. It is the practice the third field note describes, applied to live engineering work.
Parallelized a serialized customer-onboarding process that had silently absorbed years of off-channel data dependencies — the kind of dependencies the first field note describes as gap-filler accommodations. Surfacing them turned out to be the work; once surfaced, parallelization was straightforward. End-to-end onboarding time fell from weeks to days, and in many cases faster.
Replaced a workflow system whose routing logic lived overwhelmingly in freeform comment fields — the most dangerous field in any enterprise system — with a structured, queryable, actionable model. Not a one-shot migration, but an iterative process that produced a confidence score per record and required human review until the overall quality was good enough to deal only with exceptions. A direct illustration of the closure-and-confidence loop the third field note describes.