# AM-RP-001: request and attempt accounting reference

Author: Anant Mishra. Prepared 1 November 2026. Version 0.1.0.

**Status: executable software reference with synthetic inputs. No model, assistant, network service, DGX experiment, or real workload is exercised.** This material supplements the inference protocol's failure-accounting method. It does not implement business actions, service-side idempotency, permissions, recovery, or the accompanying service-request Design study.

## Reproduce locally

Download this guide, `request_accounting.py`, `test_request_accounting.py`, and `synthetic-request-attempts.json` into the same directory. Python 3.10 or later and the standard library are sufficient:

```sh
PYTHONDONTWRITEBYTECODE=1 python3 request_accounting.py
PYTHONDONTWRITEBYTECODE=1 python3 test_request_accounting.py -v
```

The CLI prints `synthetic_accounting_only`. The tests check counting invariants and invalid-input handling. Neither command calls a model or writes run evidence. The fixture's January timestamps are invented scenario inputs, not experiment or publication dates. Expected counts are authored expectations, checked against the executable reference; they are not observed service results.

## Observation contract

Each record is one frozen client observation for one unique attempt. `logical_request_id` groups attempts arising from the same intended inference request; `attempt_id` identifies a physical attempt. Preserve both identifiers in future real run logs. Identical prompt text alone cannot establish shared intent.

The only accepted fields are those identifiers plus `started_at`, `observed_at`, `outcome`, and `observation`. Timestamps must be timezone-aware; observation cannot precede start. Outcomes are:

| Outcome | Meaning | Allowed observation |
| --- | --- | --- |
| `success_response` | The client received a protocol-level success response | `response` |
| `error_response` | The client received an explicit error response | `response` |
| `unknown` | No conclusive response was available at the observation boundary | `timeout` or `connection_lost` |

A success response does not establish semantic quality, useful output, exactly-once execution, or business-effect completion. An error response does not prove that remote work or side effects never occurred. A timeout does not prove that server computation stopped. Partial streamed responses need a separately specified completeness rule before being mapped into this contract.

The reference rejects repeated attempt IDs, even identical duplicates. Reconcile duplicate log delivery upstream with an auditable rule; do not silently inflate counts or overwrite conflicts. Late evidence belongs in a versioned observation snapshot. This small reference does not merge evolving observations, model all planned requests, capture warm-ups, or account for attempts missing from the log.

## Counting rules

Attempt counts partition all supplied records into success responses, error responses, and unknowns. Logical requests partition the distinct supplied logical IDs into: at least one success response; no success response but at least one unknown attempt; or error responses only. There is no denominator for planned requests that were never dispatched or recorded. No success percentage is calculated.

Separate flags count logical requests with any unknown attempt, multiple attempts, and multiple success responses. These flags overlap the partition. A successful sibling never erases an unknown attempt. Multiple attempts are not automatically called retries: hedged or concurrent attempts also need to remain visible. Multiple success responses do not establish duplicate business effects.

The fixed fictional fixture has nine attempts across six logical requests: five success responses, two error responses, and two unknowns. Four logical requests have a success response, one has no success and an unknown, and one has error responses only. Two logical requests retain an unknown attempt; three have multiple attempts; one has multiple success responses. These are properties of invented records only.

## Research boundary and next evidence

This addition makes one accounting convention reproducible. Actual inference experiments still require authorized hardware, verified model/runtime revisions, full attempt capture, a declared observation cutoff and timeout policy, separate latency/quality analysis, representative permitted inputs, and accountable review. The twelve permission scenarios in the earlier plan remain unexecuted. This reference does not change their status or the original eight quality cases.

For agent integrations, independently reconcile authoritative business records. HTTP replay semantics and service contracts cannot be inferred from these client observations. Primary references reviewed 1 November 2026:

- RFC 9110, section 9.2.2: https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2
- AWS, Making retries safe with idempotent APIs: https://builder.aws.com/content/3Ev0BENTyBr0XxzRk5FDZzgNYos/m

AI assistance was used to prepare this material. No empirical finding, author-reviewed scholarly release, peer review, identifier, or Scholar indexing is claimed.