Event-Log-Centered Modeling

batch: Batch 05

aliases:
Event-Centered Modeling
Event-Centric Modeling
Event-First Modeling
Event-Log-Centered Representation
Event-Sourced Representation
Event-Ledger Projection Modeling
Event-Centric Knowledge Modeling

related_primes: sequencing order persistent_identifier versioning collective_memory causality observability schema time transaction primary_vs_secondary_sources traceability provenance uncertainty completeness search_and_retrieval interoperability object_permanence script event_lifecycle_phases located_in_relation periodization eventual_consistency accountability transparency

slug: representation

slug: projection

slug: replay

slug: relation

slug: sequencing

slug: order

slug: versioning

slug: causality

slug: observability

slug: schema

slug: time

slug: transaction

slug: traceability

slug: provenance

slug: completeness

slug: interoperability

slug: script

slug: periodization

slug: accountability

slug: transparency

components:
Event Boundary and Type Contract
Canonical Event Record
Event Identity Key
Participant–Role Binding
Event Time and Record Time
Place and Context Binding
Transformation Delta
Event Ordering and Concurrency Rule
Entity Identity Resolution Rule
Event Log
Provenance Record
Correction and Supersession Rule
Projection Definition
Projection Frontier
Replay and Rebuild Path
Late and Out-of-Order Event Policy
Projection Reconciliation Check
Retention, Redaction, and Access Policy
Causal and Correlation Link
Uncertainty and Conflict Record
Event Completeness Statement
Source-of-Truth Reference
Timestamp or Sequence Marker
Snapshot and Compaction Policy
Cross-Layer Index

essence_one_line: Preserve happenings as the primary record and derive entity state, relationships, places, periods, timelines, and summaries as reproducible projections of the governed event log.

compression_statement: Define a valid event as a bounded happening with identity, type, participants and roles, event time, record time, place or context, transformation, provenance, and validity status; append accepted events and linked corrections to a governed canonical log; state explicit ordering and concurrency semantics; resolve entity identity without flattening uncertainty; define versioned projections for each entity, place, period, case, timeline, aggregate, or current-state view; expose each projection frontier; rebuild views through deterministic or adjudicated replay; handle duplicate, late, out-of-order, corrected, disputed, and schema-old events; reconcile projections against the log; preserve completeness limits and alternative accounts; and govern retention, redaction, access, snapshots, and compaction so convenience views never silently replace the historical substrate.

core_intuition: Static records show what is believed now but often erase how the present came to be. An event-first model reverses that priority: bounded happenings carry participants, time, place, transformation, and evidence, while entities and periods are read as trajectories through those happenings. Because derived views can be rebuilt, corrected, compared, and reinterpreted without rewriting the source history, the model supports auditability and new questions. The leverage comes with strict obligations: an event must be more than a timestamped row, order must not be mistaken for causality, missing or contested evidence must remain visible, and the event history must not become an uncontrolled surveillance archive.

canonical_formula: Let L be a governed partially ordered set of event assertions e=(event_id, type, participants×roles, valid_time, record_time, place/context, transformation, provenance, status). For projection definition Pᵥ and frontier f, view Vᵥ,f=Pᵥ(L≤f). A valid architecture preserves: reproducibility of V from L and Pᵥ; explicit ordering and uncertainty; correction lineage rather than silent overwrite; visible frontier and completeness limits; and the ability to discard and rebuild V without losing canonical history.

structural_problem: Knowledge and operational systems commonly make entities, places, periods, or current-state records primary and attach events as incidental notes. Independent updates then overwrite history, duplicate causally related facts across records, drift across views, hide how present state was produced, and make new temporal questions expensive. When sequence, participation, transformation, provenance, and correction matter, a current-state-first model cannot reliably reconstruct trajectories or distinguish what happened from what was later recorded, inferred, or revised. Yet simply collecting logs is insufficient: without event boundaries, identity, role semantics, ordering, evidence status, projection contracts, replay, completeness statements, and retention controls, the log becomes an ambiguous pile of surveillance data rather than a coherent model.

trigger_conditions: The path by which a present entity, relation, place, or state arose matters to explanation, audit, recovery, or decision making.

trigger_conditions: Multiple consumers need different current-state, historical, spatial, period, case, or aggregate views of the same underlying changes.

trigger_conditions: Independent entity-centric records are drifting, overwriting history, or requiring manual reconciliation.

trigger_conditions: Corrections, late evidence, retractions, or revised interpretations must be preserved without erasing prior record states.

trigger_conditions: Participants, roles, locations, and transformations recur across events and cannot be represented faithfully as static attributes.

trigger_conditions: Replay or retrospective reconstruction is needed after failure, schema change, new research questions, or disputed conclusions.

trigger_conditions: Temporal order is partial, source-local, uncertain, or distinct from causal order and needs explicit semantics.

trigger_conditions: The same event history must support both operational and historiographic views while retaining provenance and access boundaries.

trigger_conditions: Current-state views can be treated as derived and rebuildable rather than independently authoritative.

trigger_conditions: There is enough event evidence to justify an event model and a plan for documenting what remains unobserved.

symptoms: A current record can state an entity status but cannot explain which accepted changes produced it.

symptoms: Different teams maintain separate timelines, entity histories, and place records that disagree after updates.

symptoms: Corrections silently replace values, making it impossible to reproduce what was known at an earlier decision time.

symptoms: Late or duplicate events create unexplained state jumps, double counting, or non-repeatable analytics.

symptoms: A new historical or operational question requires redesigning the canonical schema rather than defining another projection.

symptoms: A timeline lists dates but omits participant roles, place context, transformation, evidence, or uncertainty.

symptoms: Modern entity or place categories are projected backward as if they had always existed unchanged.

symptoms: Process analysis sees only logged activity and treats missing or informal work as non-existent.

symptoms: Snapshots, caches, or read models are patched manually and become undeclared second sources of truth.

symptoms: Narratives infer causation from event sequence without preserving competing explanations or source confidence.

root_tension: Current-state and entity-centric models are convenient for immediate queries, while faithful explanation, correction, and recombination require preserving the generative event history. The archetype resolves the tension by making events canonical and current views derived, but must control the resulting complexity, privacy, uncertainty, and replay obligations.

anti_signatures: The subject is genuinely static and no meaningful sequence, transformation, correction, or replay question exists.

anti_signatures: Direct measurement of current state is authoritative and historical reconstruction would add cost without decision value.

anti_signatures: The phenomenon is fundamentally continuous at the required resolution and forcing discrete event boundaries would create severe aliasing or false transitions.

anti_signatures: Events cannot be captured with enough identity, time, participant, context, or transformation evidence to support reliable projections.

anti_signatures: A simple audit trail, version history, timeline, or one-off incident record satisfies the need without making events canonical.

anti_signatures: Retention of event detail would create unacceptable safety, surveillance, legal, or consent harms that cannot be reduced through minimization and access controls.

anti_signatures: The real problem is inconsistent replicas, data corruption, narrative framing, or periodization and does not require event primacy.

anti_signatures: Derived views must be directly and independently editable, making a single event source inappropriate without a conflict architecture.

structural_intervention: Replace independently mutable entity, place, period, and state records with a governed event substrate. Capture bounded event assertions with explicit roles, dual time, context, transformation, provenance, and status; append rather than silently overwrite; define ordering and identity rules; make each consumer view a versioned projection with a visible frontier; support replay, correction, reconciliation, uncertainty, completeness limits, and controlled retention; and treat snapshots, indexes, timelines, and read models as derived acceleration or interpretation layers.

action_logic: State the decisions, explanations, histories, recoveries, and views that require an event-centered source rather than a current-state table.

action_logic: Define event boundaries, event types, minimum evidence, granularity, and distinctions among occurrence, report, inference, correction, and adjudication.

action_logic: Assign stable event identities and persistent participant references while preserving unresolved identity, merge, split, and successor cases.

action_logic: Capture participant roles, event time, record time, place or context, transformation delta, provenance, validity status, and uncertainty.

action_logic: Establish the canonical event log, source-of-truth scope, append authority, validation gate, access boundary, and integrity checks.

action_logic: Declare total, partial, causal, source-local, and computational ordering relations separately; define concurrency and tie-breaking behavior.

action_logic: Reject or quarantine malformed and duplicate records, and use idempotent acceptance so retry or replay does not multiply effects.

action_logic: Correct through linked supersession, retraction, compensation, or adjudication records; preserve prior knowledge states unless a governed exception requires redaction.

action_logic: Define each entity, place, period, case, timeline, aggregate, or current-state projection with inputs, projector version, order semantics, output contract, and uncertainty behavior.

action_logic: Expose projection frontiers, lag, source coverage, unresolved conflicts, and completeness limits to consumers.

action_logic: Provide deterministic or explicitly adjudicated replay and rebuild paths, including schema upcasting, snapshots, and validation against known invariants.

action_logic: Handle late and out-of-order events by scoped reorder, rebuild, notification, or decision-time freezing rather than silent insertion.

action_logic: Reconcile live projections against canonical history and repair or rebuild drifted views instead of patching them as independent truth.

action_logic: Govern retention, minimization, redaction, differential access, archival preservation, snapshotting, compaction, and retirement across canonical and derived forms.

action_logic: Audit who and what is absent from the event record, test for schema-bounded blind spots, and revise event and projection models without rewriting historical evidence.

decision_rules: Call a record an event only when it represents a bounded happening or event assertion with identifiable participants, temporal semantics, context, and a transformation or evidentiary claim.

decision_rules: Use partial order or interval uncertainty when evidence does not support one total chronology; computational tie-breaks must not masquerade as historical fact.

decision_rules: Do not infer causality from sequence alone; causal links require separate evidence and relation types.

decision_rules: Treat projections as derived and replaceable. Direct mutation is allowed only through an explicit writable-projection exception that emits canonical events or reconciliation records.

decision_rules: A projection must declare its event types, filters, role semantics, projector version, frontier, and treatment of disputed or missing events.

decision_rules: Use append-only correction by default; destructive removal requires a documented legal, privacy, or safety basis and propagated redaction evidence.

decision_rules: Snapshots and compaction may accelerate replay but cannot silently become the sole authority or erase the declared reconstruction horizon.

decision_rules: When late events change consequential historical or operational views, rebuild affected projections and notify dependent decisions according to a stated materiality rule.

decision_rules: Preserve competing event assertions when evidence does not justify collapse; project according to declared evidence or adjudication policies.

decision_rules: Minimize event detail and access by purpose. Event-centered modeling is not a license to collect every observable action indefinitely.

decision_rules: Prefer a simpler versioned record or traceability link when event primacy and replayable projection do not materially improve the problem.

target_invariants: Every canonical event or event assertion has stable identity, type, provenance, validity status, and explicit temporal semantics.

target_invariants: Participant roles, place or context, and transformation are represented rather than hidden in free text or inferred from record location.

target_invariants: Given the same canonical history, order semantics, and projector version, a deterministic projection rebuilds the same result.

target_invariants: Corrections and reinterpretations preserve lineage to prior records and prior knowledge states.

target_invariants: No derived view silently becomes an independently authoritative source of truth.

target_invariants: Projection frontier, lag, unresolved conflicts, and coverage limits remain visible to users and downstream systems.

target_invariants: Late, duplicate, concurrent, and out-of-order events are handled through declared rules rather than ad hoc patches.

target_invariants: Event sequence is not presented as causation without separate evidence.

target_invariants: Identity merges, splits, successors, and unresolved matches remain auditable and reversible where feasible.

target_invariants: Retention, redaction, access, and deletion policies propagate to derived projections and indexes.

target_invariants: Snapshots and compaction preserve the declared replay and evidentiary horizon or disclose the loss budget.

target_invariants: Absence from the event log is not interpreted as absence from reality without an explicit completeness claim.

expected_outcomes: Current state and historical trajectories can be explained and rebuilt from accepted event history.

expected_outcomes: Entity, place, period, case, and aggregate views remain consistent with a common historical substrate.

expected_outcomes: New questions can be answered through new projections without rewriting canonical history.

expected_outcomes: Corrections, late evidence, and revised interpretations remain reproducible and auditable.

expected_outcomes: Projection drift and replay defects become detectable through rebuild and reconciliation.

expected_outcomes: Historical, operational, and analytical views can coexist without pretending they are the same interpretation.

expected_outcomes: Identity, chronology, provenance, and uncertainty become explicit rather than scattered across records.

expected_outcomes: Recovery from corruption or schema change improves because views are rebuildable.

expected_outcomes: Privacy, access, retention, and archival decisions become enforceable across source and projection layers.

expected_outcomes: The model exposes blind spots and missing event classes instead of hiding them behind complete-looking entity records.

prose_tradeoffs:
- Historical fidelity and replayability increase storage, schema, and operational complexity compared with direct current-state updates.
- One canonical event substrate supports many projections but shifts complexity into event design, identity resolution, ordering, projector governance, and rebuild operations.
- Append-only correction improves auditability but can make simple facts harder to read and can preserve harmful or sensitive history longer than necessary.
- Partial ordering is epistemically honest but makes some queries, summaries, and operational decisions harder than a convenient total order.
- Rich provenance and uncertainty improve interpretation but increase capture burden and can slow ingestion.
- Derived views reduce duplication of authority but introduce projection lag and eventual-consistency behavior.
- Fine event granularity supports new analysis but creates event explosion, privacy exposure, and high replay cost; coarse events hide important transformations.
- Snapshots and compaction improve performance but reduce the reconstructable horizon unless loss is explicitly governed.
- Stable event schemas aid replay, while evolving concepts and historical interpretations require versioning and upcasting.
- Centralized event authority simplifies consistency but can concentrate surveillance, governance power, and exclusionary schema choices.

Operational Event Sourcing

short_definition: Use a governed event history as the operational source of truth and rebuild current state and query views by replaying versioned projectors.

distinctive_feature: The event ledger drives live operational state rather than serving only as a historical research record.

distinct_from_parent: The parent is domain-general and can model historical or evidentiary events; this subtype adds command acceptance, operational consistency, failure recovery, and service-level projection concerns.

still_same_parent_because: Events remain canonical, state remains derived, and replay plus projection versioning remain the core architecture.

use_when: Current state must be explainable from a durable sequence of accepted changes.

use_when: Multiple read models or services need different projections of the same operational history.

use_when: Correction, retry, replay, and auditability matter more than minimizing write-path complexity.

domain: commerce

example: Order state is rebuilt from accepted, paid, allocated, shipped, returned, and refunded events.

domain: workflow

example: A case-management service derives queues and status views from a common event stream.

failure_modes: Non-deterministic projectors make replay disagree with live state.

failure_modes: Operational teams treat snapshots as authority and lose correction lineage.

Historical Event Graph

short_definition: Represent people, objects, places, institutions, and periods through their typed participation in evidence-linked historical events.

distinctive_feature: Events serve as the integration hub for historical entities and evidence, with trajectories and periods derived from event participation.

distinct_from_parent: This subtype emphasizes archival evidence, contested accounts, approximate dates, and historiographic interpretation.

still_same_parent_because: It preserves the parent event core, role bindings, temporal anchors, transformations, projections, and correction lineage.

use_when: The same actors, objects, or places appear across many changing contexts.

use_when: Researchers need to reconstruct trajectories without forcing one static entity record to carry all temporal meaning.

use_when: Conflicting sources and uncertain dates must remain visible rather than silently harmonized.

domain: prosopography

example: A person is reconstructed from offices held, letters sent, trials, migrations, and affiliations.

example: An artifact history is projected from creation, transfer, exhibition, damage, and restoration events.

failure_modes: Recorded events are treated as complete history.

failure_modes: Sequence is mistaken for causation or moral responsibility.

Bitemporal Event Model

short_definition: Track both when an event is understood to have occurred and when the record became known, valid, corrected, or superseded.

distinctive_feature: Every event carries two temporal axes and projection queries declare which axis governs the result.

distinct_from_parent: The parent requires explicit temporal semantics; this subtype makes dual time mandatory and query-visible.

still_same_parent_because: Canonical events and reproducible projections remain the governing model.

use_when: Events arrive late, are corrected retrospectively, or have uncertain occurrence intervals.

use_when: Users must reproduce what was believed at an earlier decision time as well as what is believed now.

use_when: Regulatory, scientific, or historical questions require valid-time and record-time separation.

domain: legal

example: A judgment effective date differs from the date the record was entered or corrected.

domain: clinical

example: An exposure occurred earlier but was reported and validated only after a later diagnosis.

failure_modes: Valid time and record time are collapsed into one timestamp.

failure_modes: Corrections rewrite prior knowledge instead of preserving decision-time reproducibility.

Process-Trace Event Model

short_definition: Model work or behavior as case-linked event traces so actual paths, waits, loops, handoffs, and deviations can be reconstructed.

distinctive_feature: A case or episode projection organizes events into executable traces for conformance and process analysis.

distinct_from_parent: The parent can support arbitrary event graphs; this subtype emphasizes cases, activities, handoffs, and process conformance.

still_same_parent_because: Case state and process paths are projections from canonical events rather than independently maintained truth.

use_when: Formal workflow descriptions differ from observed execution.

use_when: Cases can be correlated across event records without unacceptable privacy or identity error.

use_when: Bottlenecks, variants, loops, and conformance must be analyzed from actual traces.

example: A care pathway is reconstructed from referral, test, treatment, handoff, and discharge events.

domain: administration

example: Permit cases are analyzed through submission, review, request, revision, approval, and appeal events.

failure_modes: Event correlation joins different cases.

failure_modes: Recorded activity is mistaken for all work, excluding informal or unlogged labor.

Evidence-Weighted Contested Event Model

short_definition: Retain competing event assertions, source provenance, confidence, and adjudication status instead of forcing one premature canonical account.

distinctive_feature: The canonical layer can hold multiple claims about an event and projects views according to declared evidence or adjudication policies.

distinct_from_parent: The parent can operate with accepted events; this subtype makes claim plurality and evidence status structurally mandatory.

still_same_parent_because: The unit of organization remains the event and all views are still governed projections of event assertions.

use_when: Sources disagree about whether, when, where, or how an event occurred.

use_when: The cost of erasing minority or later-vindicated accounts is high.

use_when: Users must distinguish observed, reported, inferred, disputed, and adjudicated events.

domain: investigation

example: Witness accounts remain separate event assertions until corroboration or adjudication changes their status.

domain: history

example: A disputed meeting is represented with competing dates, participants, and source confidence.

failure_modes: Confidence scores conceal value judgments or source power.

failure_modes: Adjudication status is presented as metaphysical certainty.

Spatial Event Atlas

short_definition: Derive the changing meaning, occupancy, use, and boundaries of places from the events that occurred or were attributed there.

distinctive_feature: Place records are temporal projections of event participation rather than static containers with events attached.

distinct_from_parent: The parent treats place as one event role; this subtype makes spatial transformation and boundary change central.

still_same_parent_because: Event records remain canonical and place views remain rebuildable projections.

use_when: Places change identity, jurisdiction, occupancy, or meaning over time.

use_when: Spatial and temporal questions must be answered together.

use_when: Users need to see multiple event layers without treating modern boundaries as timeless.

example: A district is projected from annexations, demolitions, migrations, businesses, protests, and planning decisions.

domain: archaeology

example: A site view is assembled from occupation, construction, deposition, disturbance, and excavation events.

failure_modes: Modern place identifiers are back-projected into periods when boundaries differed.

failure_modes: Approximate locations are displayed as precise points.

near_names:
Event-Centered Modeling
Event-Centric Modeling
Event-First Modeling
Event-Log-Centered Representation
Event-Sourced Modeling
Event-Graph Modeling
Activity-Centered Modeling


Event–Narration Order Decoupling

type: archetype

source: generated

batch: Batch 09

aliases: event-order / presentation-order separation

alias_records: event-order / presentation-order separation

source_primes: fabula_and_syuzhet order representation framing

related_primes: geometric_chronology cross_cutting_relationship interpretation memoing unreliable_narrator replay time causality continuity_vs_rupture traceability perspective deixis periodization observability data_integrity versioning emphasis collective_memory

slug: representation

slug: framing

slug: interpretation

slug: memoing

slug: replay

slug: perspective

slug: deixis

slug: emphasis

components:
Event Chronology Map
Narration Sequence Map
Event-to-Discourse Mapping
Disclosure Objective
Reader or User Knowledge-State Model
Temporal Anchor System
Causality and Dependency Guard
Withholding and Omission Register
Orientation and Reentry Cues
Fidelity Audit Checkpoint
Evidence Discovery-Order Record
Parallel Timeline Visualization
Multi-Perspective Thread Map
Uncertainty Annotation Layer
Revision Crosswalk Control

essence_one_line: Separate what happened when from the order in which it is shown, told, taught, or argued, then keep the two orders explicitly mapped so presentation can be optimized without corrupting chronology.

compression_statement: Event–Narration Order Decoupling applies when an underlying sequence of events, causes, discoveries, states, or decisions must be presented in an order that differs from the chronology in which those events occurred. The intervention preserves a stable event-order map, designs a separate presentation-order sequence for the audience or decision need, links every presented unit back to its chronological location, marks jumps and withheld context, and tests whether the final presentation preserves recoverable chronology, causal dependency, and evidentiary fidelity.

core_intuition: A good account often does not begin at the beginning. But once the telling order drifts away from event order, readers can mistake reveal order for cause, discovery order for occurrence, or argument order for chronology. The solution is not to force everything into chronological order; it is to treat chronology and narration as two linked artifacts with different jobs.

canonical_formula: Dual-order design = event chronology E + presentation sequence P + crosswalk M(E↔P) + disclosure rationale R + temporal anchors A + fidelity guards G.

structural_problem: A case, story, report, explanation, investigation, curriculum, interface, or record contains events whose chronological order is not the best order for presentation. When event order and narration order are not explicitly separated, the presentation can accidentally rewrite the underlying chronology, manufacture false causality, hide omitted context, overstate discovery order, or leave the audience unable to reconstruct what happened. Conversely, forcing presentation to follow chronology can bury the question, overload the audience, weaken explanation, or prevent useful staged disclosure.

trigger_conditions: The underlying event chronology differs from the order in which users, readers, learners, investigators, or decision-makers should encounter material.

trigger_conditions: The account uses flashbacks, reverse chronology, nested testimony, staged evidence, reveals, argument-first reporting, or outcome-first explanation.

trigger_conditions: A report must distinguish event order, discovery order, evidence order, argument order, and publication order.

trigger_conditions: The audience needs orientation, suspense, diagnostic focus, explanation, or pedagogy that strict chronology would not provide.

trigger_conditions: Temporal jumps, omitted intervals, retrospective reinterpretation, or multiple timelines could distort perceived causality or responsibility.

trigger_conditions: The same material must support both an engaging presentation and an auditable chronology.

trigger_conditions: Stakeholders may use presentation order strategically to frame blame, innocence, inevitability, novelty, or importance.

symptoms: Readers remember the order of disclosure as the order of occurrence.

symptoms: A report begins with the conclusion but does not provide a neutral chronology or cross-reference back to event order.

symptoms: Flashbacks, sidebars, testimony, or analytic sections create confusion about when events happened.

symptoms: Cause appears to follow effect because the presentation sequence was chosen for suspense or persuasion.

symptoms: Important context is withheld for dramatic or argumentative effect without being labeled as withheld context.

symptoms: Different teams keep separate timelines that cannot be reconciled: event chronology, evidence discovery, publication sequence, and decision timeline.

symptoms: An audience understands the narrative arc but cannot reconstruct the actual temporal dependencies.

symptoms: A curriculum, onboarding flow, or exhibit teaches concepts out of chronology but never helps learners reassemble the original sequence.

root_tension: Truthful chronology and effective presentation are both legitimate objectives, but they optimize for different things. Chronology protects causal and evidentiary order; narration order protects comprehension, emphasis, pacing, disclosure, and actionability. Trouble begins when the two orders are treated as one artifact.

anti_signatures: There is only one required ordering rule and no separate presentation order; use canonical_ordering or ordinary sequencing.

anti_signatures: The main task is reconstructing event order from layered physical or archival traces; use stratigraphic_time_ordering_inference.

anti_signatures: The main task is auditing which events, actors, causes, or omissions a story selected; use narrative_construction_audit.

anti_signatures: The main task is checking consistency of a sweeping explanatory story; use metanarrative_coherence_and_internal_consistency_check.

anti_signatures: The main task is guiding visual attention through a diagram or interface with no event chronology at stake; use visual_flow_guidance.

anti_signatures: The main task is preserving late, reconstructed, or backfilled evidence layers; use capture_latency_evidence_stratification.

anti_signatures: The account is purely fictional or playful and no one needs to recover event order, causal order, or evidence status.

structural_intervention: Create a dual-order account: preserve the underlying event chronology as one artifact, design the narration or presentation sequence as another, maintain an explicit crosswalk between them, and install temporal anchors, disclosure rules, and fidelity checks so the audience can benefit from the chosen presentation order without confusing it for event order.

action_logic: Define the event units, state transitions, decisions, evidence items, scenes, or process steps that belong in the underlying chronology.

action_logic: Build a stable event chronology with known timestamps, relative order, uncertainty, causal dependencies, and unresolved gaps.

action_logic: Define the presentation objective: suspense, comprehension, diagnosis, persuasion, onboarding, legal argument, learning progression, or decision support.

action_logic: Design the narration sequence independently, deciding what the audience should encounter first, what can be delayed, what must be repeated, and where reorientation is needed.

action_logic: Map every presentation unit back to its event-order location, evidence basis, and dependency relations.

action_logic: Mark temporal jumps, flashbacks, foreshadowing, summaries, sidebars, withheld context, retrospective interpretation, and reconstructed intervals.

action_logic: Add orientation cues that help readers re-enter the chronology after nonchronological moves.

action_logic: Audit causal and responsibility claims against the event chronology rather than the presentation sequence.

action_logic: Test the account with representative readers or reviewers to see whether they can reconstruct the intended chronology and identify the presentation logic.

action_logic: Maintain the dual-order crosswalk as the account changes so edits do not silently sever narration from chronology.

decision_rules: Never let presentation order imply a temporal or causal relation that the event chronology does not support.

decision_rules: Use nonchronological presentation only when it serves an explicit audience, decision, analytic, or pedagogical purpose.

decision_rules: Whenever material is withheld, delayed, or moved, decide whether the withholding is ordinary sequencing, necessary suspense, learner scaffolding, argument structure, or potentially misleading concealment.

decision_rules: If responsibility, legality, safety, science, or public trust is at stake, provide a neutral chronology or chronology appendix alongside the narrative order.

decision_rules: When event order is uncertain, mark uncertainty in the event chronology before designing the presentation order around it.

decision_rules: If discovery order differs from occurrence order, keep a separate evidence-discovery record rather than folding it into event chronology.

decision_rules: Reorient the audience after every major temporal jump, especially when multiple timelines, narrators, locations, or levels of abstraction are present.

decision_rules: If a dramatic, persuasive, or pedagogical sequence creates durable false memory of chronology, revise the sequence or strengthen anchors.

target_invariants: The underlying event chronology remains recoverable and distinguishable from narration order.

target_invariants: Causal dependencies are not reversed, hidden, or invented by presentation order.

target_invariants: Every presentation unit can be traced to an event unit, evidence unit, interpretation, or explicitly fictionalized construction.

target_invariants: Temporal jumps and withheld context are marked enough for the intended use and stakes.

target_invariants: Audience orientation is preserved across flashbacks, summaries, nested frames, and argument sections.

target_invariants: Event order, discovery order, argument order, and publication order remain separable when their differences matter.

target_invariants: The presentation objective is documented so reorderings can be reviewed instead of treated as accidental style.

target_invariants: Late revisions update both the chronology and the presentation crosswalk.

expected_outcomes: Clearer accounts that can use nonchronological structure without sacrificing temporal fidelity.

expected_outcomes: Reduced false causality, hindsight bias, and accidental manipulation from reveal order.

expected_outcomes: Better teaching, reporting, documentation, and narrative design because presentation order can be optimized intentionally.

expected_outcomes: Auditable timelines that support accountability even when the public-facing account is organized by theme or argument.

expected_outcomes: Improved reader or user orientation in complex multi-timeline material.

expected_outcomes: More resilient revisions because edits can be checked against both event chronology and presentation sequence.

prose_tradeoffs: Nonchronological presentation can improve comprehension, suspense, or actionability, but it increases orientation burden. Chronology appendices and crosswalks improve auditability, but they add maintenance cost and can slow reading. Staged disclosure can be powerful, but in high-stakes contexts it can become manipulation. Strong temporal anchors protect fidelity, but they can reduce mystery, pacing, or rhetorical force.

Nonchronological Reveal Design

short_definition: A presentation intentionally departs from event chronology so suspense, explanation, diagnosis, or comprehension improves while the underlying chronology remains recoverable.

distinctive_feature: The presentation sequence is intentionally optimized separately from event order rather than accidentally drifting away from it.

distinct_from_parent: This is the most direct narrative-design subtype of the parent pattern, emphasizing reveal and withholding rather than general two-order governance.

still_same_parent_because: It still relies on an explicit event chronology, presentation sequence, mapping layer, and fidelity guard.

source_primes: fabula_and_syuzhet order framing

use_when: A strict chronological account would bury the question, motive, constraint, or contrast that the audience needs first.

use_when: The designer wants to use flashback, foreshadowing, reverse chronology, nested testimony, or staged disclosure.

use_when: The intervention must preserve the actual event chronology even while encounter order is rearranged.

example: A film opens with the aftermath, then reconstructs earlier causes through flashbacks while preserving a recoverable event chronology.

example: A postmortem begins with impact and decision points, then backtracks to causal setup without confusing report order with event order.

failure_modes: The reveal sequence becomes so compelling that readers infer a false chronology or causal chain.

Investigative Chronology–Argument Split

short_definition: An investigation maintains a factual chronology separately from the order in which evidence, claims, and conclusions are presented.

distinctive_feature: It separates event order, discovery order, and argument order for evidentiary use.

distinct_from_parent: The parent is cross-domain; this variant focuses on investigations and accountability records.

still_same_parent_because: The same dual-order mapping and fidelity constraints govern the work.

use_when: A report, brief, audit, or inquiry must persuade or orient readers without misrepresenting what happened when.

use_when: Evidence was discovered in a different order than events occurred.

use_when: The audience needs both an argument path and a fact chronology.

domain: law

example: A legal brief presents facts in issue order while attaching a neutral chronology so argument order does not masquerade as event order.

failure_modes: Argument order can create implied causality that the event chronology does not support.

Pedagogical Order Resequencing

short_definition: A complex history, process, or argument is taught in an order optimized for learner readiness while preserving the underlying temporal or causal sequence.

distinctive_feature: The presentation order is optimized for scaffolding rather than suspense, argument, or evidence.

distinct_from_parent: The parent handles any event/presentation order split; this variant emphasizes learner state and prerequisite comprehension.

still_same_parent_because: It still needs recoverable event order, mapping, reentry cues, and fidelity checks.

source_primes: fabula_and_syuzhet interpretation order

use_when: Chronological order is not the best learning order.

use_when: Learners need a conceptual hook, outcome, or simple case before the original sequence makes sense.

use_when: The instructor must distinguish learning order from historical or process order.

domain: education

example: A course explains the outcome of a historical process first, then walks backward through prerequisites before returning to chronological order.

failure_modes: Learners remember the teaching order as the event order.

near_names: Event-Order / Presentation-Order Separation


Event-Rate Magnitude Encoding

batch: Batch 03

canonical_family: Channels, Coding & Transmission

slug: measurement

slug: latency

slug: aliasing

slug: distortion

slug: channel

slug: discreteness

slug: intermittency

slug: threshold

components:
Source Magnitude Definition
Stereotyped Event Unit
Event Generator Mapping
Observation Window
Rate Decoder
Calibration Curve
Latency-Precision Tradeoff Rule
Noise and Baseline Model
Dynamic Range and Saturation Bound
Aliasing and Distortion Guard
Reset or Leak Rule
Population or Channel Pool
Adaptive Window Controller
Burst Annotation
Denominator or Exposure Register
Confidence Band

mechanisms:
Fixed-Window Event Count
Rolling-Window Rate Estimator
Exponential Leaky Integrator
Spike-Rate Readout
Pulse-Density Modulation
Poisson Rate Model
Adaptive Window Widening
Rate Saturation Clamp
Inter-Event Interval Estimator
Anti-Aliasing Bin Selection

essence_one_line: Encode intensity as event frequency and decode it by counting or integrating over a calibrated window rather than by inspecting any single event.

compression_statement: Event-Rate Magnitude Encoding is used when individual events are stereotyped, cheap, discrete, or indistinguishable, but their density over time can carry a graded signal. A source magnitude modulates event frequency; a receiver estimates the magnitude by counting, smoothing, or integrating events over a window. The design problem is to choose the event unit, rate mapping, integration window, calibration curve, noise model, and saturation bounds so the decoded estimate is timely enough to act on and precise enough to trust.

core_intuition: A single tick may say only that something happened. A stream of ticks can say how much, how urgent, how strong, or how likely. The more time the receiver spends counting, the more stable the estimate becomes, but the later the estimate arrives. This archetype makes that tradeoff explicit instead of treating event frequency as a self-explanatory signal.

canonical_formula: source_magnitude m(t) -> event_generator rate lambda(t)=f(m(t)); decoder estimates m_hat(t)=g(count_or_integral(events, window W)); choose W to balance variance and latency

structural_problem: A system needs to convey or infer a continuous, graded, or probabilistic state, but the available carrier is a sequence of discrete, similar events. Without an explicit rate code, observers overreact to isolated events, miss slow changes, confuse noise bursts with magnitude shifts, or choose windows that are too short for precision or too long for timely response.

trigger_conditions: The underlying quantity is continuous, graded, probabilistic, or too fine-grained to send as a single categorical event.

trigger_conditions: The available event unit is stereotyped: a spike, pulse, click, request, alarm, visit, complaint, vote, occurrence, or token whose identity alone carries little magnitude information.

trigger_conditions: The receiver can observe event timing or count but may not have direct access to the source magnitude.

trigger_conditions: Noise, intermittency, or stochastic arrival patterns make any single event unreliable.

trigger_conditions: The receiver must trade fast reaction against confidence gained by accumulating more events.

trigger_conditions: The code may saturate when events arrive too quickly or become invisible when events arrive too rarely.

symptoms: Operators chase single events as if each event were a magnitude measurement.

symptoms: Dashboards show counts without specifying the window, baseline, denominator, or latency of the implied rate.

symptoms: Short windows produce jittery estimates, while long windows hide sudden changes.

symptoms: Bursts are misread as sustained intensity because the decoder has no decay or reset rule.

symptoms: A system reaches a maximum event rate, so larger source magnitudes become indistinguishable.

symptoms: Different teams compute different rates from the same event stream because their bins, smoothing rules, or clocks differ.

symptoms: Low-rate signals are ignored even when accumulated evidence would be meaningful.

symptoms: Event-rate comparisons are made across contexts with different exposure, capacity, or observation windows.

root_tension: The carrier gains robustness and simplicity by using repeated discrete events, while the receiver needs a stable estimate of a graded state. Precision improves by waiting and integrating; actionability improves by deciding sooner.

anti_signatures: The event identity, symbol, payload, or category carries the magnitude directly; Round-Trip Code Alignment or Symbolic Convention Governance may be primary.

anti_signatures: The main question is how often to sample an external process, not how to encode magnitude as event frequency; Temporal Resolution and Sampling Rate Design is primary.

anti_signatures: The design only needs a threshold that fires once a value crosses a boundary; Threshold-Based Activation is primary.

anti_signatures: The main problem is selecting a channel with adequate modality, bandwidth, or noise tolerance; Channel-Fit Design is primary.

anti_signatures: The signal is intentionally represented by a joint spatial pattern across many units rather than a rate through time; Population Coding may be primary.

anti_signatures: The task is retrospective accounting of event totals with no claim that rate represents an underlying magnitude.

structural_intervention: Specify the rate code as a complete encode-decode loop: define the source magnitude, choose a stereotyped event unit, map magnitude to event rate, choose an integration window and decoder, calibrate the recovered estimate, and add guards for noise, burstiness, latency, aliasing, saturation, and context shifts.

action_logic: Name the source magnitude and the decisions that will use the decoded estimate.

action_logic: Define the discrete event unit and ensure repeated events are comparable enough for rate to carry meaning.

action_logic: Choose a mapping from magnitude to event rate, including baseline, dynamic range, nonlinear transforms, and saturation limits.

action_logic: Select a counting or integration window that balances precision, latency, and expected change rate.

action_logic: Calibrate the decoder so a count, frequency, smoothed value, or inter-event interval maps back to an interpretable magnitude estimate.

action_logic: Model expected noise, stochastic arrival patterns, dropped events, bursts, clock drift, and observation gaps.

action_logic: Add aliasing and distortion checks so changes faster than the window can resolve are not misread as stable magnitude.

action_logic: Define reset, leak, or decay behavior so old events stop contributing when they no longer represent current state.

action_logic: Test the code against low-rate, high-rate, bursty, saturated, delayed, and missing-event conditions.

action_logic: Expose the window, baseline, confidence, and latency of each decoded rate estimate to downstream users.

decision_rules: Use a shorter window when response latency matters more than estimate stability and the event rate is high enough to support it.

decision_rules: Use a longer or adaptive window when events are sparse, stochastic, or safety decisions require higher confidence.

decision_rules: Do not compare rates unless the event definition, denominator, observation window, and baseline are equivalent or normalized.

decision_rules: Declare saturation when additional source magnitude no longer increases observable event rate.

decision_rules: Treat bursts separately when they may reflect synchronization, batch release, or backlog clearing rather than sustained source intensity.

decision_rules: Flag estimates as stale when the integration window includes conditions no longer true of the source process.

target_invariants: safe behavior under missing, bursty, or delayed events

expected_outcomes: A graded source state becomes recoverable from a sequence of simple events.

expected_outcomes: Receivers can tune the latency-precision tradeoff rather than inheriting it accidentally.

expected_outcomes: False urgency from isolated events and false calm from oversmoothing both decrease.

expected_outcomes: Rate comparisons become more auditable because windows, denominators, and calibration are explicit.

expected_outcomes: Saturation, aliasing, and burst artifacts become observable failure states rather than hidden interpretation errors.

prose_tradeoffs: Event-rate codes are simple and robust, but they can be slow, noisy, bandwidth-consuming, or easy to manipulate. More events improve precision but consume capacity. More smoothing improves stability but delays detection. More normalization improves comparability but may obscure absolute burden. The design must choose these tradeoffs rather than inherit them accidentally.

Spike-Rate Coding

short_definition: A neural or neural-like variant where stimulus or state intensity is represented by spikes per unit time.

distinctive_feature: The event source may have refractory periods, baseline firing, and stochastic spike timing.

distinct_from_parent: It adds neural constraints to the general event-rate code.

still_same_parent_because: The core representation remains magnitude-as-event-frequency with windowed decoding.

use_when: The carrier events are spikes or spike-like pulses.

use_when: The receiver estimates intensity by spike count, firing rate, or smoothed spike train.

domain: neuroscience

example: Estimate stimulus intensity from spikes per 100 ms response window.

Pulse-Density Encoding

short_definition: An engineering variant where an analog or graded value is represented by the density of pulses in a discrete stream.

distinctive_feature: The event density is often deliberately generated by modulation hardware or software.

distinct_from_parent: The parent includes organic, social, operational, and measurement streams as well as engineered pulse streams.

still_same_parent_because: The encode/decode logic is still event-rate magnitude recovery.

use_when: A binary or pulse stream must carry a graded value.

use_when: Filtering or integration can recover the value over a window.

example: Recover an analog level from the density of pulses after low-pass filtering.

Rolling Operational Rate Signal

short_definition: A monitoring variant where repeated operational events per window represent load, risk, failure intensity, or demand.

distinctive_feature: The events are often socially or procedurally generated, making denominators and reporting lag central.

distinct_from_parent: The parent includes physical and neural event streams; this variant emphasizes organizational measurement artifacts.

still_same_parent_because: The signal is still decoded from event frequency over a window.

use_when: Operational events such as tickets, errors, incidents, visits, or complaints are used to infer a latent process state.

use_when: Window choice affects response timing and false alarm rate.

example: Use rolling errors per minute to estimate service degradation intensity.

Adaptive-Window Rate Coding

short_definition: A variant that changes the integration window to keep uncertainty, latency, or action risk within bounds.

distinctive_feature: The decoder window is a controlled parameter rather than a fixed bin.

distinct_from_parent: The parent can use fixed windows; this variant centers adaptive window selection.

still_same_parent_because: It preserves the same event-rate magnitude code and decoder structure.

use_when: The receiver must respond quickly at high rates but accumulate longer evidence at low rates.

example: Extend the counting window when rare events make the current risk estimate too uncertain.

near_names:
Rate Coding
Firing Rate Code
Event-Rate Code
Pulse-Frequency Code
Frequency as Intensity


Event-Script Structuring

batch: Batch 10

canonical_family: Ordering, Sequencing & Dependency

source_primes: script schema sequencing representation role pattern_recognition

slug: script

slug: schema

slug: sequencing

slug: role

slug: compellence

slug: context

slug: sensemaking

slug: narrative

slug: ritual

slug: habit

slug: order

slug: causality

slug: boundary

slug: observability

slug: feedback

slug: classification

slug: abstraction

essence_one_line: Encode a familiar situation as an expected role-and-event sequence so people or systems can recognize the situation, know what normally comes next, and notice meaningful deviations.

compression_statement: Event-Script Structuring applies when a recurring encounter is too context-dependent to be governed by a flat checklist but too familiar to treat as a novel case each time. The intervention defines the situation class, its entry cues, roles, props, preconditions, typical event order, causal links, optional branches, completion signals, and breach conditions. This script becomes a compact interpretive model: it helps agents recognize the scenario, fill missing expectations, coordinate roles, guide memory and attention, and revise the model when actual encounters repeatedly violate the expected sequence.

core_intuition: A familiar situation is understood through a story-shaped template, not just isolated facts. When the template is explicit, participants can coordinate without reinventing the situation every time, but they can also see when the template is misleading, culturally narrow, unsafe, or out of date.

canonical_formula: script_fit = match(entry_cues, roles, props, event_order, causal_links, completion_signal) - breach_cost - stereotype_or_overgeneralization_cost; apply only while fit exceeds a review threshold.

structural_problem: A person, team, interface, institution, or automated system must interpret a recurring situation but lacks a shared event-sequence model. Participants know fragments of roles, cues, tools, and expected steps, yet the whole situation is tacit, inconsistent, or overgeneralized. As a result, they misread cues, skip expected events, fail to notice breaches, or impose the wrong familiar pattern on a new case.

trigger_conditions: The same kind of encounter recurs often enough that participants expect a recognizable beginning, middle, and end.

trigger_conditions: Correct action depends on roles, props, cues, conditions, and event order rather than one isolated rule.

trigger_conditions: A newcomer, user, learner, model, or cross-functional partner must learn how the situation normally unfolds.

trigger_conditions: Failures arise because people notice the same facts but interpret them through different tacit expectations.

trigger_conditions: Safety, fairness, service quality, or coordination requires knowing when the ordinary script has been breached.

trigger_conditions: The organization wants to preserve useful situated knowledge without freezing it into an inflexible procedure.

trigger_conditions: A familiar situation has domain, culture, or context variants that need explicit scope boundaries.

symptoms: Participants ask “what is supposed to happen next?” even though the overall situation is familiar.

symptoms: Role confusion occurs because actors know their tasks but not how those tasks fit the encounter sequence.

symptoms: Important anomalies are missed because there is no explicit expectation against which to register a breach.

symptoms: People overapply a familiar pattern to cases where entry cues are superficial or incomplete.

symptoms: Training relies on shadowing or folklore because the sequence, roles, props, and exception conditions are tacit.

symptoms: Interfaces, forms, or playbooks collect the right facts but fail to support situation-level interpretation.

symptoms: Different departments or cultures use incompatible assumptions about the same recurring encounter.

root_tension: Scripts compress experience by assuming familiar event order and roles, but the same compression can produce blindness, stereotype, premature closure, and brittle response when a case departs from the expected pattern.

anti_signatures: The main task is simply putting independent steps in prerequisite order; use Dependency Ordering instead.

anti_signatures: The main task is moving work through formal approval stages with criteria; use Stage-Gate Progression instead.

anti_signatures: The main task is sequencing cognitive tasks to manage learner load; use Cognitive Workflow Sequencing instead.

anti_signatures: The main task is revising categories after evidence no longer fits; use Schema Update Protocol instead.

anti_signatures: The main task is reconciling two different classification schemes; use Schema Conflict Resolution instead.

anti_signatures: The main task is changing behavioral triggers or habits; use Associative Cue Redesign instead.

anti_signatures: The main task is externalizing any mental model for shared inspection; use Cognitive Representation Externalization instead.

anti_signatures: The situation is genuinely novel, open-ended, adversarial, or emergent enough that a familiar script would create false certainty.

structural_intervention: Build and govern an explicit event script: define the situation boundary, entry cues, role slots, prop and setting requirements, expected temporal-causal event sequence, branch and exception points, completion signal, breach detectors, and update rules, then use the script for interpretation, training, coordination, interface design, or anomaly detection only within its scoped fit conditions.

action_logic: Name the recurring situation class and the practical decision the script will support.

action_logic: Specify entry cues that justify activating the script, including cues that are necessary but not sufficient.

action_logic: Map role slots, allowable role-fillers, responsibilities, permissions, and perspective differences.

action_logic: List props, records, tools, setting features, and preconditions that make the situation recognizable.

action_logic: Write the expected event sequence as temporal and causal phases, not just a flat task list.

action_logic: Mark optional branches, exception paths, culturally or domain-specific variants, and explicit stop conditions.

action_logic: Define breach signals: missing expected events, impossible role/prop combinations, timing violations, and cue conflicts.

action_logic: Attach action guidance to breach categories, including escalation, inquiry, adaptation, or script suspension.

action_logic: Test the script against representative cases, edge cases, counterexamples, and cases from affected participants.

action_logic: Publish the script in a usable medium such as a scenario card, service blueprint, training case, interface flow, or review checklist.

action_logic: Monitor real encounters and revise the script when repeated deviations show that the situation model is incomplete or biased.

decision_rules: Activate the script only when entry cues and role/prop conditions meet the stated fit threshold.

decision_rules: Treat the script as an interpretive hypothesis, not proof that a case must follow the expected sequence.

decision_rules: A breach should trigger inquiry or adaptation before blame when the script itself may be incomplete.

decision_rules: When multiple scripts fit, compare role structure, causal order, and breach evidence rather than relying on surface labels.

decision_rules: When the script affects vulnerable or low-power participants, include their perspective in breach and update rules.

decision_rules: Do not turn culturally specific scripts into universal defaults without explicit scope and exception notes.

decision_rules: Escalate to schema update or conflict resolution when repeated valid cases do not fit the script.

decision_rules: Retire or quarantine scripts that produce stereotype, premature closure, or unsafe automation.

target_invariants: The situation boundary and activation cues remain explicit.

target_invariants: Role slots are distinguished from the particular people or objects that fill them.

target_invariants: Temporal order, causal order, and optional branches are visible rather than hidden in prose.

target_invariants: Breach conditions are defined separately from moral blame or actor fault.

target_invariants: Scope, culture, domain, and context limitations are stated.

target_invariants: Users can suspend the script when fit evidence is weak or contradictory.

target_invariants: Real encounter evidence can update the script without erasing provenance.

target_invariants: The script supports interpretation and coordination without becoming a rigid stereotype.

expected_outcomes: Faster recognition of familiar situations and likely next events.

expected_outcomes: Clearer role coordination and handoff expectations.

expected_outcomes: Better onboarding, training, interface design, and case review because tacit sequence knowledge is externalized.

expected_outcomes: Earlier detection of anomalies, missing steps, unsafe deviations, or expectation conflicts.

expected_outcomes: Reduced ambiguity between ordinary variation and meaningful breach.

expected_outcomes: More accountable revision of inherited or culturally biased situation templates.

Service Encounter Script Variant

short_definition: A variant focused on recurring customer, patient, client, or citizen encounters with frontstage and backstage role expectations.

distinctive_feature: It emphasizes multi-role service choreography and handoff breaches.

distinct_from_parent: The parent covers any familiar situation; this variant focuses on service encounters.

still_same_parent_because: It still uses role slots, props, event order, and breach detection to structure interpretation.

source_primes: script role sequencing representation

use_when: A service interaction has stable phases and handoffs.

use_when: Participants need to know what normally happens next and who owns each step.

domain: healthcare

example: A clinic visit script coordinates patient arrival, intake, clinician review, discharge instructions, and follow-up triggers.

failure_modes: Treating culturally specific service expectations as universal.

failure_modes: Hiding backstage labor or patient perspective from the script.

Breach Detection Script Variant

short_definition: A variant where the script is mainly used to notice missing, impossible, mistimed, or contradictory events.

distinctive_feature: The breach detector is the dominant work product.

distinct_from_parent: The parent also supports interpretation, training, and coordination; this variant prioritizes anomaly detection.

still_same_parent_because: Breach recognition depends on the same expected role/prop/event sequence.

source_primes: script observability feedback

use_when: Anomalies reveal safety, fraud, legitimacy, or quality risk.

use_when: Ordinary variation must be separated from meaningful breach.

example: A due-process script flags missing notice, absent record, wrong authority, or skipped appeal opportunity.

failure_modes: Mistaking script incompleteness for actor failure.

Training Scenario Script Variant

short_definition: A variant that uses scripted scenario structure to teach recognition, role expectations, and next-event anticipation.

distinctive_feature: The script is packaged as a learning and rehearsal object.

distinct_from_parent: The parent includes training as one use; this variant foregrounds learning transfer.

still_same_parent_because: It teaches the same event-script structure of cues, roles, props, sequence, branches, and breaches.

source_primes: script schema mental_model

use_when: Learners must recognize recurring situations before acting.

use_when: Tacit sequence knowledge is normally acquired only by shadowing or immersion.

example: A manager learns a conflict-resolution encounter script with entry cues, role expectations, escalation branches, and closure signals.

failure_modes: Learners memorize a script without recognizing when it does not fit.

failure_modes: Training examples omit counterexamples and edge cases.

near_names:
Script
Event Script
Situation Script
Scripted Situation Model
Role-Slot Sequence Schema
Scenario Script


Eventual-Occurrence Containment Design

batch: Batch 16

canonical_family: Uncertainty, Risk & Proxy Distortion

aliases:
Eventual-Occurrence Containment
Cumulative-Exposure Containment
Repeated-Trial Hazard Containment
Nonzero-Probability Event Containment
Long-Horizon Residual-Risk Design
Assume-Eventual-Occurrence Design

source_primes: eventual_realisation_of_possibility probability statistical_independence recurrence time risk containment

slug: probability

slug: recurrence

slug: time

slug: risk

slug: containment

slug: stationarity

slug: uncertainty

slug: coupling

slug: resilience

slug: robustness

slug: controllability

slug: threshold

slug: redundancy

slug: irreversibility

components: Occurrence Detection and Escalation Signal

components: Exposure-Drift and Model-Refresh Trigger

mechanisms: Fault Tree with Repeated-Opportunity Branch

essence_one_line: When a harmful outcome retains nonzero probability across many opportunities, design as though it will occur within the relevant horizon: keep reducing risk, but also cap impact, isolate propagation, detect quickly, and prove recovery.

compression_statement: The archetype corrects per-opportunity myopia. A small residual probability can look negligible when each trial is viewed alone, yet many trials can make one or more occurrences likely, recurrent, or asymptotically almost sure. The intervention defines the event, opportunity unit, horizon, probability and dependence assumptions; estimates cumulative occurrence; selects a posture-switch threshold; and requires prevention, exposure reduction, containment boundaries, consequence caps, safe response, recovery, and model refresh as one governed system.

core_intuition: A control that makes failure rare is not the same as a proof that failure is impossible. As opportunities accumulate, the right question shifts from “Will this happen on the next trial?” to “What must be true when it eventually happens somewhere in this operating horizon?” Good design therefore keeps prevention while refusing to make prevention the only line of defense.

canonical_formula: For n independent opportunities with constant per-opportunity probability p, P(at least one occurrence) = 1 - (1 - p)^n, which approaches 1 as n approaches infinity when p > 0. For varying or dependent opportunities, use an explicit dependence model, conservative bound, simulation, or empirical frequency range; do not claim inevitability from the independent-trial formula when its assumptions fail.

structural_problem: A system is judged one opportunity at a time, so a tiny residual probability is treated as practically zero even though the number of requests, cycles, attempts, exposures, or time periods makes occurrence within the operating horizon materially likely. Preventive controls receive most design attention while blast-radius limits, isolation, detection, safe-state behavior, remedy, recovery, and recurrence control remain weak or untested.

trigger_conditions: The same adverse outcome has repeated, numerous, or open-ended opportunities to occur.

trigger_conditions: The per-opportunity probability is credibly nonzero or cannot be proven zero across the operating envelope.

trigger_conditions: The consequence of at least one occurrence is material, irreversible, systemic, or ethically significant.

trigger_conditions: Opportunity volume, asset concentration, or exposure duration is growing faster than the risk model is refreshed.

trigger_conditions: Containment, isolation, safe-state entry, recovery, or exposure reduction can materially change total harm.

trigger_conditions: A quiet history is being used as evidence that the hazard has disappeared rather than as one observation under limited exposure.

symptoms: Risk is reported only per transaction, unit, dose, request, or cycle, with no horizon-level view.

symptoms: Teams say “it has never happened” or “the chance is one in a million” without stating the number of opportunities.

symptoms: A service processes millions of opportunities while its incident plan remains informal or untested.

symptoms: Preventive barriers are documented, but no consequence cap or isolation test exists.

symptoms: Backups, recovery paths, or fail-safe states share dependencies with the control they are supposed to rescue.

symptoms: The first occurrence is classified as unforeseeable even though residual probability and repeated exposure were known.

symptoms: After restoration, normal exposure resumes without asking whether recurrence remains probable.

root_tension: Per-opportunity prevention can make an event rare, but repeated exposure can make at least one occurrence foreseeable. The system must preserve the incentive to prevent while also spending resources on containment and recovery for an event that may not yet have happened.

anti_signatures: A validated invariant makes the adverse outcome impossible throughout the declared operating envelope and the invariant itself is monitored.

anti_signatures: The activity is genuinely one-off, tightly bounded, and low consequence, so repeated-opportunity accumulation is not load-bearing.

anti_signatures: The concern is an unknown disruption with no definable event or opportunity process; use wild-card mapping and broad resilience instead.

anti_signatures: A rupture or incident is already active and immediate propagation control is the primary task; use Rupture Containment or the relevant incident response archetype.

anti_signatures: The central problem is only ranking known outcomes by probability and consequence; use Probabilistic Risk Weighting.

anti_signatures: Dependence, feedback, adaptation, or rapidly changing probability makes a repeated-trial model meaningless and no conservative alternative can be defined.

structural_intervention: Replace prevention-only, per-opportunity reasoning with a governed horizon-level design basis. Define and count opportunities, bound occurrence probability, challenge dependence assumptions, estimate cumulative occurrence, and set a posture-switch rule. Continue prevention and opportunity reduction, but simultaneously establish consequence caps, isolation boundaries, detection and escalation, safe or degraded states, recovery and remedy, recurrence review, and model-refresh triggers.

action_logic: Define the adverse outcome precisely enough to count, detect, and distinguish from neighboring events.

action_logic: Define one opportunity for occurrence and the time, volume, population, or mission horizon relevant to the decision.

action_logic: Estimate or conservatively bound per-opportunity probability and document evidence, uncertainty, and residual risk after prevention.

action_logic: Test independence, stationarity, mixing, clustering, feedback, and adaptive-opponent assumptions before selecting a cumulative model.

action_logic: Calculate or bound horizon-level occurrence and examine sensitivity to volume, probability, dependence, and consequence assumptions.

action_logic: Set a posture-switch threshold based on cumulative risk, consequence severity, irreversibility, duty of care, and the feasibility of containment.

action_logic: Continue reducing per-opportunity probability and opportunity count; do not treat containment as permission to abandon prevention.

action_logic: Partition the system into failure domains, declare a consequence cap, preserve critical functions, and define a safe or degraded state.

action_logic: Instrument occurrence detection, escalation authority, isolation actions, notification, remedy, and recovery pathways.

action_logic: Test the design through simulation, fault injection, blast-radius tests, tabletop exercises, and restore drills under realistic dependencies.

action_logic: After any occurrence or material exposure change, update the model, treat recurrence as credible until evidence supports otherwise, and decide whether to resume, scale back, redesign, or stop.

decision_rules: If a credibly nonzero per-opportunity probability and the expected opportunity count make one or more occurrences materially likely, make occurrence an explicit design basis even while prevention continues.

decision_rules: If consequence is catastrophic, irreversible, unlawful, or imposed on nonconsenting parties, require containment or stop criteria even when the numerical cumulative probability is uncertain or below a routine threshold.

decision_rules: If independence or stationarity is not defensible, do not use 1 - (1 - p)^n as a decision claim; use dependence-aware simulation, scenario bounds, empirical rates, or a more conservative envelope.

decision_rules: If an acceptable consequence cap cannot be demonstrated and the harm is intolerable, eliminate, suspend, or sharply reduce exposure rather than merely documenting residual risk.

decision_rules: No occurrence observed so far may update the estimate, but it does not by itself prove p = 0 or invalidate the need for containment.

decision_rules: After the first occurrence, assume recurrence remains possible until the initiating pathway, opportunity process, and common causes have been re-evaluated.

target_invariants: Per-opportunity risk is never silently presented as horizon-level safety.

target_invariants: Probability, opportunity count, dependence assumptions, and consequence remain linked in every risk claim.

target_invariants: Preventive controls remain active unless the hazardous activity is removed; containment is additive, not substitutive.

target_invariants: The declared consequence cap is testable and includes detection and response latency.

target_invariants: Critical functions either continue within a safe envelope or stop cleanly.

target_invariants: Containment and recovery do not depend on the same unexamined common-mode path as prevention.

target_invariants: Affected parties receive notification and remedy proportional to harm; blast radius is not merely shifted to less visible groups.

target_invariants: Exposure growth and post-incident evidence trigger model refresh rather than relying on a static historical estimate.

expected_outcomes: Fewer decisions that confuse rare per opportunity with safe over the operating horizon.

expected_outcomes: Earlier investment in isolation, consequence caps, detection, safe states, recovery, and remedy.

expected_outcomes: Reduced blast radius, downtime, recurrence, and surprise when a residual-risk event occurs.

expected_outcomes: More transparent decisions about whether to continue, scale back, redesign, insure, reserve for, or stop an activity.

expected_outcomes: Better alignment between actual exposure volume and the testing cadence of preventive and recovery controls.

expected_outcomes: A shift from “unforeseeable accident” narratives to auditable assumptions and accountable residual-risk governance.

name: Finite-Horizon Cumulative Risk Governance

short_definition: Use a bounded opportunity count and decision horizon to determine when a small per-opportunity probability becomes a containment and recovery requirement.

distinctive_feature: It replaces an asymptotic claim with a decision-specific finite horizon, probability range, and posture-switch threshold.

distinct_from_parent: The parent includes unbounded and qualitative recurrence reasoning; this variant requires explicit finite-horizon governance.

still_same_parent_because: It uses the same structural move from repeated nonzero risk to prebuilt containment, consequence caps, and recovery.

source_primes: eventual_realisation_of_possibility probability time risk containment

use_when: The relevant horizon is finite but contains enough opportunities for at least one occurrence to become materially likely.

use_when: The organization needs an auditable threshold rather than an informal appeal to eventuality.

use_when: Opportunity volume and probability bounds can be estimated or conservatively bracketed.

example: A service converts a one-in-one-hundred-million catastrophic request risk into a monthly occurrence probability using forecast request volume, then requires tenant isolation and tested restore paths.

failure_modes: Choosing a short horizon to keep cumulative risk below the governance threshold.

failure_modes: Reporting a point probability without sensitivity bounds or dependence assumptions.

Assume-Breach Containment

short_definition: Treat repeated or adaptive attack opportunities as sufficient reason to design for eventual control bypass, then isolate privileges, data, and propagation before a breach occurs.

distinctive_feature: The opportunity generator is strategic and may increase effective probability by learning, probing, or selecting weak paths.

distinct_from_parent: The parent can model stochastic repeated opportunities; this variant assumes adaptive adversarial pressure and therefore distrusts independence and stationarity.

still_same_parent_because: It retains the same prevention-plus-containment posture and makes occurrence a design basis rather than a surprise.

use_when: Attackers can make many attempts or adapt after observing defenses.

use_when: A single perimeter control cannot be proven complete over the operating horizon.

use_when: Compartmentalization, detection, credential rotation, and recovery can materially cap harm.

domain: cybersecurity

example: A platform assumes one credential or service boundary can eventually be crossed and limits each credential's scope, isolates tenants, monitors lateral movement, and rehearses key rotation and restore.

failure_modes: Using assume breach as an excuse to weaken preventive controls.

failure_modes: Building nominal segmentation whose management plane remains a common-mode path.

Eventual Defect-Escape Containment

short_definition: Treat a nonzero residual defect-escape rate across high production volume as an eventual field event and prebuild traceability, quarantine, remedy, and recurrence control.

distinctive_feature: It centers the gap between per-unit conformance and population-level escape over production volume.

distinct_from_parent: The parent is domain-general; this variant adds lot traceability, quarantine, recall, and corrective-action machinery.

still_same_parent_because: It shifts from confidence in per-unit prevention to bounded field consequence and tested recovery under repeated opportunities.

source_primes: eventual_realisation_of_possibility probability recurrence containment observability

use_when: Inspection or testing has a known or credibly nonzero miss rate.

use_when: Production volume makes at least one field escape materially likely.

use_when: Lots, versions, suppliers, or affected units can be traced and bounded after discovery.

example: A maker with a tiny residual test escape rate uses serial traceability, lot quarantine, field monitoring, notification, and correction plans because large shipment volume makes an escape foreseeable.

failure_modes: Treating traceability as sufficient when recall reach or remedy capacity is weak.

failure_modes: Averaging defect rates across suppliers and hiding a concentrated source.


Evidence-Bound Authentication

batch: Batch 06

source_primes: authentication verification evidence attestation provenance access_control capability_separation

slug: authentication

slug: verification

slug: evidence

slug: attestation

slug: provenance

slug: trust

slug: traceability

slug: screening

slug: signaling

slug: accountability

slug: transparency

slug: consent

slug: legitimacy

slug: indirection

slug: authority

slug: boundary

slug: constraint

slug: governance

slug: observability

components:
Asserted Identity or Origin Claim
Authentication Subject Boundary
Admissible Evidence Standard
Evidence-to-Claim Binding Rule
Verifier Role and Procedure
Freshness, Revocation, and Scope Check
Authentication Verdict Taxonomy
Verdict-to-Trust Coupling Rule
Audit and Appeal Record
Minimum Disclosure Boundary
Multi-Factor Evidence Set
Challenge-Response Nonce
Federated Trust Anchor
Step-Up Authentication Trigger
Privacy-Preserving Proof Path
Manual Exception Review Path

mechanisms:
Credential Verification Workflow
Authentication Broker
Digital Signature Verification
Certificate Chain Validation
Multi-Factor Authentication
Challenge-Response Authentication
Provenance Chain Review
Chain-of-Custody Evidence Review
Federated Identity Assertion
Zero-Knowledge Authentication Protocol
Liveness or Presence Check
Revocation Status Check

essence_one_line: Grant trust, access, or evidential weight only after an asserted identity or origin is bound to admissible evidence and returned as a scoped authentication verdict.

compression_statement: Define the claim to be authenticated, the evidence admissible for that claim, the verifier and procedure, the freshness and revocation checks, the verdict categories, and the downstream coupling from verdict to trust, access, authority, or weight; then reject, challenge, escalate, or narrowly accept the claim without confusing authentication with authorization, broad credibility judgment, or hidden-quality screening.

core_intuition: A name, account, credential, signature, provenance statement, or source label is only an assertion until a procedure ties it to evidence. Authentication turns an identity-like claim into an operational verdict: enough, not enough, expired, revoked, mismatched, inconclusive, or accepted only within a stated scope. The point is not to prove the entire person, object, or source is trustworthy; it is to decide whether this asserted binding is good enough for the next action.

canonical_formula: Authenticate(C, E, P, S, T) -> V, where C is an asserted identity/origin claim, E is evidence admissible under policy P, S is the verifier and procedure, T is the time/context of use, and V is a scoped verdict such as accept, reject, challenge, step-up, expired, revoked, mismatch, or inconclusive. Downstream action A may proceed only if coupling_rule(V, risk, scope) permits it.

structural_problem: A system must decide whether to trust, admit, weigh, route, or act on a claim about who or what something is, where it came from, who committed to it, or whether it is the same source previously known. Names, labels, accounts, credentials, documents, signatures, custody records, and metadata can be copied, forged, stale, misbound, misrouted, or true only for a narrower scope. Without an authentication archetype, downstream access and trust decisions treat assertions as facts, while provenance reviews, authorization rules, and general screening processes compensate too late or answer a different question.

trigger_conditions: A request, object, record, message, artifact, account, actor, device, source, or credential presents an identity or origin claim.

trigger_conditions: A later action depends on the claim: access, weight, responsibility, custody, privilege, publication, payment, acceptance, or attribution.

trigger_conditions: The claim can be imitated, replayed, substituted, stolen, forged, stale, delegated, or confused with a nearby entity.

trigger_conditions: Evidence can be gathered or checked through a repeatable procedure rather than accepted solely by reputation or assertion.

trigger_conditions: False acceptance and false rejection both matter, and the correct balance depends on risk, burden, fairness, and privacy.

trigger_conditions: The verdict must be scoped by time, capability, context, chain of custody, trust anchor, or assurance level.

trigger_conditions: A downstream system needs a machine-readable or institutionally legible decision state before proceeding.

symptoms: Accounts, documents, artifacts, requests, or sources are accepted because they look familiar rather than because their binding evidence was checked.

symptoms: Authorization rules are elaborate, but the identity or origin entering those rules is weakly established.

symptoms: A credential is valid in the abstract but stale, revoked, out of scope, borrowed, replayed, or not bound to the present claimant.

symptoms: Provenance records exist but are not connected to a verdict usable by access, trust, or evidential-weight decisions.

symptoms: Reviewers confuse source reliability with source identity, accepting a claim because the source is plausible rather than authenticated.

symptoms: A system has no clear state for inconclusive, step-up-required, expired, or challenged authentication results.

symptoms: Audits can show a decision was made but cannot reconstruct which evidence bound the assertion at the time of use.

symptoms: Users or subjects are forced to disclose more evidence than necessary because the authentication burden is not scoped.

root_tension: Authentication must be strong enough to prevent impersonation, substitution, replay, and provenance fraud, yet bounded enough to avoid turning every access or trust decision into intrusive surveillance, impossible certainty, or overbroad credentialism. It sits between bare assertion and downstream authorization: too weak, and the wrong entity gains trust; too heavy, and legitimate entities are excluded or overexposed.

anti_signatures: The task is only to decide what an already-authenticated actor may do; use access-control and least-privilege archetypes instead.

anti_signatures: The task is to evaluate the quality, competence, or risk type of a known candidate rather than to bind identity or origin; use hidden-type screening, certification, or credible signaling.

anti_signatures: The task is broad source criticism across conflicting accounts, not a scoped identity/origin verdict; use source provenance triangulation.

anti_signatures: The system simply routes interactions through a boundary gateway without needing a claim-to-evidence verdict; use gateway mediation.

anti_signatures: The claim is self-evident from direct physical possession in a low-stakes context and no persistent identity/origin decision is reused.

anti_signatures: The relevant outcome is moral legitimacy, consent, or authority foundation rather than proof that the claimant is who or what it asserts.

anti_signatures: The available evidence is intentionally symbolic, ceremonial, or expressive, and treating it as authentication would overclaim its force.

structural_intervention: Create an authentication gate that specifies the identity or origin claim, admits only relevant evidence, binds that evidence to the present claimant and context, checks freshness and revocation, records a scoped verdict, and couples the verdict to downstream trust, access, evidential weight, or escalation paths.

action_logic: Declare the asserted identity, origin, authorship, custody, device, account, credential, or source claim and the downstream decision that depends on it.

action_logic: Choose an evidence standard proportionate to risk, burden, context, privacy, and required assurance level.

action_logic: Gather or receive evidence through controlled channels that preserve integrity, provenance, and subject/data minimization.

action_logic: Bind the evidence to the claimant, artifact, request, record, or source in the current context rather than merely checking an abstract credential.

action_logic: Validate evidence using specified procedures, including chain, signature, issuer, liveness, possession, custody, or corroborating checks as appropriate.

action_logic: Check freshness, expiry, revocation, delegation scope, replay risk, and time-of-check-to-time-of-use exposure.

action_logic: Return a verdict from a finite taxonomy such as accepted, rejected, inconclusive, step-up required, expired, revoked, mismatched, out of scope, or manually review.

action_logic: Couple only the allowed downstream trust, access, or evidence-weight action to the verdict, preserving scope and not granting unrelated permissions.

action_logic: Record enough audit trace, appeal path, and evidence references to make the authentication decision reviewable without unnecessary exposure.

action_logic: Monitor failure modes, adversarial adaptation, false positives, false negatives, user burden, privacy leakage, and exclusion patterns; recalibrate the standard when needed.

decision_rules: If the consequence of false acceptance is high, require stronger binding evidence, freshness proof, and independence from replay or credential theft.

decision_rules: If the consequence of false rejection or exclusion is high, provide a fallback channel, appeal path, assisted review, or equivalent access route.

decision_rules: Do not convert a valid credential into broad authorization; map the verdict to a specific scope, time, resource, and confidence level.

decision_rules: Treat stale, revoked, delegated, or context-mismatched evidence as a different verdict from simple rejection so remediation is possible.

decision_rules: Require step-up authentication when risk, anomaly, privilege level, context shift, or evidence conflict exceeds the normal assurance band.

decision_rules: Prefer minimum necessary disclosure when the needed verdict can be produced without revealing the underlying secret, identity attribute, or full history.

decision_rules: Separate issuing authority from verification where forgery resistance, accountability, or open verification is part of the assurance model.

decision_rules: When authentication evidence and source credibility diverge, authenticate the identity/origin first and evaluate reliability separately.

expected_outcomes: Fewer impersonation, substitution, replay, provenance-fraud, and credential-misuse failures.

expected_outcomes: Cleaner separation between identity/origin verdicts and later authorization, weighting, or trust decisions.

expected_outcomes: More consistent treatment of inconclusive, expired, revoked, and step-up-required cases.

expected_outcomes: Reduced unnecessary disclosure because evidence burden is scoped to the needed verdict.

expected_outcomes: Better auditability of who or what was accepted, on what evidence, at what time, for what scope.

expected_outcomes: More resilient trust pipelines for records, artifacts, software requests, institutional credentials, and content provenance.

prose_tradeoffs: Stronger authentication can reduce impersonation, substitution, replay, and provenance fraud, but it also creates friction, cost, latency, privacy exposure, accessibility barriers, and central points of failure. Lightweight authentication improves usability but may push risk into downstream systems that assume identity or origin was firmly established. Federated identity reduces integration cost but shifts trust to issuers and brokers. Privacy-preserving proof reduces exposure but may add complexity and reduce debuggability.

Credential-Based Authentication

short_definition: Authenticates a claim by checking a credential, certificate, key, license, badge, or token against issuer, holder, scope, and revocation evidence.

distinctive_feature: The main evidence object is a credential or certificate whose issuing chain and holder binding must be validated.

distinct_from_parent: The parent includes provenance, liveness, chain-of-custody, and zero-knowledge forms; this variant centers on issuer-backed credentials.

still_same_parent_because: It still returns a scoped authentication verdict linking assertion to evidence before downstream reliance.

source_primes: authentication attestation verification

use_when: A portable credential can be presented to a verifier.

use_when: The credential must be checked for holder binding, scope, expiry, and revocation.

example: A system validates that a presented certificate is issued to the claimed service name and not revoked.

Provenance-Based Authentication

short_definition: Authenticates an artifact, record, source, or batch by checking origin, custody, integrity, and transfer evidence.

distinctive_feature: The evidence is a lineage rather than a single login factor or credential.

distinct_from_parent: It emphasizes custody, origin, and integrity chains; the parent includes actor, device, account, and source authentication too.

still_same_parent_because: It still binds an asserted identity/origin claim to admissible evidence and emits a scoped verdict.

source_primes: authentication provenance evidence traceability

use_when: The object or record claims a specific origin or continuity.

use_when: Custody gaps, substitution, forgery, or unauthorized alteration are material risks.

use_when: The verdict gates evidential weight, sale, publication, acceptance, or handling.

domain: archive

example: A document is accepted as the original record only after transfer logs and signatures match the claimed provenance.

Step-Up Authentication

short_definition: Raises the authentication evidence requirement when context, action risk, anomaly, or privilege exceeds a normal assurance threshold.

distinctive_feature: Authentication strength changes dynamically with risk and context rather than being static.

distinct_from_parent: The parent defines the whole authentication gate; this variant defines adaptive escalation of evidence.

still_same_parent_because: The output remains an authentication verdict coupled to a scoped downstream action.

source_primes: authentication risk threshold

use_when: The same claimant performs actions with different risk levels.

use_when: Anomalous context changes the probability of impersonation or credential theft.

use_when: Low-friction default authentication must be supplemented for consequential actions.

domain: banking

example: A transfer above a threshold requires a fresh possession factor and transaction-bound confirmation.

Privacy-Preserving Authentication

short_definition: Authenticates a required claim while revealing only the verdict or minimum necessary attribute, not the underlying secret or full identity record.

distinctive_feature: The authentication procedure is designed around minimal disclosure rather than maximum evidence exposure.

distinct_from_parent: The parent permits many evidence channels; this variant prioritizes selective proof and disclosure minimization.

still_same_parent_because: It still binds the asserted claim to admissible evidence through a verdict procedure.

use_when: The verifier needs a binary or scoped claim but not the underlying attribute.

use_when: Disclosure creates safety, privacy, discrimination, or regulatory risk.

use_when: A cryptographic, escrowed, selective-disclosure, or trusted intermediary proof can produce the verdict.

example: A verifier receives proof that a user meets an age threshold without seeing date of birth or legal name.

near_names:
Authentication
Identity Verification
Origin Verification
Authentication Broker
Credential Verification
Proof of Identity
Authenticity Check