Concept: Authority packages

Status: fixture-rehearsed. The full lifecycle (import → candidate → review → activate → revoke) walks as a fixture in crates/gestalt-cloud. Real package activation is in closed_runtime_boundary (see 022 gap report item 3). The only fixture package today is authority-packages/france-market-entry-projection-2026-04.json. German invoice/VAT/GoBD packages are marked planned_fixture_family in authority-packages/catalog.fixture.json.

What an authority package is

An authority package is a signed, versioned bundle of operationally-binding governance, published by an accountable party, that can be imported into a tenant’s Geist after a structured review.

A package typically bundles:

• a set of capability atoms (what acts mean operationally),
• a set of pendulum rule sets (rules that radiate authority within spheres),
• the authority sources they cite (regulations, court decisions, published standards),
• attestations by professional bodies (Kanzlei, auditor, chamber),
• a publisher signature,
• liability terms binding the publisher to the package’s claims,
• supersession metadata (which prior package this replaces).

A package is the unit by which legal-operational opinion enters Gestalt. Without packages, a Koerper cannot meaningfully cite a capability that does anything stronger than a fixture predicate.

Why packages instead of code

Conventional governance software hardcodes rules. A typical SaaS app “knows” how German VAT works because the developers wrote it that way. This has three failure modes:

1. Drift. When the law changes, the code lags. The lag is silent.
2. Opacity. When a rule fires, no one can point to its source. The rule and the source are in different buildings.
3. Liability fog. When a rule is wrong, no accountable party carries the consequence. The vendor invokes its disclaimer; the user is on their own.

Packages fix all three by being first-class signed publications:

1. A package supersedes a prior version with explicit metadata. The transition is auditable.
2. Each capability cites its authority sources by content hash. Each rule set cites its source documents by content hash. Drilling from “this atom was admitted under this rule” to “here is the regulation paragraph” is mechanical.
3. The publisher signs. The publisher’s professional reviewer signs. Liability terms are part of the package. When something is wrong, the chain of accountability is in the data.

Package lifecycle

import       publisher submits signed manifest with content hash, source hash
   |
   v
candidate    Gestalt evaluates the manifest, accepts as candidate
   |
   v
review       reviewers (professionals, auditors) approve or refuse
   |
   v
activate     fixture admission only today; production activation is gated
   |
   v
revoke       publisher or trust-revocation withdraws the package

Each step is its own membrane operation:

authority.package.import      POST /v1/authority/packages/import
authority.package.candidate   POST /v1/authority/packages/candidate
authority.package.review      POST /v1/authority/packages/review
authority.package.activate    POST /v1/authority/packages/activate
authority.package.revoke      POST /v1/authority/packages/revoke
authority.package.status      GET  /v1/authority/packages/status

See api/authority.md.

What a package looks like (fixture)

A simplified view of authority-packages/france-market-entry-projection-2026-04.json:

{
  "package_ref": "authority_package:france_market_entry_projection_2026_04",
  "kind": "projection_authority_package",
  "jurisdictions": ["DE", "FR"],
  "authority_epoch": "authority_epoch:fixture_2026_04",
  "publisher": "verlag:fixture_eu_market_entry",
  "publisher_signed": true,
  "supersedes": null,
  "manifest_version": "authority.package.manifest.v0.fixture",
  "source_hash": "sha256:fixture_source",
  "content_hash": "sha256:fixture_manifest",
  "pendulum_rule_sets": [...],
  "capability_atoms": [...],
  "attestations": [...],
  "liability_terms": "fixture only; no production reliance"
}

The real publication path is gated. Today the package is hand-rolled JSON; production publication will require:

• a real publisher account with an identity that can sign,
• a Verlag editorial pipeline that captures source documents at content hash,
• a professional reviewer with standing to sign reviews,
• a registry trust model so tenants can decide which publishers they rely on for which scopes.

See 022 items 3 and 8.

Importing a package (fixture walk)

const imported = await client.packageImport({
  tenant: "tenant_node:rheinwerk_calibration",
  package: "authority_package:france_market_entry_projection_2026_04",
  publisher_signed: true,
  manifest_version: "authority.package.manifest.v0.fixture",
  source_hash: "sha256:fixture_source",
  content_hash: "sha256:fixture_manifest",
  tampered_manifest: false,
  stale: false,
  self_activate: false,
});

// imported.outcome === "admitted"
// imported.body.candidate is the candidate ref

If the manifest is tampered:

const tampered = await client.packageImport({
  ...,
  tampered_manifest: true,
});

// tampered.outcome === "refused"
// tampered.body.refusalReason === "authority_package_tamper_refused"

If the source has gone stale:

// stale: true  →  refused with "authority_package_stale"

These refusals are the load-bearing part of the fixture: they demonstrate that Gestalt refuses untrustworthy publications, which is the only thing that makes trustworthy ones meaningful.

Reviewing a package

const review = await client.packageReview({
  tenant: "tenant_node:rheinwerk_calibration",
  package: "authority_package:france_market_entry_projection_2026_04",
  reviewer_decision: "approve",  // or "refuse"
});

Today the reviewer identity is implicit. Real review will require:

• a reviewer with attested professional standing for the package’s scope,
• a signed review with conditions (time-bound, scope-bound),
• the ability to attach a reviewer opinion (a kind of intervention).

See advisor-lenses.md for the broader intervention model.

Activating a package

const activation = await client.packageActivate({
  tenant: "tenant_node:rheinwerk_calibration",
  package: "authority_package:france_market_entry_projection_2026_04",
  publisher_signed: true,
  reviewer_decision: "approve",
  self_activate: false,
});

// activation.outcome === "admitted"
// activation.body.decision === "admit_fixture_only"

self_activate: true is structurally refused (authority_package_self_activation_refused). A publisher cannot activate its own package without an external reviewer signal — this is enforced at admission, not by social convention.

Revoking a package

const revocation = await client.packageRevoke({
  tenant: "tenant_node:rheinwerk_calibration",
  package: "authority_package:france_market_entry_projection_2026_04",
});

Revocation does not delete the package. It records the revocation as an admitted lifecycle atom. Atoms previously admitted under the package remain valid for what they were admitted under, but new atoms cannot cite the revoked package.

This is the same discipline as capability supersession: history is not rewritten when authority changes.

Trust scoping

A tenant does not trust a publisher globally. Trust is scoped:

trusted_for:
  standing_sources
  law_sources
  professional_attestations
  registry_claims
  identity_evidence
  payment_conditions
  clause_libraries
  proof_verification

A publisher trusted for clause libraries is not automatically trusted for tax interpretation. A bank trusted for settlement evidence is not automatically trusted for employment facts. A lawyer trusted for one matter is not automatically trusted for every contract.

Today this scoping lives implicitly in the fixture catalog. The production version requires a registry trust workflow that does not yet exist.

Catalog

The local catalog is at authority-packages/catalog.fixture.json. It separates implemented fixture packages from planned_fixture_family entries. Today the only implemented fixture package is the France market-entry projection. The German invoice/VAT/GoBD package family — the one that would matter most for Gestalt’s first product wedge — is planned but not implemented.

What “fixture-only” means in the package context

When you see decision: "admit_fixture_only", it means:

• the package’s manifest and source hashes were structurally accepted,
• the publisher signature was structurally validated (against the fixture keyring, not a real PKI),
• the reviewer decision was applied,
• but the package’s effects on actual atom admission are fixture effects, not production-binding rules.

A capability cited from a fixture-activated package will admit fixture atoms. It will not admit atoms with real legal weight.

Where to read next

• Atoms and capabilities
• Pendulums and Verlag
• Receipts and proofs
• API: authority
• Guide: publishing an authority package