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 resilience harness 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 carries a distinct type rather than a bare Text.

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

An Admitted decision admits; a Blocked or BlockedByDefault decision rejects ByPolicy, naming the deciding rule and carrying the human-readable renderDecision as the message. An Undecidable decision (a fail-closed rule that could not be computed) 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 admission 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.