Bring us the calls you cannot account for.
One traffic path to start. We will look at how your agents and applications reach models today, what one boundary would change, and what the record would let a reviewer follow afterwards. iTmethods operates the boundary inside your environment, to your change control.
The first engagement is a design partnership rather than a handover. Scope, measures and the escalation path are written down together before anything carries traffic.
One traffic path, and the person who owns the policy.
Not the whole estate. One path that already carries model calls, and the constraints that would have to hold around it.
Starting narrow is not caution, it is how the policy gets written by people who have seen what it has to allow. A boundary designed against every path at once is designed against none of them.
This is the most common shape and the easiest to scope, because the gap is already known to somebody.
AskWho would have to answer if a regulator asked what an agent did last quarter?
The boundary is useful whoever built the agent, and one set of rules covers all of them.
AskHow many different ways does model traffic leave your environment today?
Bring the document. The gap between what it says and what the boundary can hold is the whole first conversation.
AskWhich rule would you most want enforced rather than asserted?
What has to be true before we start.
Four conditions, and the fourth is the one most often missing. If an item cannot be met, we would rather find out now than design around a gap.
One traffic path we can start with
An application or an agent that already reaches a model, and that somebody would notice if it stopped. Real traffic, not a test harness.
Your identity provider, key service and storage target
The boundary wires into what you already run. We do not ask you to adopt ours, and the storage the records land in stays in your account.
Someone who owns the policy
One person who can say what may be sent, what may not, and who decides when that changes. The policy is written with them, not handed to them.
A change-control path we run inside
iTmethods operates the boundary inside your environment, which only works if we are told how change is approved there. That path is agreed before anything carries traffic.
A boundary standing on one path, and the record it produces.
Two things at the end, and a decision about whether the second one is worth widening.
What exists that did not before
A policy that is enforced rather than written down. Agreed with the person who owns it, applied at the point the call is made.
A record a reviewer can follow. For each call: the identity that made it, the policy that applied, the decision taken, the model that answered, and the time it happened.
A written view of what widening would take. Which paths would come next, what each would need, and which ones we would leave alone.
Where it stops
Coverage is what you point at it. Calls that do not take the path are outside the record, and the record says so rather than implying completeness.
This operating model is new to the category. That is the reason the first engagement is designed as a partnership: the scope, the measures and the escalation path are written down together, not inherited from somewhere they have already been proven.
Attestation status is released on request under non-disclosure rather than asserted on a page.
Start with one path.
Tell us which application or agent reaches a model, who owns the policy behind it, and what you would want a reviewer to be able to follow afterwards.