Skip to content

§02c Jupiter — Non-Language Bridge — Named-authority standing

Mars® Spec§02c Jupiter — Non-Language Bridge › Named-authority standing

← Outbound enforcement constraints (NB3, NB4, NB5) · Section index · Scope-of-applicability certificates →

7. Named-authority standing

A named human authority is an individual whose standing declaration is registered in the authority registry as a typed, cryptographically-signed eight-field record. The declaration is a structural primitive of the specification registry — not an operational role claim — and is the exclusive basis on which the verification system admits recorded actions authorizing downstream consumption of certified predicates for consequence-bearing operations.

Eight-field authority-standing declaration:

Field Contents
1 — Named-human-authority identity A typed record identifying the authority by one or more of: full legal name and organizational role, decentralized identifier, organizational employee identifier, professional license identifier, security-clearance identifier, or hardware-bound credential identifier (FIDO2, PIV, CAC)
2 — Consequence-bearing class set The set of typed consequence-bearing classes for which the authority has declared standing, each drawn from the registered consequence-bearing-class enumeration (§7.1)
3 — Declared scope For each class in Field 2, the typed scope within which the authority’s standing extends, expressed as a typed enumeration of admissible operational contexts, a typed range expression, a typed predicate over operational context, or a combination
4 — Issuing-authority identity The identity of the organization, agency, professional body, or regulatory authority declaring the authority’s standing (distinct from the named human authority)
5 — Issuing-authority signature A cryptographic signature of the issuing authority over Fields 1–4, attesting the declaration of standing
6 — Temporal validity window Issuance timestamp, expiration timestamp, and optional required re-attestation cadence
7 — Revocation-reference A reference by which the declaration’s revocation status may be queried at admission time, selected from: a transparency log reference, an OCSP-style endpoint, a content-addressed revocation registry, or a hardware-attested append-only revocation log
8 — Cryptographic signature A signature over Fields 1–7 concatenated, under an EUF-CMA-secure scheme at security level at least 128 bits

The authority registry is indexed by named-human-authority identity, by consequence-bearing class, and by issuing-authority identity. It is subject to the delta-attestation lifecycle (§02b §5) on amendment — standing declarations are registered artifacts whose version identity is load-bearing.

7.1 Consequence-bearing-class enumeration

The deployment’s consequence-bearing-class enumeration is recorded in the specification registry as a typed cryptographically-signed declaration comprising: the list of consequence-bearing classes, each with a class identifier, a class semantic content declaration, and an optional default scope representation; the issuing-authority signature of the deployment or a recognized standards body authorizing the enumeration; and a cryptographic signature over the above. The enumeration is the universe from which Fields 2–3 of every standing declaration draw their class references. A standing declaration referencing a class absent from the registered enumeration is refused at registration. A recorded-action event referencing a class absent from the enumeration is refused at admission. The enumeration is itself subject to the delta-attestation lifecycle (§02b §5); amendment that removes or restricts a class cascades through dependent standing declarations.

7.2 Recorded-action discharge module

At a verification gate processing a recorded-action event by which a named human authority purports to authorize downstream consumption of a certified predicate as authoritative input to a consequence-bearing operation, the recorded-action discharge module applies a seven-check sequence. The module’s authority to discharge is conditioned on the predicate carrying a valid conformance certificate (§02b §2): the module refuses the predicate if the referenced certificate is absent, expired, or fails integrity verification and does not independently certify predicates.

Seven-check sequence:

# Check Refusal when
1 Consequence-bearing class present in enumeration Class is absent from the registered consequence-bearing-class enumeration (§7.1)
2 Authority-standing declaration found No declaration is registered for the named human authority for the consequence-bearing class
3 Declaration cryptographic signature verifies Field 8 signature fails verification against declared key material
4 Issuing-authority signature verifies Field 5 signature fails verification against the declared issuing-authority key material
5 Temporal validity window current Field 6 expiration timestamp has elapsed or re-attestation cadence has lapsed
6 Revocation-reference shows not-revoked Field 7 revocation-reference query indicates the declaration is revoked
7 Operation scope within declared scope The operation’s typed scope is not within the declaration’s declared scope (Field 3) for the consequence-bearing class

Checks 1–2 (class enumeration, presence) are evaluated before the cryptographic and runtime checks (3–6) so the module short-circuits on common structural failures before incurring revocation-query cost. The module admits the recorded action when all seven checks pass. Configurations declaring fallback admission paths bypassing any check are refused at deployment registration.

Standing coverage at the actuation gate. A co-signature from an authority whose standing declaration does not cover the actuation class or the scope of the actuation is a gate-check failure under §4.3 condition 8. Coverage is verified at the actuation gate by: (i) retrieving the standing declaration from the authority registry by the authority identifier in Field 7 of the actuation anchor; (ii) confirming the actuation class is in the authority’s consequence-bearing class set (Field 2); (iii) confirming the actuation scope falls within the authority’s declared scope (Field 3).

7.3 Cascading invalidation through the audit trail

Upon revocation, withdrawal, or amendment of a standing declaration, the verification system cascades invalidation through the audit trail to recorded actions performed under the declaration within a declared retention window:

  1. The audit trail is queried for recorded-action events performed under the revoked declaration within the retention window.
  2. For each affected recorded action, a typed cascade record is created in the audit trail naming the affected recorded action, the revoked declaration, the cascade timestamp, and the cascade outcome.
  3. Downstream consumers that consumed the authorized predicate are notified via the declared notification mechanism.
  4. Non-linguistic effects emitted under actuation anchors carrying the recorded action as named-human-authority co-signature are refused subsequent emission; pending non-linguistic effects are refused.
  5. Subsequent recorded actions by the same named human authority for the consequence-bearing class of the revoked declaration are refused admission until a replacement standing declaration is registered.

7.4 Standing declaration lifecycle

Amendment that narrows Field 2 (consequence-bearing class set) or restricts Field 3 (declared scope) produces at least a scope-restricting delta-classification (§02b §5.3) on any in-flight actuation anchors referencing that authority — they must be re-discharged under the narrowed standing before the re-discharge deadline declared in the delta-attestation object. Amendment that widens Field 2 or expands Field 3 produces a scope-extending delta-classification; in-flight anchors valid under the prior (narrower) standing may be optionally re-discharged under the expanded standing at the operator’s election. Editorial or identity-only amendment produces a scope-preserving delta-classification with no effect on in-flight anchors. Amendment that revokes the declaration entirely produces scope-breaking delta-classification with immediate cascade: all in-flight actuation anchors referencing the revoked authority are immediately invalidated and the audit-trail cascade of §7.3 is triggered. Actuation anchors are registered artifacts with lifecycle states Open and Invalidated; their registration home is the deployment registry and cascade invalidation is recorded against registered anchor identifiers.

7.5 Organizational issuer standing (certificate-issuer standing)

The named-human-authority standing declaration is the human-action species of a standing genus enforced through the same specification registry: a named human authority’s standing governs who may act; an organizational issuer’s standing governs who may certify; a reviewer’s standing governs who may review (§7.6). Each species carries its own registered class enumeration and is subject to accreditation, revocation, and cascade disciplines of common form. The genus is open to further principal species of the same form: in particular, the operator-revocable standing authorization under which a governed autonomous-reasoning loop operates (§04 §3.6) is, when registered, a standing declaration of this genus — its principal an autonomous system, its issuing authority a named operator holding an authority-standing declaration for the corresponding consequence-bearing class, its class set drawn from a registered enumeration of autonomous-operation classes, and its lifecycle subject to the same accreditation, revocation, and cascade disciplines (§7.3–§7.4). Registration of an autonomous-system standing declaration whose class set includes a consequence-bearing class reserved to named human authorities is refused: autonomous standing extends the genus; it does not relax the named-human-authority reservation.

The issuer-standing declaration declares which organizational issuer may issue which class of certificate. It is a typed, cryptographically-signed seven-field record registered in the specification registry: (1) issuer identity; (2) certificate-class set, each class drawn from a registered certificate-class enumeration (non-limiting: conformance certificate, scope-of-applicability certificate, cross-store calibration mapping, behavioral attestation, composed certificate); (3) declared scope per class (domains, jurisdictions, artifact classes); (4) accrediting-authority identity — the mark owner, standards body, or regulator declaring the issuer’s standing, distinct from the issuer — with the accrediting authority’s signature over fields 1–3; (5) temporal validity window with re-accreditation cadence; (6) revocation reference; (7) cryptographic signature over fields 1–6.

Every consumption gate that would rely on a certificate first verifies that the certificate’s issuer holds a valid, in-scope, unrevoked issuer-standing declaration for the certificate’s class; reliance is refused otherwise with a typed issuer-standing diagnostic. Revocation of an issuer-standing declaration by the accrediting authority cascades through the audit trail to certificates issued under the declaration within the declared retention window, with consumer notification; subsequent reliance is refused until re-issuance by an issuer holding valid standing — de-accrediting an issuer reaches the certificates it issued, not merely its future issuance. The accrediting-authority signature may be federated across constituent organizational signatures against a declared federation policy; withdrawal of any required constituent signature invalidates the declaration. An issuer’s standing may be delegated for a declared window to a subordinate issuer, the subordinate’s declaration recorded against the delegating issuer’s signature and bounded by the delegating issuer’s own declared scope; revocation of the delegating issuer’s standing cascades through the delegation. The issuer-standing declaration is a registered artifact subject to the delta-attestation lifecycle (§02b §5), with the §7.4 amendment semantics applying: narrowing produces at least a scope-restricting classification; revocation is scope-breaking with immediate cascade.

7.6 Adjudication-event records and reviewer standing

The act of review is itself a registered, first-class object. An adjudication-event record is the typed, signed object by which a human review of a registered artifact enters the system, comprising seven fields: (1) artifact identity — the reviewed artifact’s content hash and registered artifact class (a specification, interpretation-generation specification, calibration mapping, behavioral-condition representation, cross-domain typed interface, or model); (2) verdict, drawn from the recorded-action enumeration {accept, modify, reject, refer, revoke} (§7); (3) reviewer set — each named reviewer referencing a reviewer-standing declaration, an authority-standing declaration (§7) whose consequence-bearing class set is a set of registered artifact classes for review, with a per-class quorum requirement (k-of-n reviewers with distinct standing); (4) rating-unit population and agreement statistic — the per-unit judgments by each reviewer over the artifact’s constituent elements and the inter-reviewer statistic computed over that declared population against the registered threshold (§01 §8); a single holistic judgment per reviewer does not satisfy this field; (5) boundary-closure attestation where the artifact class requires one (§8.2); (6) timestamp and adjudication basis — one of bootstrap adjudication (§02a §2.2), amendment re-adjudication (§02b §5), drift re-certification (§02b §5.5), or referral response (§3); the quorum and threshold are declarable per basis; (7) signature over fields 1–6, the reviewer signatures recorded within.

The adjudication discharge module refuses to register an adjudication event when any participating reviewer’s standing declaration is absent, expired, revoked, or out of scope for the artifact class, when the per-class quorum is not met, or when the agreement statistic fails the declared threshold. Each verdict routes to a structural consequence: accept registers the artifact with the adjudication-event record incorporated as its reviewer-attested faithfulness anchor; modify returns the artifact with typed findings and requires re-adjudication before registration; reject refuses registration while retaining the record; refer emits a routing-with-trigger referral object (§3) to the joint authority; revoke invalidates a prior registration with cascading invalidation through the audit trail to consumers within the declared retention window. The verdict routing is what distinguishes adjudication from sign-off: every verdict, including the negative ones, produces a typed, consequential, auditable object.



← Outbound enforcement constraints (NB3, NB4, NB5) · Section index · Scope-of-applicability certificates →