# M2M API Playbook

This playbook describes the preferred B2B machine-to-machine contour for AI Agent Blind-Spot Review.

Strategic contour decision lives in `./strategy-decision.json`: M2M API is the commercial core, Proof Library is demand generation and calibration, and the Compliant Adapter Layer is route maintenance only.

## Core Decision

Do not model the system as a fully autonomous factory that discovers messy humans, sells to them, collects money, and reinvests without external gates.

Model it as three linked contours:

- B2B M2M API for structured agent platforms and orchestration systems.
- Assistant-filter workflow for messy human artifacts, with human verification before paid delivery when scope is high.
- Public proof loop for anonymized teardown examples and backtest calibration.
- Compliant adapter layer for official API, documentation, schema, and route freshness maintenance.

## Why M2M First

M2M input is cleaner because partner systems can submit:

- workflows;
- traces;
- role setups;
- route artifacts;
- event logs;
- execution constraints;
- acceptance criteria.

This reduces the risk that the service becomes a generic downgrade generator for vague human prompts.

## Autonomy Boundary

The assistant-filter contour is the intended autonomy model: agents reduce operator load, but they do not remove external-state gates.

Agents may:

- discover public candidates;
- prefill typed intake fields;
- classify routing signals;
- draft failure maps;
- prepare quotes and delivery drafts;
- aggregate anonymized blind-spot statistics.

Agents may not:

- create bank accounts;
- pass KYC;
- file taxes;
- act as legal, financial, or security authority;
- deliver EUR 250+ outputs without human verification;
- claim guaranteed outcomes.

## Review Mode By Tier

- EUR 99 Agent Output Red-Team: agent draft with spot-check unless risk flags trigger human verification.
- EUR 250 Corrected Action Plan: agent draft, human verified before delivery.
- EUR 500+ Agentic SLAM Audit: human verified architecture audit.

## M2M Flow

1. Partner system reads `./health.json`.
2. Partner system reads `./api-contract.json`.
3. Partner system reads `./autonomy-resilience-policy.json`.
4. Partner system validates payload against `./intake-validator.json`.
5. Partner system submits structured artifact.
6. Blind-Spot Review returns accepted, partial_review, rejected, or queued.
7. Draft failure map is generated.
8. Sentinel review is triggered when moving-gate, semantic-dissipation, liability, tier, or risk signals require it.
9. Partner system receives verdict, failure map, next allowed action, and do-not-do list.

## Public Proof Loop

During `backtest_open`, public or anonymized candidates should be used to expand the proof library and calibration corpus. Overflow candidates can be aggregated into recurring blind-spot statistics without naming the source.

During `api_backtest_open`, partner systems should submit controlled typed JSON requests to the local M2M API gate only. The response validates routing, failure-map generation, and human-verification flags; it does not imply paid production availability or automatic billing.

## Failure Mode To Avoid

If the system tries to close discovery, persuasion, intake, payment, delivery, and reinvestment as a single autonomous loop, it creates false autonomy. The correct design is to automate preparation and routing while keeping external-state gates explicit.

The three hard stop classes are moving gate problem, semantic dissipation, and liability void. See `./autonomy-resilience-policy.json`.

## Compliant Adapter Layer

The adapter layer may update connectors only through official APIs, documentation, changelogs, schema observations, and permitted integrations.

It may not bypass captchas, anti-fraud systems, rate limits, account restrictions, or access controls. If those signals appear, the correct action is to mark the route blocked or stale and trigger sentinel review.