The Nilsoft Continuity Diagnostic
Find the control gaps.
Give engineering
a clear next move.
One workflow, examined across the agent, its tools and the people around it. You receive an evidence-linked account of what can fail, the controls it needs, and a prioritised remediation plan.
Within five business days after required access, evidence and discovery are complete.
When it earns its place
For the gap between
a working agent
and a trusted workflow.
You are moving toward production, expanding an agent’s authority, or already carrying the cost of a workflow you cannot reliably explain.
- Your team manually reconciles conflicting records or uncertain outcomes.
- Approvals can go stale between a human decision and an automated action.
- Retries, handoffs or changing state make customer actions difficult to trust.
- You have traces and evaluations, but important workflow questions remain unresolved.
We choose one coherent operational outcome. It may cross several systems; it is not an organisation-wide audit.
Open the work / sample 01
One refund agent.
Three places to lose control.
Illustrative sample — synthetic data, not a customer result.
A customer refund is approved. The order changes before the agent executes. The payment API accepts the request, but the workflow never establishes the customer’s final refund state.
- E01 / 09:41:00
Approve
A human approves a refund against order v18.
- E02 / 09:41:08
State changes
An operator changes the order to v19. No recheck is recorded.
- E03 / 09:41:12
Request accepted
202 Accepted. No idempotency reference accompanies the request. - E04 / 09:41:15
Outcome missing
A retry is scheduled. No final provider observation or receipt is recorded.
The supplied sample establishes an accepted request. It establishes neither a completed refund nor a duplicate.
The findings
Inspect the evidence, consequence and proposed correction.01Approval became staleThe decision outlived its facts.
- Sample evidence
- E01 / Approval references order version 18. E02 / An operator changes the order to version 19 before the tool call. The supplied trace contains no precondition recheck.
- Possible consequence
- The agent may act on permission that no longer covers the current order. A valid earlier approval is not enough to establish that this action is still permitted.
- Proposed correction
- Bind approval to the relevant order state. Re-read and compare that state immediately before execution; route a mismatch back to the decision owner.
- Verification condition
- Change the order after approval. Execution must stop until the changed preconditions are resolved.
02Repeated execution lacks a reliable boundaryA retry could become a second refund.
- Sample evidence
- E03 / The request has no idempotency reference. E04 / A retry is scheduled while the first refund outcome remains unknown.
- Possible consequence
- The workflow cannot establish that another attempt represents the same intended refund. An unintended duplicate is possible; this sample does not establish that one occurred.
- Proposed correction
- Assign one stable idempotency reference to the intended refund and reuse it across retries. Reconcile an uncertain attempt before initiating a new one.
- Verification condition
- Repeat the same refund intent through the supported retry path. Confirm it cannot create an additional refund.
03Accepted request is treated as completed workThe response is not the result.
- Sample evidence
- E03 / The payment API returns 202 Accepted. E04 / The trace records no provider status check or linked completion receipt.
- Possible consequence
- The team cannot establish whether the customer was refunded. Marking the task complete would conceal an unknown outcome.
- Proposed correction
- Observe the provider’s final refund state. Connect that observation and its receipt to the original request, approval and attempted action.
- Verification condition
- Exercise pending, failed and completed provider responses. Only an evidenced completed refund may be presented as complete.
Proposed design / not an observed result
Make the next attempt accountable.
- Revalidate the approved state
- Execute one bounded refund intent
- Observe the final provider state
- Link the evidence to the decision
These controls have not been implemented or tested in this illustrative case. The diagnostic defines what to change and how to check it; implementation is a separate engagement.
The findings pack
Seven outputs.
Three useful decisions.
Each material finding carries its supporting evidence, consequence and verification state. Missing evidence remains a gap to resolve.
What is happening?
- Current-state workflow map
The actors, tools, decisions and material transitions, including the workarounds your team depends on.
- Continuity and control failure register
The material gaps, their evidence, and the consequence of leaving them unresolved.
What must change?
- Authority / capability / effect map
Who owns each decision, what is permitted to act, and which effects must be observed.
- Target governed transition model
A proposed path from relevant state and resolved permission to an action and an evidenced result.
- Remediation architecture
The concrete changes needed at the most consequential control gaps.
Where do we start?
- Three prioritised next moves
Each with an intended outcome, reason for priority, boundary, dependencies and verification condition.
- One 60-minute findings session
Work through the diagnosis, proposed corrections and next engineering decision.
From first conversation to findings
A defined piece of work.
A usable handover.
Sean Manouge, Nilsoft’s founder and systems architect, owns the work. Your team supplies context and evidence; the diagnostic connects them into a decision.
- 01
Establish fit and scope.
Describe the workflow, the uncertainty and its consequence. Agree the operational outcome and engagement boundary.
- 02
Walk through the evidence.
Bring the decision owner, available traces, relevant configuration and examples. Establish what is known and what is missing.
- 03
Inspect the control gaps.
Trace state, authority, action and effect. Define the proposed architecture and the three priorities.
- 04
Review the next moves.
Receive the findings pack and a 60-minute session. Decide what your team should implement or commission next.
The diagnostic does not change customer systems. Its delivery window starts after required access, evidence and discovery are complete.
Scope, effort and terms
Know what you’re
committing to.
50% to commence and 50% on delivery of the findings pack.
Delivery within five business days after required access, evidence and discovery are complete. Unavailable evidence or stakeholders pause the window.
What access and effort do you need?
A workflow walkthrough, relevant architecture or process material, logs or receipts, configuration, known failure examples, and access to the workflow decision owner. Persistent system access is not required by default. We establish the necessary customer participation during scoping; there is no invented fixed-hour commitment.
Will you touch production or take control of our data?
The diagnostic does not mutate customer systems. Access and evidence are agreed for the selected workflow. Customer data, credentials, decisions and canonical records remain within the agreed customer relationship. Initial enquiries should contain no credentials or sensitive operational records.
We already have evaluations and observability. Is this still useful?
Existing evaluations, traces and logs are useful inputs. The diagnostic follows one operational outcome across tools and human decisions, examining state changes, permissions, retries and the evidence of the resulting effect. Fit depends on the unresolved questions in your workflow.
What happens after the findings session?
Your team has the findings, proposed architecture and three prioritised next moves. You can implement them internally or separately agree remediation or a paid pilot. Follow-on work is optional and requires a separate agreement.
What if the evidence is incomplete?
We identify the missing evidence and keep inference, uncertainty and unknowns explicit. Unavailable required evidence or stakeholders pause the delivery window; they are not a reason to manufacture a confident result.
What is outside the diagnostic?
Implementation, production deployment, ongoing support, penetration testing, legal advice, regulatory certification, compliance certification, customer policy or business-decision ownership, and an organisation-wide audit. The diagnostic does not guarantee that every risk is identified or eliminated. Tax treatment follows the Nilsoft invoice and applicable requirements.
Start with one workflow
Bring the part
you don’t yet trust.
Tell us what your agent does, where the uncertainty starts, and what is at stake. We’ll establish whether a bounded diagnostic fits.