The direct answer
Keep successful record checks separate from complete-artifact acceptance. For the selected nonempty aes128gcm body, require supported authentication, record-position and padding validation through the actual final record and complete body boundary. A checked prefix or closed connection cannot substitute for that evidence; current content and release permissions remain separate.
A checked prefix is still a prefix
A receiver stages an encrypted AI-generated maintenance artifact. One record’s authentication check is supported, then the transfer ends. The interface reports the artifact complete because nothing received so far failed that check. But the missing suffix is exactly what the receiver has not established.
This original worksheet selects one finite, nonempty body using RFC 8188’s aes128gcm content coding. It assumes independently admitted trusted writers and an intended receiver; malicious keyholders are outside the positive. It excludes range access, coding stacks, header-only empty-body branches and custom encrypted-record formats. The earlier one-shot AESGCM worksheet remains unchanged.
Bind completion to the selected record format
RFC 8188 sections 2–2.3 use fixed-size records, with a possibly shorter last record. Authenticated padding distinguishes final delimiter 2 from nonfinal 1; invalid or absent delimiters fail. Nonces incorporate record position.
Sections 4.1–4.2 address automatic coding removal and reject partial-as-whole delivery. Preserve actual coding evidence. This June 2017 Standards Track document is not installed-decoder evidence or a current deployment recommendation.
The selected application adds a stricter release policy: keep all plaintext unavailable to parsers, models and other consumers until complete-body disposition is established. That staging rule is original policy, not a claim that the RFC prohibits all incremental processing.
Walk an original two-record paper case
Invent approved artifact A-A/revision V-A and a protected body-context reference B-A. The intended nonempty content has two symbolic records, R0 followed by R1. Their proposed roles are nonfinal and final respectively. These labels denote review evidence; no ciphertext, delimiter bytes, authentication tag, nonce, key or encoded message was created.
Suppose the available evidence concerns only R0’s tag check, with its nonfinal role. If R1 never arrives, that evidence cannot become a complete-body result. In particular, treating R0 as the last record does not transform its nonfinal delimiter into the required final one. Keep record authentication and complete format validation in different columns.
The useful conditional positive requires supported results for the entire intended body in its proper association, including finality and complete boundary handling, plus the application’s remaining artifact-release gates. A familiar filename, an ended connection or a plausible plaintext prefix cannot supply the missing result.
Any unexpected suffix must receive a supported complete-decoder disposition under this profile. Do not stop inspection at the first promising final-marker observation or silently discard remaining input. A marker considered outside its authenticated record and body position is insufficient evidence.
Keep a finite-body completeness sheet
| Evidence row | Question it must settle |
|---|---|
| Object and context | Which approved artifact revision and complete coded-body association is intended? |
| Admitted decoder profile | Which supported complete framing, cryptographic, padding and error behavior applies? |
| Ordered record coverage | Which required positions have actual supported results? |
| Finality and body boundary | Is final-record validation established for the complete body, with suffix disposition known? |
| Staged output association | Are the exact completed plaintext and accepted revision kept stable through handoff? |
| Release decision | Do content admission and current viewing/model-route rights still permit the intended use? |
The sheet deliberately has no single decrypted_ok flag. Record progress may be useful operational evidence while the whole artifact remains unavailable. Completion status also cannot be inherited by a later object replacement or another body with similar decoded text.
Actual key custody, writer and receiver admission, key derivation and nonce lifecycle, supported decoder, effective coding path, complete bounded capture, immutable staging, coordinated handoff and current rights are unimplemented or unknown. Any missing prerequisite blocks the positive. This is not a construction guide for those mechanisms.
Review eight independent inert cases
| Condition | Proposed disposition |
|---|---|
| R0 and R1, complete supported finality/boundary, stable A-A and all actual release prerequisites hold | Conditionally admit the exact completed artifact to separate content/release checks |
| Only R0’s tag result is supported; R1 is missing | Keep incomplete; no prefix-as-whole release |
| The connection ends after a nonfinal record | No completion from transport closure |
| A final-marker observation lacks supported record authentication or padding validation | Withhold complete-body acceptance |
| Unexpected trailing record, fragment or other suffix is unresolved | Hold; never silently ignore it to obtain success |
| Record position, body context or artifact revision changes | Do not reuse earlier evidence for the changed assembly |
| Decoder, key history, input bounds or staged-output custody is unknown | Block the positive; no guessed compatibility fallback |
| Complete decoding is supported but content or current access fails | Withhold parser/model disclosure independently |
No row reports an executed decoder result. The positive is conditional so this teaching exercise can preserve a useful permitted artifact without pretending that all implementations already satisfy the sheet.
Leave cryptographic and application scope separate
RFC 8188 sections 1, 4.3 and 4.5 leave key management to the larger design, require the needed per-message uniqueness, and limit authentication to entities possessing the relevant key. This does not establish the identity or authority of one unique sender.
Do not import the earlier worksheet’s tenant associated-data encoding into this different format: RFC 8188 specifies empty additional data. Trusted object/context association and complete key handling therefore remain independent design requirements here. No key acquisition, derivation, randomness, nonce allocator or operating-volume recipe is supplied.
A complete authenticated object can still contain unsafe instructions or restricted content. It establishes neither business-effect commitment nor replay prevention, durable storage, harmless parsing or all-copy deletion. Keep those decisions separate from this narrowly supported format-completeness result.
No request, HTTP field, record buffer, ciphertext, padding, key, nonce, decoder, encryption/decryption, crypto import, parser, API/model or runtime fixture was constructed or executed. Boundary is prelaunch and does not ship this encrypted-artifact receiver. Its synthetic policy, export and approval-status checks establish different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.