What stress-tested means at after.machines.

The 8 checks.

Every system I deliver faces these eight. The record names what was tried under each one, and when.

1. ST1Test setWe run a fixed set of labeled cases, with the right answer written down first, and compare every result.
2. ST2Prompt attackAt least one test hides instructions in the input. The workflow must ignore them or flag them.
3. ST3Run twiceSending the same input twice, or rerunning after a crash, never doubles a record, a message or a payment.
4. ST4Failure recoveryA failed call is retried a set number of times. If it still fails, the item is parked for a person. Nothing is dropped silently.
5. ST5Load and limitsWe run it at its own maximum batch size, and it has limits on input size, items per run, sending speed and AI spend.
6. ST6Failure alertIf a run fails, a named person gets an email saying which step failed.
7. ST7Human sign-offNothing reaches a customer, a candidate or a money system without a person, unless a fixed rule allows it.
8. ST8Rules around the AIFixed rules run before the AI and check its answer after. If the AI fails or is down, the workflow falls back to a safe result.

The stress-test record.

Delivered with every System Build. One row per check, dated at every run, counts only, never your data.

CheckWhat the record reports

1. ST1Test setThe number of labeled cases and how many runs in a row passed.
2. ST2Prompt attackThe number of attack cases and what happened to each one.
3. ST3Run twiceWhether the same input sent twice left one record and one side effect.
4. ST4Failure recoveryThe retry count, and where failed items are parked for a person.
5. ST5Load and limitsThe batch size tested, and the limits set on size, items, sending speed and AI spend.
6. ST6Failure alertWhether the failure email named the step that failed.
7. ST7Human sign-offWhere a person signs off, or the fixed rule that allows an exception.
8. ST8Rules around the AIThe rules that run before the AI, the checks after it, and the fallback.

What the record never shows.

The record shows what was tested, when, and what was not. These stay out of it.

• Test inputs or outputs.
• Prompt text.
• Model names.
• Screenshots of any builder.
• Execution logs.
• The values of limits or timeouts.
• Failure counts from real client runs.
• A client's identity without written permission.
• A status light without a recorded run behind it.
• Percentages or scores for any check.

When the checks run.

The free review runs nothing. It names, in one line, which checks the candidate workflow would face. The checks themselves run in the paid phases.

Phase	What happens with the 8 checks	Where it shows
Diagnostic Sprint	Each check is marked "Applies" or "Not needed", with the reason, for the chosen workflow. The acceptance rule is written down: every check that applies must pass before handover. Nothing is built, so nothing is run.	A one-page stress-test plan inside the priority action plan.
System Build	Every check that applies runs on test data before the system touches real data. The model-review date is recorded for each AI step. A failing check blocks handover.	The stress-test record: dated, one row per check, counts only. Acceptance means the written scope is met and every check that applies has passed.
Optimization Retainer	The checks that apply run again after any model or prompt change, after any third-party change that touches the workflow, and at least every 90 days. The record gets a new date each time.	The monthly health review, with the last run date per check.

A check reads Passed only with a dated recorded run behind it. The "Stress tested" mark comes off when the last run is older than 90 days, or older than the latest model or prompt change.

What a large company staffs a team for, you get as one system.

Large companies run these with whole teams. I build the same kind of system as one automation, test it against the 8 checks, and hand it to you.

Capability	How a large company staffs it	What one System Build gives you	Checks
Speed-to-lead routing with response deadlines	An SDR team and routing rules owned by RevOps	Every inbound lead scored by fixed rules, given an owner and a deadline; unclear cases pause for a person	ST1, ST7, ST8
CRM discipline after every call	Sales ops and deal reviews	Call notes become a CRM update under stage rules; closing a deal always needs a person	ST7, ST8
Support priority and escalation	A support operations team	Each ticket gets a priority, a team and a due time by rule; replies stay drafts until a person sends them	ST7, ST8
Invoice checks before anything is paid	An accounts payable team	Duplicate and math checks around one AI step; anything risky goes to a person	ST2, ST3, ST7
A weekly reporting pack	A BI or finance team	Numbers rebuilt from source each week; any AI note checked against the computed numbers	ST8
Reliability engineering	A platform team	Retries, parked failures, replay-safe runs, a failure alert, spend limits, on every system	ST3 to ST6

I'm Nitin Sarkar.

I build one automation at a time for startups, at fixed prices, and I try to break every system against the 8 checks before I hand it over. You deal with me from the first call to the handover.