Baseline
Process, volume, period and measurements available before the change.
Scoping · evaluation · operation
A useful system should remain understandable when it fails.
This method applies to automations, integrations and AI capabilities: define the decision, reduce risk, measure actual behaviour and prepare operations before production deployment.
1. Scope the outcome and risk
Scoping describes the current process, trigger, inputs, expected decision, output, owner and the cases in which the system must stop. A success criterion is observable: removing a defined manual step, detecting a known incident or producing a draft that satisfies a review rubric.
The level of control depends on the potential harm. A reversible internal suggestion does not require the same safeguards as an external, financial, sensitive or difficult-to-reverse action.
2. Design the architecture and data
- Limit permissions and data to the actual need.
- Identify source systems and which source is authoritative.
- Plan for idempotency, duplicates, delays and interruptions.
- Keep appropriate traces without exposing secrets or unnecessary data.
- Define manual recovery and a fallback strategy for every critical dependency.
Credentials and keys remain in a secrets manager or controlled environment configuration, never in a public page or repository.
3. Evaluate before automating
An AI capability is evaluated on examples representative of the use case, including ambiguous inputs and expected refusals. The rubric covers useful business accuracy, completeness, format, dangerous errors, cost and latency. The model is not its own source of truth.
A threshold defines what may be automated, what requires human approval and what must be blocked. If no acceptable output is available, the system fails explicitly instead of inventing a fallback answer.
4. Deploy, observe and hand over
Production deployment includes tests for critical journeys, permission validation, actionable alerts and a rollback procedure. Monitoring separates technical availability, output quality and business outcome. An integration may return HTTP 200 while producing incorrect data: both layers need controls.
The delivered documentation identifies dependencies, access, limitations, alerts, recovery and the person responsible for decisions during an incident.
5. Evidence standard
Intervention
Components actually delivered, environment and responsibilities.
Verification
Reproducible tests, acceptance criteria and public status where possible.
Outcome
Dated measurement, calculation definition and a distinction between correlation and causation.
Confidentiality
Names, data or quotations published only with permission.
Limitations
Known failures, dependencies, biases, missing data and the next review.
Without a publishable measurement or permission, I describe the architecture and method, not an assumed client outcome.
Start with the right context
A useful first conversation includes the process, tools, data, approving people and the main risk to avoid. For a correction to this method or an engagement request, email contact@victorlaybats.com.