The outcome of deciding a request: serve it, or refuse it with a reason.

Every client-facing reply renders one of these. Admit carries no payload — the artifact or packument is what is then streamed; Reject carries the Rejection that explains the refusal and selects the status.

A refusal: why it was refused, and an intuitive message for the client. The rejectionReason selects the HTTP status; the rejectionMessage is the human-facing text rendered into the response body.

Why a request was refused.

A policy refusal is a deliberate verdict and is final for this request; an unavailability is an inability to decide and carries whether it is expected to self-heal, which is what separates a retryable 503 from a terminal 500/403.

Whether an unavailability is expected to resolve on its own.

This is the single distinction the serve status mapping turns on: a transient cause (WillResolve) is worth retrying (a 503); a permanent or internal one (WontResolve) is not, so it must not be dressed up as a retryable 503 (it is a 500). The effectful tier sets it from the nature of the failure: an upstream outage, rate limit, timeout, or open breaker is transient; an internal or parse fault is not.

A Retry-After delay, in whole seconds. A 'newtype' so a raw count of seconds is never confused with some other integer when it reaches the response header.

The name of the rule that decided a refusal, carried for the audit trail and the denial body. A 'newtype' over the ruleName text so a rule identity is not just any string.

Project a rules Decision (see Ecluse.Rules) into a serve outcome. Pure and total.

An Approved decision admits; a Denied or DeniedByDefault decision rejects ByPolicy, naming the deciding rule and carrying the human-readable renderDecision as the message. An Undecidable decision (a needed effectful rule could not be consulted) rejects as Unavailable, carrying its Transience so the status mapping can choose 503 vs 500 — fail-closed, exactly as a denial removes a version, but flagged retryable when the cause may self-heal. Only an approval admits.

The HTTP status a concrete-artifact request renders to. A domain sum type (not a raw code) so the mapping is total and the WAI layer reads off an exhaustive set; artifactStatusCode gives the numeric code.

A packument request has no single status — its versions are filtered and a status is chosen over the survivors — so this type models only the concrete-artifact case.

Map a serve outcome to its concrete-artifact status. Pure and total.

403 for a policy refusal; 503 when an unavailability WillResolve (a retry may help); 500 when it WontResolve. __503 only when we believe it will resolve__ — a permanent or internal inability is a 500, since retrying it cannot help. A 404 upstream miss is not a serve decision (the version exists unless upstream says otherwise), so it is not produced here.

The numeric HTTP status code for an ArtifactStatus. Pure and total.

The HTTP status a packument request renders to, chosen once the merged survivor set is known. A packument has no single per-version status — its versions are filtered and merged across upstreams — so the status is chosen __over the survivors__: with at least one survivor the document is served; with none, the status follows the most recoverable cause among the exclusions (see packumentStatus).

A domain sum (not a raw code) so the mapping is total and the WAI layer reads an exhaustive set; packumentStatusCode gives the numeric code. There is no 404: a packument whose versions were all withheld is not a miss — the package exists, so a genuine upstream absence (no such package at all) is a separate concern of the serve layer, decided before the merge.

Choose a packument's status from the per-version serve outcomes weighed for it: the Admits for surviving versions (trusted, or rule-approved) and the Rejects for excluded ones — plus any Reject a needed-but-unavailable upstream contributes. Pure and total.

Any Admit means the merged document has a survivor, so it is served (PackumentOk). With no survivor the status follows the most recoverable cause among the exclusions, so a retry is invited exactly when it might produce survivors:

• any Unavailable WillResolve → 503, suggesting the longest RetryAfter any such cause asked for (so every transient cause has likely cleared by then);
• else any UpstreamInvalid → 502 (a responding upstream returned a packument for a different package; ranked above the terminal 500/403 because it names a concrete, actionable gateway fault, but below the retryable 503 since a transient origin may yet come back with a valid document);
• else any Unavailable WontResolve → 500 (a permanent inability — a retry cannot help, so it is not dressed up as a retryable 503);
• else every exclusion is a deny-by-default cause — a ByPolicy rule denial or an admission refusal (MissingIntegrity or BelowIntegrityFloor), __including the degenerate empty input__ → 403: there is nothing to serve and nothing invites a retry.

Never 404: the versions existed and were withheld (see PackumentStatus).

The numeric HTTP status code for a PackumentStatus. Pure and total.

The longest suggested RetryAfter among transient causes, or Nothing when none of them suggested a delay.

An operator-configured message appended to every denial — typically where to ask for help (e.g. a support channel). Stored trimmed of surrounding whitespace so it joins the denial text with a single separating space and an all-blank value contributes nothing.

Build a HelpMessage, trimming surrounding whitespace.

The trimmed help-message text.

Append a non-blank operator HelpMessage to a denial message, separated by a single space; a blank or absent help message contributes nothing.

This is the ecosystem-neutral part of denial rendering — every ecosystem appends the operator's help text the same way. How the joined text is then wrapped into body bytes is the mount's MountRenderer.

A rendered error body: its Content-Type and the bytes.

The agnostic serve layer chooses the HTTP status; the body shape — JSON, plain text, HTML — is the mount's, so a MountRenderer returns this pair and the WAI layer reads the content type off it rather than assuming one.

A mount's ecosystem-specific error renderer — the Handle that keeps the npm {"error": …} shape (and any other ecosystem's) out of the agnostic web layer.

The status machinery here is ecosystem-agnostic, but the body a client reads an error from is not: an npm client expects a JSON {"error": …} object, a PyPI client a different surface. Each mount supplies a renderer, chosen at the composition root alongside its path grammar, so the web layer holds no body shape of its own. renderError shapes a denial or meta-route error (a 403/404/501 body) from the optional operator help message and the human-facing reason.