Per-Engagement System Graphs: Capturing Client Topology Once for Consultancies

The core problem is not that integrators are bad at discovery. They are usually very good at it. The problem is that the output of discovery is a document, and documents decouple from reality the moment the client merges their next pull request.

Consider what a typical engagement actually produces: an architecture diagram, a Confluence page of service ownership, a spreadsheet of integrations, and a lot of context that lives only in the heads of the two or three engineers who did the work. When those engineers move to the next client, the model leaves with them. When you return to the same client six months later for phase two, you re-discover. You are paying senior rates to relearn things you already knew.

This is getting worse, not better, for a structural reason. Roughly 41% of codebases are now AI-generated, which means client systems are changing faster and in less legible ways than they did when a human wrote every line. Industry research puts the rate at which AI coding tasks introduce critical flaws or security issues near 45%. A static topology document captured at week two of an engagement is describing a system that no longer exists by week six. The faster your clients ship, the shorter the half-life of your discovery work.

The fix is to treat a client's topology as a queryable, live model rather than a static artifact. In Zof's architecture this is the System Graph: a live dependency and context map of services, dependencies, and CI/CD pipelines. The distinction matters because a graph supports two things a document never will. It can be diffed, and it can drive automation.

A graph that captures services, their dependencies, data flows, ownership, and the CI/CD paths that change them becomes the substrate for everything else you do on the engagement. Instead of validation that runs the same fixed suite regardless of what moved, you get validation that is change-aware: when the client modifies an auth service, the model already knows which downstream services and pipelines that change touches, so the work targets reality instead of a checklist.

For an integrator, the graph is also the deliverable that survives. When you build it as a structured model rather than a slide, the next engineer who joins the engagement inherits an accurate picture instead of a meeting invite. The institutional knowledge stops living in individual heads.

### What to capture in the first pass

You do not need to model everything to get value. Capture the load-bearing topology and let the model deepen as the engagement proceeds:

Capturing the topology once only pays off if it stays accurate without a human re-walking the codebase every sprint. This is where Testing Fleets earn their place. Rather than static scripts that rot as the system changes, they plan, execute, observe, and maintain validation as the implementation evolves, and that observation feeds the graph. As the client's architecture shifts during your engagement, the model updates from real behavior instead of from a quarterly re-interview.

The governing principle here is agents propose, humans authorize. The agents do the tedious, continuous work of tracking what changed and what it affected. Your engineers hold authority over what those observations mean and what action follows. Nobody is suggesting you let unsupervised automation rewrite a client's production system. That would be reckless, and no serious client would permit it. The point is narrower and more durable: the model that took two weeks to build by hand now maintains itself, under your team's supervision, so the discovery investment keeps compounding instead of decaying.

This is also where the engagement's security posture sharpens. Because the graph knows what is actually reachable, prioritization gets honest. Reachability-based prioritization can mean 70-90% less exploitable exposure, because the team triages what is genuinely reachable in the live system instead of a flat list of findings the scanner produced out of context.

Once you have modeled three or four clients as graphs, a second-order asset appears: patterns. Most B2B SaaS clients in a given vertical share a recognizable shape. A fintech client tends to have a payments path, a ledger, an identity boundary, and a reconciliation flow. A retail client tends to have a catalog, a cart, a fulfillment path, and a payments integration.

You can encode those recurring shapes as templates. Not the client's specific data, which you must keep isolated, but the topology pattern, the validation strategy that fits it, and the policies that governed previous engagements. The next time you onboard a similar client, you start from a template instead of a blank whiteboard. The first engagement pays full discovery cost. The fifth in that vertical starts at perhaps a third of it.

This is the structural advantage that turns a consultancy's experience into a compounding asset rather than a series of one-off projects. The model is the moat.

The objection a skeptical client will raise immediately: you are proposing to run agents and hold a model of our system, so where does our data go and what can your tooling touch. This has to be answered in the architecture, not in the SOW.

Edge Runners address this directly. They are signed capsules that execute inside the customer's own boundary, within a secure enclave, and produce audit-ready evidence without exfiltrating the client's source or data. The model is built and maintained where the system lives. Combined with Governance, explicit policy, approval gates, and an audit trail of what was proposed, authorized, and executed, you can give a client a defensible answer to every question their security team will ask. For multi-tenant consultancy work, that isolation is not a nice-to-have; it is the precondition for being allowed to do the work at all.

You can test this on your next engagement without changing how you sell:

If you are weighing whether to build this internally or adopt it, build vs buy lays out the tradeoffs, and how it works shows the closed loop end to end.