# First-write admission record Hypothetical teaching cases. The reported local tests checked selected behavior in an invoice implementation that holds its records in memory. This download records the results; it does not include that software. The tests do not establish production permission, compliance, safety under concurrent requests, or approval to enable writes. Read [What should a tool check before changing a record?](https://caisi.dev/notes/agent-first-write-authorization/). ## Selected completed local checks | Case | Observed local result | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Ordinary authorized request | One hold release saved and checked | | Direct call to the write service without approval | Service refuses; zero hold releases | | Approval belongs to another proposal | Workflow stops for review before calling the write service; zero write requests; zero hold releases | | Caller loses permission after the workflow's earlier check | One write request; receiving service refuses; zero hold releases | | Expired approval | Workflow refuses before calling the write service; zero write requests; zero hold releases | The workflow can stop a request before calling the service that applies the correction. That does not prove the receiving service could refuse a direct call that bypasses the workflow. The missing-approval and revoked-permission cases test the service itself. For every refused request, inspect saved records too: an error message alone cannot prove that no hold was released. ## Proposed target checks: not run | Required check | Evidence needed before a target claim | | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Who started the work, which service carries it out, and who calls the write service | Trusted identities, customer, record, and action; all applicable current permissions must allow it. The model cannot supply permission. | | Exact proposed contents | Stored approval identifies the unchanged proposal; changing its contents invalidates that approval. | | Approver and time | Verify the approver's identity and role, any required separation from the requester, and when approval begins and expires. | | Current policy and record version | The receiving system checks current policy and enforces the expected record version as part of the write, or provides equivalent protection against a change between check and write. | | Tool build and production release | The exact tool build is approved for the compatible release, has an accountable owner, and can be disabled. | | One intended correction | The receiving system prevents the same operation being applied twice, including when requests arrive together. | | Saved result required for success | A permitted source-system check finds the correct record, operation, and resulting state. | | Refused request, unavailable check, or uncertain result | No forbidden change; a responsible person owns investigation, a hold, or the permitted manual alternative. | Current target disposition: **writes disabled; target evidence not supplied**. No actual owner, permission, approval, or release is assigned by this worksheet. ## Blank record for one permitted action ### Start with these questions 1. Which exact record may change, and what is the largest permitted change? 2. Who requested and approved it, and how does approval identify the unchanged proposal? 3. What does the receiving service recheck immediately before applying it? 4. Which saved result proves it happened once, and what happens if that result is unknown? ### Check the action boundary | Question | Record | | -------------------------------------------------------------------------------------------------------------- | ------------ | | Who owns the workflow, and who owns the receiving service? | Record | | What action is allowed, on which exact record, with what maximum change? | Record | | Which initiating person, background service, caller, and customer identities were verified? | Record | | Which current permissions must allow the action for those identities? | Record | | Which current record and policy versions apply, and how old may each be? | Record | | What is the proposal ID, and how does approval identify its exact contents? | Record | | How is the approver verified, when does approval expire, and must the approver be separate from the requester? | Record | | Which exact tool build and release are approved, who owns them, and how can they be disabled? | Record | | Which operation ID identifies the intended change, and how does the receiving system prevent duplicates? | Record | | Which saved result proves success, and how may it be checked in the source system? | Record | | What happened in tests for missing approval, a changed proposal, and revoked access? | Not run | | What happened with old record state, duplicate requests, and unavailable confirmation? | Not run | | After each refused request, did inspection confirm that no forbidden change was saved? | Not run | | Which cases remain unresolved, who owns them, and what safe step comes next? | Record | | Has an authorized owner approved release, using which evidence? | Not approved | Do not include private records, credentials, customer identifiers, or restricted source locations in a public copy.