Diagnostic of an agent’s controls

Launch hypothesis. Proposal of 20 October 2026. The format and the effort below are to be confirmed in each quote. They still have to be tested on the first missions. This page is not a certification, and it is not an authorization to go into production.

For one consequential agent-driven flow: the REG Execution Boundary Diagnostic focuses on duplicates, interruptions, UNKNOWN outcomes and reconciliation. This is distinct from the general document-based review below; scope, schedule and fees are determined in a written quotation.

One question, its records, a next step to decide

For example, an agent dispatched a request and confirmation is missing. Before trying again, you want to know what is established, what remains unknown and who can check what happens next. This is an illustrative situation.

You bring one action, a question and the rules, documents or traces available. We examine together what authorizes the action, what was dispatched and what actually confirms the outcome.

You receive a sourced sheet, short annexes and up to three priorities. Each priority proposes a control to check, an owner to confirm and an observable criterion. Missing information stays explicit.

The decision being prepared. Do the available elements suffice to continue the project, is further information required, or should a targeted trial be prepared? Every operational decision stays with the client’s competent owner.

First, see a simulated sheet Describe a situation →

The first link opens a written example; the second helps prepare a message to review before sending. Scope and fees are agreed before an engagement begins.

Who it is for, and when

The sponsor is the person who carries the action: technical leadership, an AI lead, an architect, or an operations owner. The business owner and someone who can explain the technical path take part in the examination.

The same offer covers two situations, chosen at scoping.

Situation	Starting question	Material examined
Before going into service, or before a change	Have we defined the controls and the resume conditions for this action?	Design, rules, and expected behavior. Scenarios stay hypotheses until they are tested.
After an incident, or an ambiguous response	What can we establish before deciding what comes next?	One agreed occurrence, its chronology, and the traces that can be reached, even when partial.

Examples of actions: create a supplier order, change an access right, publish a record, or transmit a payment instruction. These examples describe possible uses. They are not client references.

The starting scope

The proposed scope is one process, one action type, one destination system, one reference environment, and one central question. For an incident review, it covers one occurrence, or one incident file, agreed in writing.

The work is done from documents, exports, and interviews. It includes scoping, analysis, a workshop, a restitution, and one cycle of factual correction. It does not ask for access that can trigger an action in production.

Code changes, instrumentation, tests inside the client’s system, and deployment of a resume mechanism belong to a further scope. The diagnostic may specify the trials to run. Running them has to be agreed explicitly.

Expected inputs

Input	Minimal example	If it is missing
Action and consequence to preserve	Create a single order per approved request	Scoping begins by choosing that action.
Rules and responsibilities	Who authorizes, amount or volume limit, stop conditions	A declared rule stays a hypothesis to be confirmed.
Technical path	Agent, tool, destination service, the point where the effect becomes committed	The map is rebuilt with the team and marked as declarative.
Identity and chronology	Request identifier, call identifier, sequence of events	The limits of matching are recorded.
Available traces, for an incident	Decision, request, response, log, acknowledgement, or destination state	The conclusion may be “not established”, and lead to a collection plan.
Known resume procedure	Retry, cancellation, reconciliation, human intervention	The diagnostic states the design decisions that are required.
Counterparts and the decision expected	Business owner, technical owner, the decision to prepare	The proposal names the participants required before the start.

Documents may be stripped of secrets and of data that does not serve the question. How material is transmitted, accessed, kept, and deleted is agreed at scoping.

The proposed course

A 30-minute scoping. Choose the action, the question, the sources that can be reached, and the acceptance criteria. The written scope is what allows a decision to start.
Documentary preparation. Inventory the sources, note the contradictions, and prepare the control grid.
A 90-minute workshop. Reconstruct authorization, dispatch, result, and the resource committed. Examine the ordinary course and the relevant exceptions.
Analysis and writing. Produce the sheet, the references, and at most three priority actions inside the agreed scope.
A 45-minute restitution. Reread the facts, make the disagreements precise, confirm the owners, and decide what follows. One cycle of factual correction is included.

An initial envelope of two to three provider working days, spread over a week after the agreed material arrives, may be used to price the first quotes. This format still has to be tested on the first missions. It is not a contractual delay already guaranteed.

What is examined

When a file names PASS, FLAG, HOLD, or HARD_VETO, those are execution verdicts. They stay a field apart from the postures NORMAL, CAUTION, and HOLDING-FIRST. In the TENIR frame, the membrane is the line that decides. The diagnostic does not replace it: it prepares a human decision, inside a written scope.

Question	What the examination looks for
Authorization	The applicable rule, the authority, the limits, and the observation required before dispatch.
Identity of the action	The link between request, attempt, call, and expected effect. Behavior on a replay.
Result	The difference between authorization, recorded call, received response, and confirmed effect.
Committed resource	Amount or quota consumed, reserved, and available. The update rule.
Exceptions	Refusal, missing or stale observation, unknown response, concurrent request, and interruption, as the case requires.
Resume	The information that has authority, the owner of the decision, and the condition required before another attempt.

Each point receives a status: documented, declared by the team, shown by an identified trial, or not established. A trial of the TENIR/REG demonstrator does not show the behavior of the client’s system.

Deliverables

A one-page synthesis sheet: action, question, scope, main findings, unknowns, conclusion, and the next control.

Short working annexes: a map of the action, a register of sources, and a grid of the controls examined. A trace is referenced by file, identifier, sequence, or a usable path. A declaration is attributed to the person who made it.

A follow-up plan limited to three priorities: the problem addressed, the control proposed, the evidence expected, a responsibility proposed and then confirmed by the client, and a closing condition. If the elements already suffice, the file may conclude that no further work is required inside the scope studied.

The demonstrator may be used as a teaching support during the workshop. What is delivered is the analysis of the client’s case, and the decision that analysis makes it possible to prepare. The filled example — local simulation, unknown outcome shows the expected form. It is not a client reference.

Acceptance criteria

Criterion	Check at restitution
Explicit scope	The action, the system, the environment, and the question are named. The limits are visible.
Traceable findings	Each important finding points to a source that can be found again, to an attributed declaration, or to an explicit gap.
States correctly distinguished	Authorization, dispatch, result, and committed resource are presented separately.
Uncertainty kept	Each missing piece of information states what it prevents concluding, and, where possible, how to obtain it.
A usable follow-up	Each priority action has an objective, a responsibility identified or still to confirm, and an observable criterion.
Review closed	Factual corrections are integrated. Disagreements that stay open are recorded.

A conclusion of “not established with the elements available” is acceptable when it explains the gap and its consequences. Acceptance does not require finding a failure, resolving the incident, or buying software. It is not a certification, and it is not a general authorization to go into production.

The commercial model

A fixed fee, quoted and accepted after scoping. The price is calculated from the effort of preparation, analysis, facilitation, and writing, with the correction cycle included. The quote fixes the volume of documents, the participants, the dates, the form of the deliverables, and how acceptance works.

A second process, several environments, an extended technical reconstruction, or further trials trigger a written rescoping. A possible architecture study, or a pilot, stays a later decision.

To validate the offer, the first missions have to make it possible to observe the real effort, whether the sheet is understood, whether it is used in a decision, and the willingness to pay. No market price, time saving, or return on investment is established.

The five questions of the first exchange

Which precise action can the agent trigger, in which system, and which consequence must be preserved?
Which incident, doubt, or change motivates the request?
Which decision has to be made, and by when?
Which rules, people, and traces are available for the examination?
Who carries the decision and the budget for the diagnostic, and who will take part in the restitution?

The button opens a message to skiredj@tenirlabs.cc, already structured by these five questions. The site does not send it: your mail application opens, for you to reread.

Scope my diagnostic See the simulated example