Glossary
Status: stable. These terms have one meaning across the docs and they will not silently change. If you find a doc using a term in a different sense, file an issue.
The vocabulary below is loaded. Read what-is-gestalt.md first if any of it is unfamiliar.
Core trinity
Section titled “Core trinity”The governed truth organ of a company. Holds durable company facts — invoices, payments, contracts, payroll facts, obligations, consents, mandates, attestations, legal situations, advisor opinions, filings, proofs, counterparty commitments. Narrow. Slow-moving. Signed. Append-only. Cannot be casually rewritten by application code. There is one Geist per company. See concepts/geist-and-koerper.md.
Koerper
Section titled “Koerper”The mutable operational body around a Geist. Product data, UI state, CRM fields, inventory tables, workflows, dashboards, caches, AI-generated apps, experiments, local projections. Vast. Fast-moving. Replaceable. Customer-authored. A company may have many Koerpers (a shop, a back-office UI, a mobile app, a Steuerberater console, an agent workcell). All of them propose; only the Geist admits.
The emergent field of all Geists in bilateral contact. Not a global database. Not a blockchain. Not a marketplace. The shape made by local relationships: company to customer, company to supplier, company to bank, company to Steuerberater, company to lawyer, company to regulator. No participant sees the whole mesh. (Note: mesh has no API surface today; see 022 gap report item 13.)
The atom and what it carries
Section titled “The atom and what it carries”The smallest durable unit of business reality in Gestalt. Every serious transition is an atom. Carries: subject, cause, authority, content, evidence, governance, effects, commitment. Atoms are admitted by Gravity, citing a capability. See concepts/atoms-and-capabilities.md.
Subject
Section titled “Subject”The party an atom is about. Often a company_geist:... ref but can
be a human_person:... or other subject ref.
The party that acts — the originator of the intent. Often distinct from subject. May be a human, an agent, an external system.
Vessel
Section titled “Vessel”The surface from which an actor proposes. A CLI session, a native desktop app, a browser, an MCP tool, an HSM-backed signer. Each vessel has a declared signing posture that Gravity uses to decide whether the vessel can complete a serious act or only propose one. See concepts/the-membrane.md.
Signing posture
Section titled “Signing posture”The trust floor of a vessel. Examples:
dev_full_signinglocal_fixture_signingproposal_onlypaired_native_signinghsm_backed_signingread_onlyIntent envelope
Section titled “Intent envelope”The structured request a vessel sends to cross the membrane. Carries: who is asking, under what surface, for which company, in which reality, under which capability, with which content, citing which evidence, expecting which effects, with which signing posture.
Capability (capability atom)
Section titled “Capability (capability atom)”A published, accountable definition of what an act means. Itself an atom. Carries publisher, subject, capability identity, input schema, predicate, effect grammar, required evidence, allowed discretion points, referenced authority sources, import set, version relation, validity window, reliance terms, attestations, commitment. Other atoms cite capabilities by content address. See concepts/atoms-and-capabilities.md.
Capability publisher
Section titled “Capability publisher”The party that publishes a capability atom — typically a Verlag or a company’s own policy organ. Accountable for the prose, predicate, and effect grammar that the capability binds.
Capability import
Section titled “Capability import”A capability cited by another capability. An invoice capability may import standing validation, invoice numbering, VAT posture, evidence custody, document hash. Imports are content-addressed.
Standing
Section titled “Standing”A grant of capacity for an actor to bind a subject. (Geschaeftsfuehrer,
Prokurist, signing officer, mandated agent.) The membrane exposes
standing.claim, standing.evaluate, standing.grant, and
standing.revoke as staging-durable fixture lifecycle records — they
do not create production standing, and HumanAuth presence alone never
creates standing. See reference/capability-state.md.
Mandate
Section titled “Mandate”A scoped authorization for an actor — usually narrower than standing. Used heavily in agent governance. An agent acts under a mandate that defines its principal, readable lens, writable scope, tool scope, counterparty scope, amount limits, evidence requirements, intervention triggers, escalation policy, revocation path, and liability topology.
Evidence
Section titled “Evidence”Material that supports a claim in an atom. Captured as an evidence bundle — a signed, content-addressed bundle of source material. Evidence does not create authority; it backs claims that authority then admits.
Receipt
Section titled “Receipt”The shape-correct artifact returned by every membrane crossing. Carries
ref, outcome, reasons, optional signature, optional fixture flag. (Note:
today receipts are SHA256 hashes of (ref|subject|outcome), not real
signatures over canonical bytes; see
022 item 17.)
Proof bundle
Section titled “Proof bundle”A scoped, signed bundle of receipts, packages, evidence, and signer provenance, suitable for disclosure to a counterparty, advisor, or regulator. Disclosure is always entitlement-scoped.
Gravity, decisions, outcomes
Section titled “Gravity, decisions, outcomes”Gravity
Section titled “Gravity”The structural admission organ. Evaluates an intent envelope against a
world snapshot and returns a GravityDecision. Lives in
crates/gestalt-gravity. Gravity is not a legal oracle. It checks
structural conditions: subject validity, standing, capability citation,
evidence, signature binding, reality coherence, authority epoch,
effect grammar, closure-surface linkage. See
concepts/the-membrane.md.
GravityDecision
Section titled “GravityDecision”Admitted the atom enters the named realityRefused a structured refusal with failed gate, reason, remedyPending a pending action awaits a higher signing floor or evidenceOutcome
Section titled “Outcome”The membrane’s outcome enum, broader than Gravity. Used in receipts.
admitted serious atom committedrefused refused with codespending awaiting signing / evidence / advisorprojected admitted into a projected reality onlyverified a non-mutating call (probe, query, verify) succeededqueued accepted into an outbox (effect.intent)executed dispatched (effect.dispatch)failed dispatch attempted but failed (idempotent record)Refusal
Section titled “Refusal”A structured refusal carries failed_gate, capability_ref,
source_atoms, locus, reason, remedy_hint, required_evidence,
required_intervention, possible_projection_path,
whether_failure_is_recordable. Refusals are not generic errors. See
reference/refusal-codes.md.
Pending action
Section titled “Pending action”A membrane object awaiting a signing vessel or higher standing surface to complete. Carries the original intent envelope, required standing, required evidence, required channels, expiry, origin vessel, correlation id, preview, and a Gravity precheck.
Reality
Section titled “Reality”Reality
Section titled “Reality”The named history an atom lives in.
record the company's actual past and presentprojected:<id> a bounded possible worldline (a "what-if")shared_projected:<id> a projection visible to a counterparty (future)Projection
Section titled “Projection”A reality forked from record to rehearse a possible future without
binding it. Atoms admitted into a projection do not leak into record.
See concepts/realities.md.
Promotion
Section titled “Promotion”The governed act of moving (re-crossing) projected atoms into record under current record conditions. Promotion is not a copy; it is a fresh Gravity admission. Requires its own evidence and authority.
Discard
Section titled “Discard”The governed act of ending a projection while preserving the explanation of why.
Closure surface
Section titled “Closure surface”A structural object opened when an atom creates future pressure (“this receivable must be settled before the period can close”). Open closure surfaces block period close, period audits, and dependent atoms. See concepts/effects.md.
Tension
Section titled “Tension”A first-class object for an unresolved company-state conflict. Has
status open | resolved | scarred. A failed period close, a missing
piece of evidence, a contested fact — these become tensions.
A continuing causal thread across atoms — a refund fiber, a customer support fiber, a tax-audit fiber, a contract-renewal fiber. Lets explanations follow the actual causal graph rather than dashboards.
Zeitgestalt
Section titled “Zeitgestalt”The explanatory query organ. Asks “why” questions of a worldline:
why can March not close?, why was this atom refused?. Returns a
structured answer that walks atoms, capabilities, evidence, standing,
effects, and closure surfaces. See concepts/the-membrane.md.
(Note: the explanatory engine is shape-only today; see
022 item 14.)
Authority topology
Section titled “Authority topology”Pendulum
Section titled “Pendulum”A Geist whose emissions affect other Geists. Radiates authority or reliance within bounded spheres. Classes:
- Sovereign — states, courts, registries, regulators, Finanzamt.
- Professional — Kanzleien, Steuerberater, auditors, chambers.
- Commercial — insurers, banks, platforms, vendors, standards bodies.
- Verlag — publishers of legal-operational instruments.
- Company — boards, officers, compliance offices.
See concepts/pendulums-and-verlag.md. (Note: real Pendulum evaluation is not yet operational; see 022 item 4.)
Pendulum source
Section titled “Pendulum source”A raw source document a Pendulum cites — a regulation, a court decision, a published standard, a chamber opinion. Captured with content hash, version label, and freshness metadata.
Pendulum rule set / rule
Section titled “Pendulum rule set / rule”A grouping of rules a Pendulum publishes against an authority epoch. Each rule has a code, jurisdiction, trigger tags, condition, emits, required evidence, confidence.
Authority epoch
Section titled “Authority epoch”A bounded period during which a particular authority topology applies. Atoms cite the epoch under which they were admitted; if the epoch ends or is superseded, prior atoms remain valid for what they were admitted under. (Note: no membrane endpoint to define / transition epochs yet; see 022 item 19.)
Authority sphere
Section titled “Authority sphere”The intersection of subject, actor, territory, time, matter, operation, product, counterparty, company form, professional qualification, contract, policy, legal situation, and reliance terms under which a rule is active. See concepts/pendulums-and-verlag.md.
Verlag
Section titled “Verlag”A publisher of legal-operational instruments. Digests raw authority into capability atoms, predicates, evidence requirements, and operational effects. Accountable for the bridge between law and operation. Not a sovereign. Not the source of law.
Verlag instrument
Section titled “Verlag instrument”A specific publication of a Verlag — a clause library, a contract template, a CNL grammar, a checklist, a workflow definition.
Authority package
Section titled “Authority package”A signed, versioned bundle of pendulum rule sets and capability atoms published by a Verlag (or sometimes by a company itself). Goes through an import → candidate → review → activate lifecycle. (Note: real package activation is not yet enabled; see 022 item 3.)
Attestation / Attestor
Section titled “Attestation / Attestor”A scoped statement by a professional or accountable party (Kanzlei, auditor, chamber, insurer) attached to a specific version, scope, and liability window of an authority package, capability, or atom.
Effects and operations
Section titled “Effects and operations”Effect
Section titled “Effect”The bridge from governance to product behavior. An atom may emit effects that change what the company must do next. See concepts/effects.md.
Effect modes
Section titled “Effect modes”RefuseAtCommitCommitButWarnRequireEvidenceRequireInterventionRequireCounterpartyAckRequireWaitingPeriodRequireNotificationRequireAdvisorOpinionRequireExternalAuthorityMarkContestedOpenReviewMatterEffect intent / Effect outbox / Effect dispatch
Section titled “Effect intent / Effect outbox / Effect dispatch”Sensitive external effects (sending email, posting payment, notifying counterparty) are admitted as effect intents into a durable outbox, then dispatched with idempotent attempt records. (Note: real dispatch to external systems is not operational; see 022 item 12.)
Situation
Section titled “Situation”A first-class change in authority topology — insolvency proceeding initiated, tax audit open, litigation hold active, license suspended, sanctions hit, bank account frozen, data subject request received, court injunction served. Not just a status flag.
Advisors and intervention
Section titled “Advisors and intervention”Advisor lens
Section titled “Advisor lens”A scoped view onto a company Geist for an external professional
(Steuerberater, lawyer, auditor, bank, insurer, regulator). Defines
visible facts, permissible operations, issueable opinions, reliance
terms, confidentiality terms, validity windows, revocation path, proof
export rights. The membrane exposes lens.scope and lens.disclose as
staging-durable — they record explicit field scope and redacted
disclosure for advisor or Koerper access without exposing raw DB,
connector payloads, or biometric material.
Intervention
Section titled “Intervention”A signed speech act by a professional. A lawyer issues a risk note, legal opinion, approval with conditions, rejection, formal attestation, representation act, or request for evidence. A Steuerberater issues a posting proposal, VAT treatment opinion, filing approval, correction request, or year-end closing attestation.
Matter
Section titled “Matter”A bounded engagement between a company and an advisor — usually opened by the advisor through a lens. Carries scope, reviewed facts, issued opinions, validity, fees, confidentiality, retention.
Agents
Section titled “Agents”Workcell
Section titled “Workcell”The unit of agent governance in Gestalt. A support.refund.workcell,
receivables.reminder.workcell, crm.contact-maintenance.workcell,
bookkeeping.proposal.workcell. Each workcell has identity, principal,
mandate, readable lens, writable scope, tool scope, counterparty scope,
amount limits, evidence requirements, intervention triggers, escalation
policy, revocation path, and liability topology.
Standing ladder for agents
Section titled “Standing ladder for agents”Instrument agent drafts, extracts, classifies, proposes; no standingProposal agent creates proposed atoms and requests interventionDelegated agent commits independently inside a bounded mandatePendulum agent persistent identity, attestations, insurance, owner/deployer relation, limited standing in the meshIdentity, presence, sessions
Section titled “Identity, presence, sessions”HumanAuth
Section titled “HumanAuth”The membrane’s human-presence model. Two lanes:
- Private passkey lane — WebAuthn-style passkey assertion, no biometric material seen by Gestalt.
- CPU face-match fallback — explicit-consent 1:1 fallback proofing, ephemeral embeddings only, no template storage, no 1:N search.
A successful HumanAuth produces a human presence receipt. Presence does not create standing on its own. (See 022 item 15.)
Passkey binding
Section titled “Passkey binding”A WebAuthn credential bound to an actor and tenant. Stored as content-hashed binding metadata; raw credential material is not stored.
Session lifecycle
Section titled “Session lifecycle”Each session has issued/expires timestamps and a status active | revoked. Revocation is itself an admitted lifecycle record.
Hosted operator
Section titled “Hosted operator”A Gestalt-side delegate that may sign on behalf of a tenant under a
narrow scoped grant — used for shop-origin acts where the original
actor is a remote customer. See authority.hostedOperator.grant / revoke operations.
Connectors and witnesses
Section titled “Connectors and witnesses”Connector
Section titled “Connector”An external system from which Gestalt witnesses evidence — a bank feed, a DATEV export, a Lexware integration, a shop system, a payment processor. Connectors do not write company truth; they produce connector witnesses.
Connector witness
Section titled “Connector witness”A redacted, signed, content-addressed record that an external
connector observed something specific. Carries source system, source
hash, transform hash, raw kind. Raw payloads are not exposed through
the membrane. (Note: today only fixture: true connector witnesses
are accepted; see 022 item 11.)
Observed input / Transform receipt / Evidence bundle
Section titled “Observed input / Transform receipt / Evidence bundle”The pipeline a connector witness flows through:
observed input the redacted witnessed materialtransform a deterministic shaping into evidence shapeevidence bundle the signed, content-addressed bundle ready for atom citationEconomy
Section titled “Economy”Economic invoice
Section titled “Economic invoice”An invoice atom that creates a receivable obligation and a closure surface. Until the closure surface is resolved (matched payment + advisor evidence), the receivable blocks period close.
Payment observation
Section titled “Payment observation”A connector-witnessed payment that may settle a receivable obligation when amount, currency, and identifying claims match.
Bookkeeping fact
Section titled “Bookkeeping fact”An admitted accounting interpretation, requiring matching invoice + payment observation + (where required) advisor evidence.
Period close
Section titled “Period close”A request to close an economic period. Gates on resolved closure surfaces and explicit clearance evidence. Refuses if any closure surface is still open or any tension is unresolved.
Worlds, snapshots, refs
Section titled “Worlds, snapshots, refs”Reality ref / Atom ref / Capability ref / Evidence ref
Section titled “Reality ref / Atom ref / Capability ref / Evidence ref”Refs are content-addressed identifiers shaped like
<kind>:<identifier>. Examples:
reality:recordreality:m6_projection_repairatom:01H...capability:issue_invoice_fixture_v1evidence_bundle:invoice_payloadauthority_package:m6_cloud_authority_fixture_2026_04authority_epoch:fixture_2026_04human_presence_receipt:fixture_private_presencehuman_person:annacompany_geist:rheinwerk_calibrationtenant_node:rheinwerk_calibrationTenant
Section titled “Tenant”The top-level isolation boundary in Gestalt. A tenant typically owns
one or more Geists. (Note: today only the fixture tenant
tenant_node:rheinwerk_calibration exists; see
022 item 7.)
World snapshot
Section titled “World snapshot”The internal representation Gravity evaluates against. Carries realities, capabilities, standings, evidence, sessions, keys, and ongoing surfaces.
Membrane
Section titled “Membrane”Membrane
Section titled “Membrane”The line between Koerper (mutable) and Geist (governed). Crossed only
by intent envelopes. The HTTP API at gestalt-cloud is the membrane.
See concepts/the-membrane.md.
Open SDK boundary
Section titled “Open SDK boundary”What the SDK is allowed to do: typed request envelopes, typed response envelopes, local receipt verification, fixture simulation, proof disclosure request construction.
Closed runtime boundary
Section titled “Closed runtime boundary”What the SDK is not allowed to touch: production admission, tenant key custody, authority package activation, pendulum evaluator dispatch, proof issuance, operator audit policy.
Forbidden surface
Section titled “Forbidden surface”What no surface can ever do: raw database access, private signing keys, cross-tenant graph traversal, production package mutation, unscoped proof bundle disclosure.
Capability state (doc convention)
Section titled “Capability state (doc convention)”Every doc page describing a membrane operation labels its current state.
shape-only contract + types onlyfixture-rehearsed end-to-end fixture flow walksstaging-durable persists across restarts on stagingauthentic production-admitted (no operation today)See reference/capability-state.md.