Public data index › Agent Fleet Truth-Probe Review
Find the green checks that cannot detect their own blind spots.
For a founder, platform lead, or automation operator responsible for 20–200 recurring AI-agent or automation jobs. This is a fixed-scope, adversarial code review of the Python or Bash probes you already rely on: what each probe actually establishes, what happens when its source disappears, and whether its guards can reach both sides.
A truth probe is any script that reports operational reality: a health check, status report, nightly run summary, or gate that decides whether another action may proceed. The review treats each one as a claim-making program and asks whether the implementation can establish the sentence it emits, or can only produce the string.
The fixed offer
$457 one time
We review up to twelve accepted, sanitized Python or Bash probes and every helper needed to understand them, capped at 1,500 total lines. You receive the evidence, tests, mutation results, unapplied diffs, and remediation order within seven business days after written scope acceptance and cleared payment.
What you receive
Claim-to-source matrix
Every claim from the accepted probes is mapped to the specific source and code path that produces it. A claim with no supporting observation is marked rather than inferred.
Failure-semantics table
Each probe is exercised against unavailable, permission-denied, timeout, malformed, empty, and stale inputs. This is where a probe's own blindness can become a false success or false failure.
Rerunnable synthetic tests
At least one expected-good and one forced-failure case per accepted probe. The suite runs on your side after the engagement and is yours to keep and extend.
Mutation evidence
Existing guards are deliberately challenged to show whether each one reaches both outcomes. A guard that remains green when its target defect is introduced is recorded as vacuous.
Unapplied patch diffs
False-success, false-failure, and unknowable-state defects found during the accepted review receive proposed diffs. Nothing is applied to your source or infrastructure. Your team decides whether, when, and how to merge.
Prioritized remediation brief
Findings are ordered and the ordering is explained. The thirty-day correction window covers mistakes in the delivered review, test fixtures, or diffs. It does not cover production behavior, new code, a changed probe, or an outage.
The three verdicts
Every verdict carries the label under supplied fixtures — N of M fleet probes reviewed. The count travels with the result so a review of twelve probes cannot be restated as a conclusion about two hundred jobs.
| Verdict | Meaning | What it does not mean |
|---|---|---|
| BOUND | The implementation supports its stated claim under the authorized supplied fixtures. | It does not say the fleet is healthy, the observation is current, or the probe covers every failure. |
| UNBOUND | A tested change breaks the claim without the probe detecting it, or the probe asserts a result its observation cannot establish. | It does not predict an outage or establish that production is currently broken. |
| UNKNOWN | The relationship cannot be determined from the accepted code and authorized fixtures. | It is not a pass, a fail, a missing row, or permission to carry a prior answer forward. |
The review output is a mapped relationship between your probe's sentence and its implementation under supplied fixtures. It is not an audit opinion, certification, attestation, or statement about production health.
Scope, custody, and the pre-payment boundary
- Review surface is Python or Bash only.
- Up to twelve probes and 1,500 total lines, including imports and transitive helpers required to understand the reviewed behavior.
- Actual sanitized source and synthetic fixtures move only after written scope acceptance, through an agreed customer transfer method.
- Any subprocessor or model use is disclosed in the written scope before source transfer. Customer source is not used to train models or reused as a vendor template.
- Customer materials are deleted thirty days after final delivery.
- No production access, production execution, remote shell, credential, customer record, or new code running against buyer infrastructure is part of the service.
A short probe can call a much larger shared utility. Those helpers count: a 200-line probe plus a 400-line module needed to understand its behavior consumes 600 lines of the cap. A disconnected excerpt is not accepted as a reviewable surface.
What this review does not sell
| Activity | What it normally does | This review's boundary |
|---|---|---|
| Monitoring and alerting | Continuously observes running systems and emits signals. | Reads accepted source under supplied fixtures; no production connection or ongoing service. |
| Incident response | Acts during a live failure. | A fixed work product delivered on the stated schedule; no on-call response. |
| Penetration testing | Probes systems for exploitable weaknesses. | No system access and no security testing. |
| Compliance or legal certification | Assesses a system against a formal standard. | No certification, legal conclusion, audit opinion, or assurance. |
| Uptime warranty | Commits to availability or response. | No promise that outages will be detected or prevented. |
This is code review. Even a BOUND probe can observe a source that is stale, partial, misconfigured, or outside the reviewed fleet subset. The verdict is deliberately too small to become a production guarantee.
Owned method proof, checked 2026-08-09
US Tech Automations' own read-only system_truth.py measured 545 lines on the dated check. A normal run emitted 33 explicit probe rows: 30 OK, 3 FAIL, and 0 UNKNOWN. Its sources included actual systemd state, ports, HTTP, read-only aggregate ledger observations, self-versus-external traffic, stale workflow state, a page-quality gate, and governance dates.
A separate global negative control forced every source unavailable. It emitted zero OK and zero FAIL rows, did not replace the durable report, and exited successfully. That demonstrates one implemented failure-semantics method: when the instrument cannot observe, it refuses to manufacture a system verdict.
Primary reference sources
- Google SRE: Monitoring Distributed Systems distinguishes signal meaning and white-box from black-box observation. This review applies that care to probe source; it is not a Google service.
- OpenTelemetry semantic conventions provide a shared vocabulary for correlatable telemetry. This service does not certify conformance to those conventions.
- OpenTelemetry GenAI attribute registry warns that tool arguments and results may contain sensitive information. That is why production output and tool payloads are outside the intake.
How the scope check works
- Describe the surface without sending it. Give the language, probe count, total lines including helpers, runtime, and a plain objective. Do not paste or link source, output, endpoints, logs, traces, or configurations.
- We accept or decline fit before payment. The written response fixes which probes and helpers count, what can be sanitized without losing behavior, the authorized fixture boundary, price, delivery clock, retention, model/subprocessor disclosure, and exclusions.
- Source transfer follows accepted scope. Sanitized code and synthetic fixtures use the agreed customer transfer method. No public form or production access is repurposed as a file channel.
- You receive evidence you can rerun. Tests, mutation results, tables, unapplied diffs, and the remediation order arrive together. Your team owns application.