Bind AI download metadata to the reviewed artifact

Review the response after approving the object

A fictional console offers a two-line maintenance summary A-A, revision R-A. Its plain-text UTF-8 bytes have already passed a separate admission process, and the current recipient may download that exact revision. Yet the response builder still needs to decide how those bytes are described to the browser.

This is a later boundary than publishing complete immutable bytes or authorizing a download link. It is also separate from inserting model text into a page. The selected surface is one authenticated attachment response, with no inline preview, redirect, range request or arbitrary uploaded format.

The proposed service uses Django FileResponse for an already admitted binary-content file object. Acquiring the correct object, preserving its bytes and position, and managing its supported serving lifecycle remain separate prerequisites. No file is opened or inspected here.

Make helper inference an explicit decision

The Django 6.0 reference documents FileResponse(open_file, as_attachment=False, filename='', **kwargs). With as_attachment=True it sets attachment disposition; otherwise it sets inline only when a filename is available. A custom filename is available when the file object’s name is absent or inappropriate. Content-Type can be guessed from that filename or the file object’s name, and set_headers runs during initialization.

For A-A, choose one fixed public filename, summary.txt, and as_attachment=True. Do not derive either choice from a model answer, storage label or recipient name. A renamed object does not automatically deserve a different public representation.

The same reference documents response-header assignment. Our proposed construction review places the explicit Content-Type and X-Content-Type-Options assignments after helper initialization, then checks the required tuple. This avoids relying on an undocumented precedence between an inferred field and a constructor shortcut. No later code may rebuild those fields from a filename.

Keep filename, disposition and type separate

MDN’s Content-Disposition reference distinguishes inline from attachment and describes a filename used in the browser’s save interaction. Browsers can transform names to satisfy local filesystem rules. Therefore summary.txt is a proposed public filename, not proof of the final local name or destination.

This profile accepts no arbitrary filename input. Its fixed short ASCII name avoids needing a general quoting, Unicode or path-sanitization recipe. Changing to personalized names, caller-selected extensions or multiple formats requires another review. A header-setting API is not a content classifier.

The explicit media requirement is text/plain; charset=utf-8. That declaration must correspond to the independently admitted bytes; setting a field does not convert their encoding or remove active content. If the artifact is not the selected plain-text representation, hold it rather than relabel it to pass the worksheet.

Describe nosniff according to the receiving context

MDN documents two nosniff effects: script and style destinations block unexpected MIME types, while other responses, including document navigations, use the declared Content-Type instead of sniffing a different type. The selected attachment policy requires nosniff alongside the correct type; it does not treat this as an all-purpose request blocker.

For this design, attachment describes the intended download interaction and nosniff constrains MIME interpretation in the documented contexts. Neither authenticates the recipient, checks summary accuracy or governs a program the user later chooses to open. No universal nonexecution, browser sandbox or safe-file claim follows.

Actual browser applicability and effective headers after middleware, server and CDN processing remain unverified. A future implementation must establish that they match the chosen contract. Source-level intent alone is insufficient, and this guide supplies no middleware or proxy configuration.

Write one metadata admission sheet

This original sheet is policy notation only. It creates no response, header object or download:

PROPOSED_UNRUN
Object: A-A / revision R-A / admitted byte identity B-A
Consumer: current authorized recipient / download only
Representation: admitted plain-text UTF-8
Public filename: fixed application literal summary.txt
Django plan: as_attachment=True; explicit filename
After initialization: explicit text/plain; charset=utf-8
Additional required field: X-Content-Type-Options = nosniff
Outcome permitted here: metadata plan eligible for separate release review

The positive preserves a useful ordinary summary download. It is conditional on matching byte identity, current coordinated rights, a supported framework and file-serving path, effective headers and applicable browser behavior. These are unimplemented prerequisites here; unknown evidence blocks eligibility.

Keep object and revision identifiers in protected review evidence. The filename deliberately carries no owner, account or workspace identity. Producing the same public name for different authorized summaries does not merge their object identities; the trusted delivery mapping must retain that distinction.

Challenge eight proposed metadata decisions

Keep evidence and product scope narrow

The Django body identifies version 6.0, not an installed patch. The MDN pages inspected were modified October 12, 2026 and March 17, 2026. No live application, browser or delivery configuration was examined.

For these proposed cases, no response, header, request, file, browser download, Django import or runtime fixture was constructed or exercised. Documentation reads and private editorial file handling are separate. The sheet establishes no cache policy, complete transfer, storage safety or recall of saved copies.

Boundary is a prelaunch model router with planned request-path checks, not a shipped Django delivery or MIME-validation service. Its synthetic action exercise and existing mock evidence do not test this response contract.