Fast/Slow Path Routing

batch: Batch 13

canonical_family: Staged Processes & Exception Routing

source_primes: fast_path_slow_path_architecture screening threshold resource_management cost_benefit_analysis asymmetry path classification queueing flow

slug: screening

slug: asymmetry

slug: path

slug: classification

slug: queueing

slug: flow

slug: gatekeeping

slug: latency

slug: boundedness

slug: risk

slug: equity

components:
Case Unit and Outcome Boundary
Common Case Definition
Fast Path Lane
Exception or Ambiguity Detector
Routing Trigger
Slow Path Lane
Safety and Fairness Guardrail
Escalation Handoff Protocol
Slow Path Capacity Reserve
Feedback Recalibration Loop
Confidence Score or Uncertainty Signal
Audit Sampling Rule
Manual Override and Appeal Path
Return-to-Fast-Path Rule
Surge or Degraded-Mode Policy

mechanisms:
Triage Rule Table
Confidence Threshold Router
Automated Pre-Screen with Manual Review
Happy-Path / Exception Workflow
Cache with Authoritative Fallback
Fast-Track Lane with Audit
Exception Queue Dashboard
Deoptimization or Fallback Handler
Escalation Playbook

core_intuition: Most cases often share enough structure that treating every case like a rare exception wastes scarce attention, time, compute, and expertise. But the rare case is exactly where shortcuts can produce outsized harm. The archetype works by admitting that the system has two different cost and risk regimes, then making the boundary between them explicit, monitored, and revisable.

canonical_formula: For case x: if FastEligible(x) and GuardrailsOK(x) and Confidence(x) >= trigger then FastPath(x); else SlowPath(x). Recalibrate trigger and path capacity from false-fast errors, false-slow burden, tail harm, queue age, drift, and subgroup outcomes.

structural_problem: A single treatment path is being used for cases with very different frequency, cost, ambiguity, and risk profiles. If the path is optimized for the common case, rare or high-stakes exceptions are under-examined. If the path is optimized for exceptions, ordinary cases are burdened by unnecessary delay, cost, expertise, or bureaucracy. Without explicit routing, the system oscillates between over-processing the routine and under-protecting the exceptional.

trigger_conditions: The case stream contains many routine low-risk items and a smaller set of ambiguous, rare, adversarial, irreversible, or high-impact items.

trigger_conditions: A cheap treatment can handle the common case with acceptable error only if its assumptions are explicit.

trigger_conditions: A slower treatment exists that can use richer evidence, authority, expertise, computation, deliberation, or safeguards.

trigger_conditions: The system can observe enough features, confidence, or context to trigger path selection before the cost or harm of misrouting becomes too high.

trigger_conditions: Applying slow-path treatment to every case would overload capacity, destroy latency targets, or waste expertise.

trigger_conditions: Letting every case use the fast path would hide errors, inequity, abuse, rare hazards, or corrupted evidence.

trigger_conditions: The boundary between routine and exceptional can drift as case mix, incentives, threats, or technology changes.

symptoms: Routine cases wait behind complex exceptions even though they need little judgment.

symptoms: Experts spend scarce attention repeating decisions that could be safely standardized or automated.

symptoms: Rare cases slip through a simplified process and create tail failures, appeals, rework, or public harm.

symptoms: Operators invent informal shortcuts because the official process is too slow for ordinary work.

symptoms: A trigger or rule exists, but no one tracks false-fast approvals, false-slow escalations, or slow-path backlog.

symptoms: The slow path becomes a dumping ground with unclear ownership, weak handoff, and no protected capacity.

symptoms: Fast-path eligibility becomes path dependent: originally narrow assumptions silently expand until safeguards are bypassed.

symptoms: Different groups experience systematically different routing errors or appeal burdens.

root_tension: The archetype manages the tension between average-case efficiency and exceptional-case integrity. The common case deserves speed and simplicity, but rare cases often carry disproportionate informational, ethical, safety, or strategic weight. A useful design lowers average cost without pretending that every case belongs to the average.

anti_signatures: All cases require individualized deliberation or carry high enough stakes that a cheap fast path is unsafe.

anti_signatures: The slow path has no greater authority, evidence, capability, or safeguards than the fast path.

anti_signatures: The system cannot observe any reliable feature, threshold, uncertainty signal, or appeal trigger before routing.

anti_signatures: The central problem is service order among waiting cases; use queue_discipline_design.

anti_signatures: The central problem is capacity relative to arrivals; use service_rate_matching or work_in_progress_limiting.

anti_signatures: The central problem is a simple threshold activating one response; use threshold_based_activation.

anti_signatures: The central problem is escalation through multiple authority levels; use tiered_escalation.

anti_signatures: The central problem is staged recognition through coarse-to-fine discriminators; use cascaded_hierarchical_recognition.

anti_signatures: The split is merely ad hoc exception handling with no maintained architecture, trigger, capacity plan, or feedback loop.

structural_intervention: Design a maintained two-path routing architecture: a cheap bounded fast path for cases inside the common-case envelope, a richer slow path for exceptions, and a monitored trigger and feedback loop that move cases between them without hiding harm.

action_logic: Define the case unit, routing outcome, and minimum invariants that neither path is allowed to violate.

action_logic: Empirically describe the common-case envelope: frequency, features, stakes, uncertainty, allowed error, latency need, and cost ceiling.

action_logic: Design the fast path to handle only that envelope with the simplest reliable rule, template, automation, cache, checklist, protocol, delegation, or optimized handler.

action_logic: Design the slow path with the authority, evidence, expertise, time, computation, or safeguards needed for cases outside the envelope.

action_logic: Specify the routing trigger: rule, threshold, confidence score, anomaly detector, red flag, appeal, sample, or human judgment that moves cases between paths.

action_logic: Protect slow-path capacity and handoff quality so escalation is a real treatment, not a queueing sink.

action_logic: Measure false-fast errors, false-slow escalations, slow-path backlog, tail harm, fairness, drift, and operator workarounds.

action_logic: Recalibrate the common-case definition, trigger, guardrails, and capacity split as case mix, incentives, or stakes change.

decision_rules: Use a fast path only for cases whose assumptions can be named and whose worst plausible error remains within the guardrail envelope.

decision_rules: Escalate by ambiguity, novelty, risk, irreversibility, value, adversarial signal, rights impact, missing evidence, or operator uncertainty, not merely by inconvenience.

decision_rules: Set the trigger using both directions of error: harm from letting an exception stay fast and cost from sending routine cases slow.

decision_rules: Reserve slow-path capacity before expanding fast-path volume; otherwise exceptions accumulate until the trigger is ignored.

decision_rules: Include appeal, override, or audit when routing affects rights, access, safety, credit, diagnosis, moderation, discipline, or allocation.

decision_rules: Treat repeated slow-path cases as design feedback: either make a new fast-path subtype or revise the common-case envelope.

decision_rules: Tighten routing under drift, adversarial pressure, high stakes, low observability, or subgroup error imbalance.

target_invariants: Fast-path speed must not erase the safety, fairness, correctness, or evidence requirements that define acceptable outcomes.

target_invariants: The slow path must remain resourced enough to handle routed cases within a defensible time window.

target_invariants: The routing trigger must remain inspectable, contestable where stakes require it, and recalibrated against observed outcomes.

target_invariants: Exceptional cases must carry context across the handoff so slow-path review starts from evidence rather than from scratch.

target_invariants: The architecture must detect when the fast path is being gamed, overextended, or used as a bypassed safeguard.

expected_outcomes: Lower average latency and operating cost for routine cases.

expected_outcomes: Better use of scarce expert, review, compute, or deliberative capacity.

expected_outcomes: Earlier detection and safer handling of ambiguous, rare, adversarial, high-stakes, or novel cases.

expected_outcomes: Reduced informal workaround pressure because routine cases no longer need exception-level burden.

expected_outcomes: More visible tradeoff between false-fast harms and false-slow burden.

expected_outcomes: Improved auditability of why a case took the route it did.

prose_essence:
Route routine cases through a cheap, safe fast path while sending exceptional, ambiguous, risky, or high-value cases to a deliberately resourced slow path.

When one uniform process either over-processes common cases or under-processes rare ones, define the common-case envelope, build a bounded fast lane for it, define a trigger for ambiguity or risk, route exceptions to a slower path with the right authority and evidence, protect slow-path capacity, and use feedback to recalibrate the boundary.

The core design move is to stop pretending that one path should be optimal for every case. A fast path is justified only for cases that fit a named, monitored common-case envelope. A slow path is justified only when it has the extra evidence, authority, expertise, computation, or safeguards that make escalation worthwhile.

Hot-Path / Cold-Path Architecture

short_definition: Optimizes high-frequency operations through a hot path while sending rare, cold, expensive, or integrating operations through a slower path.

distinctive_feature: The main split is between high-frequency fast operations and low-frequency slow or authoritative operations.

distinct_from_parent: Narrower and more systems-oriented than the parent; often implemented with caches, optimized handlers, or fallback routines.

still_same_parent_because: It still routes common cases cheaply and escalates exceptions to a more expensive path through a maintained trigger.

use_when: Request frequency is highly skewed and the common operation must be extremely cheap.

use_when: The exceptional case requires a different store, computation, consistency check, or integration step.

use_when: The system can detect misses, conflicts, or assumption breaks reliably enough to fall back.

example: Serving cache hits immediately while routing misses or conflicts to the authoritative database.

example: Executing optimized code until guard assumptions fail, then deoptimizing to a general interpreter.

failure_modes: The hot path becomes a bypassed safeguard and handles cases it was never validated for.

Happy-Path / Exception-Path Design

short_definition: Defines a streamlined expected workflow and an explicit route for cases that violate assumptions, require extra evidence, or need special handling.

distinctive_feature: The split is described in process-design language: a normal happy path plus a named exception path.

distinct_from_parent: Narrower than the parent because it is usually a workflow design and documentation pattern.

still_same_parent_because: The structural logic remains cheap routine processing with deliberate escalation of nonroutine cases.

use_when: A routine workflow is repeatedly slowed by rare exceptions.

use_when: Exceptions are real and recurring enough that they deserve a designed route rather than ad hoc workarounds.

use_when: Operators need to know what information and ownership must travel with an exception.

example: Auto-resolving routine account questions while escalating billing disputes to specialists.

domain: administration

example: Approving complete standard forms quickly while routing unusual claims to review.

failure_modes: The exception path becomes unowned, slow, and punitive rather than resourced.

Cheap Screen / Expensive Review

short_definition: Uses a cheap, intentionally selective screen to decide which cases need an expensive authoritative check.

distinctive_feature: The decisive split is an economics-of-verification split between cheap screening and expensive confirmation.

distinct_from_parent: Narrower than the parent because the slow path is specifically authoritative review after a cheaper screen.

still_same_parent_because: It is a direct instance of the fast/slow architecture with screening as the routing mechanism.

use_when: The expensive review is too costly to apply to all cases.

use_when: False negatives, false positives, or adversarial bypass risks can be measured and bounded.

use_when: The cheap screen is calibrated to protect high-harm exceptions.

example: Automatically approving low-risk transactions while routing anomalies to fraud analysts.

example: Using automated screening to queue uncertain or high-impact cases for trained review.

failure_modes: The cheap screen is optimized for average cost and silently increases costly false negatives.

Fast-Track Lane with Safety Audit

short_definition: Creates a low-friction lane for apparently low-risk or prequalified cases while auditing enough cases to protect safety, fairness, and eligibility integrity.

distinctive_feature: The fast path is intentionally privileged or accelerated and therefore requires stronger fairness and audit design.

distinct_from_parent: Narrower than the parent because it centers access, eligibility, and governance of fast-track privilege.

still_same_parent_because: It still partitions common or low-risk cases away from deeper review with a maintained trigger and feedback loop.

use_when: Some cases can fairly receive accelerated handling.

use_when: Acceleration creates risk of inequity, fraud, omitted safeguards, or hidden selection bias.

use_when: The organization can sample, audit, and correct the fast lane.

example: Fast-processing complete low-risk applications while sampling approvals for eligibility drift.

example: Using protocol-driven nurse handling for routine requests with audit and physician escalation.

failure_modes: The fast lane becomes a biased privilege channel or a way to bypass safeguards.

near_names:
Fast-Path / Slow-Path Architecture
Fast/Slow Path Architecture
Common-Case / Exception-Case Routing
Cheap Filter / Expensive Check
Happy Path / Exception Workflow
Hot Path / Cold Path Design


Fast–Slow Store Coupling

type: archetype

source: generated

batch: Batch 10

canonical_family: Memory, Records & Persistence

aliases: Fast Scratchpad with Durable Backing Store

alias_records: Fast Scratchpad with Durable Backing Store

slug: caching

slug: replay

slug: redundancy

slug: coupling

slug: buffering

slug: pipeline

slug: scalability

slug: sharding

slug: versioning

slug: scheduling

slug: cadence

components:
Fast Volatile Store
Slow Integrated Store
Read/Write Routing Rule
Transfer Trigger or Cadence
Consolidation Transform
Promotion and Eviction Rule
Interference and Overwrite Guard
Freshness and Authority Marker
Consistency Reconciliation Check
Capacity and Latency Budget
Slow-Store Bypass Exception
Transfer Backlog Dashboard
Replay-Assisted Consolidation Window

mechanisms: Write-Back Cache with Durable Backing Store

mechanisms: Short-Term to Long-Term Memory Consolidation Routine

mechanisms: Staging Table to Canonical Warehouse Pipeline

mechanisms: Incident Timeline to Permanent Runbook Update

mechanisms: Local Inventory Cache with System-of-Record Refresh

essence_one_line: Keep a volatile fast store and a durable integrated store coupled by governed transfer so the system gets immediate access without losing long-term coherence.

compression_statement: Fast–Slow Store Coupling solves the incompatibility between speed and integration by giving each demand its own substrate: a small, quick, interference-prone store for live use, and a slower, integrated store for durable memory or source-of-truth structure. The archetype succeeds only when transfer, consolidation, eviction, freshness, and reconciliation rules prevent the two stores from drifting into separate realities.

core_intuition: One memory layer cannot usually be optimized for everything. The layer that is fast enough for live work is too crowded, local, or overwritable to remain authoritative. The layer that is durable enough to integrate everything is too slow or heavy for immediate use. Coupling the two lets the system answer now and learn for later, as long as the coupling rules are treated as part of the design rather than an afterthought.

canonical_formula: fast_volatile_store + slow_integrated_store + transfer_cadence + consolidation_transform + reconciliation_guard -> rapid_access_with_durable_coherence

structural_problem: A system must respond quickly to local, recent, or high-frequency demands while also preserving a coherent, integrated, durable memory. Using only a fast store causes overwriting, fragmentation, stale local truth, and loss of history. Using only a slow integrated store makes live action too expensive, late, or cognitively burdensome.

trigger_conditions: Local or recent state is needed faster than the canonical store can safely supply it.

trigger_conditions: Material first appears in a fragile, crowded, or context-specific form that can be overwritten by new input.

trigger_conditions: Durable value depends on later integration, deduplication, compression, validation, or provenance preservation.

trigger_conditions: The system faces repeated reads or decisions where locality of reference makes a fast layer valuable.

trigger_conditions: Transfer from the fast layer to the slow layer can be scheduled, triggered, or governed explicitly.

trigger_conditions: The cost of maintaining two stores is lower than the cost of slow responses, lost traces, or incoherent memory.

symptoms: Teams rely on quick notes, local spreadsheets, inboxes, or chat threads that never become institutional memory.

symptoms: A cache, working set, queue, or scratchpad is useful in the moment but repeatedly becomes stale or misleading.

symptoms: Canonical records are accurate but too slow or hard to consult during live work.

symptoms: Important new information disappears because the fast layer is overwritten before consolidation.

symptoms: The organization has both rich archives and fast local workarounds, but no reliable transfer between them.

symptoms: Errors arise because users cannot tell whether the fast store, slow store, or transfer pipeline is authoritative.

root_tension: Speed wants locality, mutability, and low overhead; durable integration wants validation, context, normalization, and stability. The architecture must keep those needs separate without letting them become uncoordinated.

anti_signatures: The only goal is to cache reusable results near demand; use Strategic Caching when no slow-store integration problem exists.

anti_signatures: The only goal is to do likely future work early; use Precomputation / Prefetching.

anti_signatures: The fast and slow paths are decision methods rather than storage substrates; use Heuristic vs. Algorithm Tradeoff and Selection or Fast-Path / Slow-Path Architecture when drafted.

anti_signatures: The second store is merely a backup copy for resilience; use Diverse Functional Redundancy or Path Redundancy Provisioning.

anti_signatures: The temporary store has no intended durable transfer; use Buffering or Intake Queue Staging.

anti_signatures: Legal, safety, or privacy constraints require one authoritative record and prohibit duplicated working copies.

structural_intervention: Introduce two explicitly differentiated stores: a fast, volatile, high-access layer for immediate work and a slower, integrated layer for durable coherence. Define routing, transfer, consolidation, eviction, freshness, and reconciliation rules so the layers cooperate instead of becoming competing truths.

action_logic: Define the demand that must be served quickly and the evidence, state, or memory that must remain durable.

action_logic: Partition storage into a fast layer optimized for latency, locality, mutability, or working access and a slow layer optimized for integration, provenance, validation, and durability.

action_logic: Specify which operations read from the fast layer, which write to it, which bypass it, and which require slow-layer confirmation.

action_logic: Create transfer triggers or a transfer cadence that moves selected material from the fast store into the slow store before decay, overwriting, or context loss.

action_logic: Transform material during transfer through validation, deduplication, normalization, summarization, compression, enrichment, or provenance marking.

action_logic: Set eviction, expiration, refresh, and promotion rules so the fast store remains useful rather than becoming a junk drawer.

action_logic: Reconcile conflicts between the two stores with versioning, authority rules, audit trails, and repair paths.

action_logic: Monitor latency, hit rate, stale-use events, transfer backlog, integration quality, and slow-store coherence.

decision_rules: Use the fast layer for high-frequency, low-latency, reversible, or locally contextual operations.

decision_rules: Require slow-layer confirmation when correctness, auditability, safety, or durable institutional memory matters more than speed.

decision_rules: Transfer soon enough that fragile traces do not decay, but late enough that the slow store is not polluted by every transient scratch item.

decision_rules: Prefer triggered transfer for high-risk or high-value traces and cadence-based transfer for routine accumulation.

decision_rules: Make the slow store authoritative for long-horizon decisions unless a declared emergency mode justifies temporary fast-layer authority.

decision_rules: Retire or rebuild the fast store when stale-use incidents, conflict rates, or transfer backlog exceed tolerance.

target_invariants: The two stores have distinct optimization targets; they are not merely duplicate copies.

target_invariants: Every durable item has a visible path from fast capture to slow integration or an explicit decision not to integrate.

target_invariants: Users can tell which store is authoritative for a given purpose and time horizon.

target_invariants: Transfer rules preserve provenance, context, and uncertainty rather than silently rewriting history.

target_invariants: The fast layer remains bounded enough to be fast and disposable enough to be refreshed.

target_invariants: The slow layer remains coherent enough to serve as memory, source of truth, or integrated model.

expected_outcomes: Live work becomes faster because recent or frequent material is close to use.

expected_outcomes: Durable memory improves because important fast-layer traces are consolidated before they decay.

expected_outcomes: The system avoids choosing between slow accuracy and fast but fragile availability.

expected_outcomes: Staleness, overwriting, and split-brain state become monitored design risks rather than accidental surprises.

expected_outcomes: The architecture supports learning over time while retaining low-latency action in the present.

prose_tradeoffs: Maintaining two stores costs more than maintaining one. The architecture introduces transfer work, reconciliation work, and stale-state risk. A stricter slow-store authority improves coherence but may slow users down. A looser fast-store authority improves responsiveness but may create shadow truth. Frequent consolidation preserves traces but risks canonizing noise. Infrequent consolidation protects the slow store but loses fragile information.

Write-Back Cache Coupling

short_definition: Fast local writes are accepted in a cache or log and later flushed to a durable backing store.

distinctive_feature: Write speed is achieved by delaying durable integration while preserving a flush and recovery path.

distinct_from_parent: Narrower than the parent because it focuses on local write capture and later durable flush.

still_same_parent_because: The core structure remains a fast store, slow store, and governed transfer.

use_when: Live writes need lower latency than immediate durable integration allows.

use_when: Temporary inconsistency is acceptable within a bounded window.

use_when: Crash recovery and conflict handling can be specified explicitly.

domain: databases

example: A write-ahead log accepts fast appends before compaction into durable indexed state.

failure_modes:
Lost writes during crash
Split-brain state
Unbounded flush backlog

name: Working Trace to Long-Term Memory Coupling

short_definition: Fragile working traces are protected and consolidated into durable memory through review, rest, rehearsal, or encoding structure.

distinctive_feature: The fast layer is cognitive or operational working memory rather than a technical cache.

distinct_from_parent: Narrower than the parent because it centers on human or organizational memory consolidation.

still_same_parent_because: The same fast-store/slow-store transfer architecture governs the case.

use_when: A learner, team, or performer captures fragile traces during live work.

use_when: Those traces decay or are overwritten unless protected and later integrated.

use_when: The durable outcome is long-term recall, skill, or institutional memory.

example: Live incident notes are later converted into runbook changes and training cases.

failure_modes: Unverified impressions become canonical memory

Staging-to-Canonical Record Coupling

short_definition: Incoming material is captured quickly in a staging layer and later transformed into canonical durable records.

distinctive_feature: The slow-store transfer is explicitly a curation and canonicalization pipeline.

distinct_from_parent: Narrower than the parent because it emphasizes record quality and canonicalization.

still_same_parent_because: It still implements fast capture plus slow integration.

use_when: Raw input arrives faster than canonical validation can occur.

use_when: Canonical records need schema, provenance, deduplication, and quality checks.

use_when: The staging layer must not become the unofficial source of truth.

example: Raw event records land in a staging table before validation into a canonical warehouse.

failure_modes: Bad records are canonized by batch habit

Hot/Cold Storage Tiering

short_definition: High-use material lives in fast expensive tiers while low-use durable material migrates to slower cheaper tiers.

distinctive_feature: The split is governed by access heat and resource cost rather than only memory consolidation.

distinct_from_parent: Narrower than the parent because it emphasizes tier economics and latency management.

still_same_parent_because: It still couples fast and slow stores through promotion and demotion rules.

use_when: Access frequency varies sharply across items.

use_when: Fast storage is more expensive, scarce, or interference-prone than slow storage.

use_when: Migration rules can be based on age, frequency, value, risk, or forecasted demand.

example_domains: infrastructure archives logistics

domain: infrastructure

example: Frequently used files remain on fast storage while older material migrates to slower durable storage.

failure_modes: Misclassified heat causes latency spikes

failure_modes: Cold storage becomes inaccessible when needed

near_names:
Two-Store Architecture
Dual-Store Transfer Architecture
Fast–Slow Memory Architecture
Cache/Backing-Store Coupling
Staging-to-Canonical Transfer