The closed, evaluation-agnostic vocabulary of built-in rules an operator selects and refines in config. Most built-in rules reason only over the PackageDetails an adapter already fetched; AllowIfRemediatesCve additionally consults the local advisory database through the boot-bound RuleDeps.

This is data, not the engine's runtime representation: a small, inspectable, Eq/Show enum so config can parse, patch (override a rule's parameters), and name each rule. Ecluse.Core.Rules turns it into the engine's runtime PreparedRule (binding how it is evaluated) for evaluation. It carries no allow/deny "direction" -- whether a rule admits or blocks is simply what its evaluation returns.

It is also the security boundary on what config can express: untrusted config only ever yields closed Rule data, never arbitrary computation. A rule whose evaluation performs IO (AllowIfRemediatesCve) is a plain constructor here that evalRule dispatches on; arbitrary evaluation closures are a code-layer capability, never reachable from config.

A stable, human-facing name for a rule -- its identity, derived from the data: the boot-order tiebreak and the credited identity in logs and denial messages.

A Rule paired with the integer precedence at which it competes (higher wins). This is config's resolved-policy element; Ecluse.Core.Rules prepares it into the engine's runtime rule, whose boot-time ordering (bootOrder) turns precedence -- and, at equal precedence, the rule name -- into the single total order the engine walks.

Precedence is a field, not an Ord instance: equal precedence between two rules is legal (it is resolved by name in the boot order), so a total derived Ord would be non-antisymmetric -- unlawful and misleading. This mirrors Version, whose ordering likewise goes through a function rather than a derived instance.

The default precedence for a rule type -- used when a policy omits an explicit precedence for a rule.

Every deny type defaults strictly above every allow type, so "any deny overrides any allow" holds out of the box. The rule types occupy two bands: the allow band, ordered by how explicit the operator's statement is (AllowIfOlderThan < AllowIfRemediatesCve < AllowScope < AllowByIdentity), then the deny band (defaultDenyInstallTimeExecutionPrecedence, defaultDenyByIdentityPrecedence) strictly above all of it. An operator may still raise a specific allow above a specific deny by giving it a higher explicit precedence -- the per-type defaults set only the out-of-the-box ordering.

Pair a rule with its type's defaultPrecedence.

Default precedence of AllowIfOlderThan: the lowest band, a passive quarantine that yields to an explicit allow-list and to every deny.

Default precedence of AllowIfRemediatesCve: above the passive age quarantine, which is the point of the fast lane -- a security fix is admitted immediately instead of waiting out min-age -- but below AllowScope, so a scoped package an operator already trusts never pays the advisory probe and the more explicit rule keeps the audit credit.

Default precedence of AllowScope: above the passive age quarantine -- an explicit allow-list of a trusted internal scope is a stronger statement than the time gate -- but still below every deny.

Default precedence of AllowByIdentity: the top of the allow band -- an exact identity is the most explicit allow an operator can state -- yet still strictly below every deny default, so revocation and the install-script deny keep the last word.

Default precedence of DenyInstallTimeExecution: the deny band, strictly above every allow default, so a matching deny overrides any allow out of the box.

Default precedence of DenyByIdentity: the top precedence, strictly above every other rule (including explicit allow-lists), to serve as a hard revocation.

Ambient information a rule may need that is not part of the package itself (the wall-clock "now" for age calculations).

A human-facing reason a rule attaches to its result, kept for the audit trail.

The verdict of a single rule against a single package version.

A result is decisive iff it is Allow, Deny, or Unavailable _ FailDeny _. NoDecision and Unavailable _ FailNoDecision _ are non-decisive no-ops; the engine collects their reasons (in boot order) for the deny-by-default audit trail.

How a rule's Unavailable result aligns when the rule could not be computed.

There is deliberately no FailAllow: a failed or uncomputable check must never admit unvetted bytes. A rule whose verdict is load-bearing for safety fails closed (FailDeny); a remediation/allow-direction rule whose missing signal should not block availability fails open (FailNoDecision).

The overall decision for a package version against a whole rule set.

The deciding rule is credited by name (Text): a rule's stable identity is its name (see ruleName), independent of how it is evaluated.

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.