Minimum Sufficient Solution

batch: First Iteration/Batch 27

Minimum Viable Solution

notes: A useful near-name when viability means sufficient for the core requirement; can be confused with MVP learning-release logic.

Minimum Necessary Solution

notes: Emphasizes exclusion of nonessential scope, but “necessary” can sound more absolute than the practical sufficiency threshold used here.

Right-Sized Solution

notes: Informal name for a solution no larger than the requirement and protected invariants justify.

Minimum Viable Scope

notes: Names the scope boundary aspect of the archetype; should not be used without a sufficiency test and expansion path.

MVP-like Scoping

notes: A common mechanism family, especially in product and service design; not identical to the broader archetype.

source_primes: minimalism parsimony constraint

slug: minimalism

slug: constraint

slug: mvp

slug: function

slug: complexity

slug: scalability

components:
Core Requirement
Preserved Invariant Set
Nonessential Feature Filter
Sufficiency Test
Expansion Path
Review Trigger
Deferred Enhancement Backlog
Stakeholder Need Trace
Exception Rule

mechanisms:
MVP-like Scoping
Minimum Viable Process
Lean Policy Design
Essential Feature Set
Minimum Viable Documentation
Simple Intervention Package
Pilotable Solution
Must/Should/Could Filter
Scope-Cut Review

essence_one_line: Implement the smallest solution that satisfies the core requirement without unnecessary features, scope, or complexity.

compression_statement: When a problem invites overbuilding, define the minimum sufficient solution that meets the core need, preserves non-negotiable invariants, excludes nonessential additions, and leaves a clear path for later expansion if evidence justifies it.

core_intuition: A solution can fail by being too small, but it can also fail by being too large: slower to deliver, harder to understand, more expensive to maintain, more brittle to change, and more confusing to users. Minimum sufficiency makes the core requirement explicit, treats every additional feature or step as needing justification, and protects against irreversible underbuilding by defining when expansion should occur.

canonical_formula: Core requirement + preserved invariants + sufficiency test + nonessential feature filter + expansion path -> smallest solution that can responsibly work

structural_problem: A solution effort expands beyond the essential requirement, increasing cost, delay, maintenance burden, implementation risk, user confusion, or governance overhead before the extra scope has earned its place.

condition: The team is adding features, process steps, controls, or deliverables before the core requirement is stable.

signal: People are debating enhancements without being able to state what would count as sufficient for the first working solution.

condition: Delivery is delayed by speculative future needs.

signal: The design includes capabilities for users, edge cases, volumes, or contexts that are not required for the present decision or launch.

condition: Stakeholder requests are treated as requirements by default.

signal: The backlog, policy text, workflow, or architecture grows because additions are easier to accept than to evaluate.

condition: The system needs a usable solution under limited time, budget, attention, or implementation capacity.

signal: A comprehensive design would be ideal but would arrive too late, cost too much, or exceed the ability of users and operators to adopt it.

condition: Nonessential complexity is creating operational or cognitive drag.

signal: Users skip steps, ignore documents, misunderstand options, or require training/support because the solution includes too much structure.

symptom: Scope creep

description: The solution boundary keeps expanding without a corresponding change in the core requirement or protected invariants.

symptom: Feature bloat

description: Capabilities remain because they are possible, requested, or fashionable, not because the solution would be insufficient without them.

symptom: Delayed delivery

description: The system postpones useful action while waiting for a complete version whose extra completeness is not necessary for the immediate need.

symptom: Maintenance drag

description: Every added part increases documentation, training, support, integration, debugging, governance, or monitoring requirements.

symptom: Unclear sufficiency boundary

description: Participants disagree about what counts as done because no minimum requirement, test, or stop condition has been defined.

symptom: User confusion or process avoidance

description: People work around the official solution because it contains more fields, choices, approvals, or instructions than they can reasonably use.

root_tension: The system must preserve enough function, safety, equity, reliability, and legitimacy to work, while avoiding the cost and delay of features, steps, variants, and controls that the current requirement does not actually need.

case: The so-called extras are actually protected invariants.

reason: Accessibility, safety, security, legality, reliability, auditability, or equity requirements may look like additions but are part of sufficiency.

case: The task is primarily to learn whether the requirement is real.

reason: That may be Minimum Viable Learning Release or a prototype-learning loop rather than a minimum sufficient operational solution.

case: The added complexity has a proven and necessary benefit.

reason: A larger design may be appropriate when evidence shows that missing functionality would cause unacceptable harm, failure, or rework.

case: Expansion after launch is infeasible or extremely costly.

reason: Minimum sufficiency is safer when there is a credible expansion path. If expansion is impossible, initial scope may need to include future-critical capacity.

case: The solution must satisfy a formal completeness standard.

reason: Legal, scientific, engineering, or contractual contexts may require full specification, redundancy, validation, or documentation before deployment.

structural_intervention: State the core requirement, identify protected invariants, filter out nonessential features or steps, validate that the remaining solution is sufficient, and define review triggers for adding scope back when evidence shows the minimum is no longer enough.

Define the core requirement

logic: Name the job the solution must perform, for whom, under what conditions, and at what minimum performance level. Without this requirement, reduction becomes arbitrary cutting.

Name protected invariants

logic: Identify what cannot be sacrificed while simplifying: safety, accessibility, legality, equity, reliability, privacy, auditability, or other non-negotiable constraints.

Separate required from optional scope

logic: List proposed features, steps, deliverables, controls, and variants, then ask whether each is necessary for the core requirement or a protected invariant.

Apply the sufficiency test

logic: Check the reduced solution against realistic use cases, edge cases, and operational constraints to verify that it can responsibly work.

name: Defer rather than erase useful additions

logic: Move nonessential additions to a visible backlog or expansion path so they are not smuggled into the initial solution or forgotten when later justified.

Set review triggers for expansion

logic: Define what evidence, load, failure, harm, user feedback, or changed requirement would justify adding capability, redundancy, control, or complexity.

rule: Keep a feature, step, or control only if the solution would fail the core requirement or a protected invariant without it.

rationale: This converts minimalism from taste into a requirement-preserving filter.

rule: Defer optional scope when the cost of including it now exceeds the risk of adding it later.

rationale: The archetype relies on reversible or staged expansion where possible.

rule: Do not call a solution sufficient until realistic users, operators, or reviewers can complete the core task with it.

rationale: Sufficiency is tested by use, not by the builder’s belief that the reduced version should work.

rule: Treat safety, accessibility, equity, legality, and reliability requirements as part of the minimum, not as enhancements.

rationale: Otherwise the archetype becomes a license for harmful underbuilding.

invariant: Core function preserved

why_it_matters: The solution must still do the job it exists to do.

invariant: Protected safety, legality, equity, and accessibility constraints preserved

why_it_matters: A small solution that shifts risk or exclusion onto users is not sufficient.

invariant: Operational usability preserved

why_it_matters: The reduced solution must be understandable, adoptable, and maintainable by its intended users and operators.

invariant: Expansion path preserved

why_it_matters: A minimum solution should be able to grow when evidence shows the minimum is no longer enough.

invariant: Decision accountability preserved

why_it_matters: Deferring scope should be visible, reasoned, and reviewable rather than hidden neglect.

outcome: Faster responsible delivery

description: Work reaches users or decision-makers sooner because optional scope no longer blocks the core solution.

outcome: Lower implementation and maintenance burden

description: Fewer parts, steps, and exceptions reduce cost, training, coordination, and support load.

outcome: Clearer solution boundary

description: Participants know what is required now, what is deferred, and what evidence would change that boundary.

outcome: Reduced overengineering and feature bloat

description: Speculative complexity is postponed until its value is demonstrated.

outcome: Improved adaptability

description: A smaller initial solution is often easier to revise when the requirement changes or feedback arrives.

prose_essence:
Minimum Sufficient Solution is the intervention pattern of building no more solution than the core requirement demands, while still preserving the constraints that make the solution responsible. It is not generic minimalism. It is a disciplined reduction of implemented scope: first define what must be accomplished, then remove features, steps, documentation, rules, or infrastructure that are not needed for that accomplishment.

The archetype is most useful when a solution is becoming large because additions are easy to request and hard to reject. Its central question is: **what is the smallest solution that can responsibly work now, and what would tell us that more is needed later?**

prose_when_to_use:
Use this archetype when an effort is expanding beyond the requirement it needs to satisfy. Typical signals include feature bloat, overbuilt workflows, excessive documentation, policy language that tries to cover every hypothetical case, or technical architecture that implements speculative future needs before the present one works.

It is especially useful under time, budget, attention, or implementation constraints. A smaller sufficient solution can often be delivered, adopted, tested, maintained, and revised more easily than a comprehensive one. The archetype is also useful when stakeholders are treating every request as a requirement; it gives the team a principled way to say “not now” without pretending the request has no value.

Do not use it as a shortcut for cutting safety, accessibility, legal compliance, equity protections, privacy, auditability, or basic reliability. Those are often part of the minimum, not enhancements.

prose_structural_problem:
The structural problem is overbuilding before sufficiency has been defined. A project, process, policy, product, or intervention grows by accretion: one feature for a possible user, one approval for a possible failure, one extra document for a possible handoff, one dashboard for a possible report. Each addition may sound reasonable in isolation, but the combined solution becomes slower, harder to use, harder to maintain, and harder to change.

The deeper tension is that incomplete solutions can fail, but excessive solutions also fail. Overbuilt solutions consume implementation capacity, confuse users, create maintenance obligations, and delay the moment when the core need is actually served.

prose_intervention_logic:
The intervention begins by naming the core requirement. A solution cannot be minimum sufficient unless the team can say what it must accomplish, for whom, under what conditions, and at what minimum standard.

Next, the team names protected invariants: the things that must remain true while scope is reduced. These often include safety, legality, accessibility, equity, privacy, reliability, auditability, and usability. This step prevents “minimum” from becoming underbuilding.

Then the team applies a nonessential feature filter. Each proposed feature, step, document, workflow, control, or capability must justify itself by supporting the core requirement or a protected invariant. Items that are useful but not required are deferred, not erased.

The reduced solution is then tested for sufficiency in realistic conditions. Finally, the team defines an expansion path and review triggers so that the minimum can grow when evidence shows that it is no longer sufficient.

prose_key_components:
### Core Requirement

The core requirement states the job the solution must perform. It anchors the entire archetype. Without it, teams cannot distinguish “essential” from “preferred,” and reduction becomes arbitrary.

### Preserved Invariant Set

The preserved invariant set names the constraints that cannot be sacrificed while simplifying. This is where safety, accessibility, equity, legality, privacy, auditability, and reliability belong. These are not decorative additions; they define what responsible sufficiency means.

### Nonessential Feature Filter

The nonessential feature filter tests each proposed part of the solution. A part stays only if the solution would fail the core requirement or a protected invariant without it. Otherwise, it is deferred, simplified, or removed.

### Sufficiency Test

The sufficiency test checks whether the reduced solution actually works. This may involve user tasks, acceptance criteria, pilots, edge-case reviews, operational walkthroughs, compliance checks, or simulations. The test keeps the archetype grounded in use rather than builder intuition.

### Expansion Path

The expansion path keeps useful but nonessential additions visible for later consideration. It lets the system start small without pretending the first minimum will be permanently enough.

### Review Trigger

The review trigger specifies what evidence should reopen the boundary: higher volume, repeated failures, user harm, unmet edge cases, support burden, changed regulation, or stakeholder feedback. It makes deferral accountable.

### Deferred Enhancement Backlog

A deferred enhancement backlog is optional but often useful. It records additions that were considered and postponed. This helps prevent both scope creep and silent neglect.

### Exception Rule

An exception rule protects cases where the minimum path is not enough. This is especially important in high-stakes or equity-sensitive contexts where rare cases cannot simply be optimized away.

prose_common_mechanisms:
### MVP-like Scoping

MVP-like scoping is a common implementation mechanism, especially in product and service contexts. It should not be confused with the archetype itself. The archetype is broader and applies to processes, policies, documentation, infrastructure, and intervention packages.

### Minimum Viable Process

A minimum viable process is the smallest recurring workflow that performs its function. It may reduce meetings, approvals, forms, or handoffs while preserving accountability and escalation.

### Lean Policy Design

Lean policy design creates the simplest rule or governance structure that can achieve the policy purpose. It avoids building a comprehensive regime before the immediate governance problem requires it.

### Essential Feature Set

An essential feature set is an artifact that lists the capabilities required for the solution to work. It separates launch-critical or implementation-critical features from enhancements.

### Minimum Viable Documentation

Minimum viable documentation gives users and operators enough information to act correctly, maintain the solution, hand it off, or escalate problems. It is not a refusal to document; it is documentation scoped to use.

### Simple Intervention Package

A simple intervention package bundles the few elements needed to produce a target effect. It is useful in public health, education, community programs, and organizational change where implementation capacity is limited.

### Pilotable Solution

A pilotable solution makes the minimum testable in a bounded context. The pilot is a mechanism for validating sufficiency; it is not automatically the archetype itself.

### Must/Should/Could Filter and Scope-Cut Review

Must/Should/Could filters and scope-cut reviews are practical sorting mechanisms. They help teams classify proposed scope, remove unnecessary parts, and preserve visibility for deferred improvements.

prose_failure_modes:
The most common failure mode is underbuilding: the team defines the core requirement too narrowly and declares a solution sufficient before realistic use proves it.

A second failure mode is treating protected invariants as optional. Safety, accessibility, equity, privacy, legality, and reliability can be mistakenly cut as “extra.”

A third failure mode is false sufficiency from idealized testing. A solution may work for expert builders in clean conditions but fail for real users under real constraints.

A fourth failure mode is permanent deferral. Useful additions are postponed with no owner, trigger, or review cadence, so the minimum becomes a stagnant under-solution.

A fifth failure mode is austerity disguised as minimalism. The language of minimum sufficiency can be misused to justify cost cutting, service denial, or burden shifting.

prose_neighbor_distinctions:
Minimum Sufficient Solution is distinct from Parsimony Filter. Parsimony Filter removes unsupported assumptions or complexity; Minimum Sufficient Solution defines the smallest implemented solution that satisfies a requirement.

It is distinct from Bounded Approximation. Bounded Approximation simplifies representation or computation while bounding error; this archetype scopes a solution.

It is distinct from Minimum Effective Intervention. Minimum Effective Intervention focuses on the least dose or intensity that produces an effect; Minimum Sufficient Solution focuses on the smallest solution form, which may include features, process, documentation, and expansion logic.

It is distinct from Minimum Viable Learning Release. A learning release is sized to generate feedback and validate assumptions; a minimum sufficient solution is sized to satisfy a known requirement. They may overlap, but their success tests differ.

It is distinct from Marginal Stop Rule. Marginal Stop Rule decides when further increments are no longer worth the cost; Minimum Sufficient Solution defines the initial sufficient boundary.

prose_cross_domain_examples:
In software, a team ships the core workflow, basic recovery, logging, and support before adding personalization or analytics.

In clinic operations, a short intake process keeps the required safety questions and escalation path while removing duplicative fields.

In local government, a temporary permit process starts with one eligibility rule, one review queue, and one appeal path before building a full licensing regime.

In education, a tutoring program begins with a diagnostic prompt, a standard session routine, and progress review before adopting a complex platform.

In technical operations, an internal deployment tool includes authentication, rollback, logging, and a runbook while deferring a custom dashboard.

prose_non_examples:
A bridge design that removes redundancy because most days do not require it is not a minimum sufficient solution. The redundancy may be part of safety sufficiency.

A public benefits form that removes translation, accessibility, or appeal mechanisms just to become shorter is not this archetype. It has removed protected invariants.

A rough forecast is not this archetype; it is closer to Bounded Approximation.

A team that stops refining a design because the next improvement is not worth the cost is using a stop-rule pattern, not necessarily Minimum Sufficient Solution.

A prototype launched only to learn whether users care is closer to Minimum Viable Learning Release or prototype learning if it does not satisfy the core requirement.

prose_tradeoffs:
Minimum sufficiency trades completeness for speed and clarity. This is valuable only when the missing scope is genuinely nonessential or safely deferrable.

It trades broad edge-case coverage for lower burden. That tradeoff can be dangerous if rare cases involve high harm, legal obligation, or vulnerable users.

It trades stakeholder satisfaction for focus. Some stakeholders may feel ignored when their preferred additions are deferred, even if the core solution is sufficient.

It trades mature appearance for adaptability. A smaller solution may look less impressive than a comprehensive design, even when it is more usable and easier to improve.

prose_invariants_to_preserve:
The solution must preserve its core function. It must still do the job it exists to do.

It must preserve safety, legality, accessibility, equity, privacy, auditability, and reliability where those matter. These constraints are part of sufficiency, not optional enhancements.

It should preserve operational usability. The intended users and operators must be able to understand, adopt, and maintain it.

It should preserve an expansion path. Starting small is safer when the system can add capability, control, documentation, or capacity as evidence arrives.

It should preserve accountability for deferral. Excluded scope should be visible, reasoned, and reviewable.

prose_target_outcomes:
The immediate target outcome is faster responsible delivery: the core need is served without waiting for optional scope.

The second target outcome is reduced implementation and maintenance burden. Fewer parts mean fewer things to train, document, debug, govern, and revise.

The third target outcome is a clearer solution boundary. Stakeholders can see what is required now, what is deferred, and what evidence would justify expansion.

The fourth target outcome is reduced overengineering. Speculative features and controls stop blocking action.

The fifth target outcome is improved adaptability. A smaller solution is often easier to change when requirements, users, or constraints become clearer.

prose_parameter_dimensions:
The main tuning dimension is the strictness of the sufficiency threshold. A looser threshold favors speed and low burden; a stricter threshold favors completeness, safety, and confidence.

A second dimension is reversibility. If omitted scope can be added later cheaply, the minimum can be smaller. If expansion is expensive or impossible, the initial solution should include more future-critical capacity.

A third dimension is edge-case tolerance. Low-stakes, common-case solutions can sometimes rely on simple exception handling. High-stakes systems need stronger tail coverage, appeal paths, or reserves.

A fourth dimension is stakeholder tolerance. Some contexts accept staged delivery; others require visible completeness, legitimacy, or ceremonial robustness before the solution can be trusted.

A fifth dimension is maintenance capacity. A minimum that is easy to build but hard to maintain is not truly sufficient.

prose_variants_and_near_names:
Recognized variants include Minimum Viable Process, Essential Feature Set, Minimum Viable Documentation, and Simple Intervention Package. These remain under the parent when they use the same logic: define the requirement, preserve invariants, remove nonessential scope, test sufficiency, and preserve an expansion path.

Near names include Minimum Viable Solution, Minimum Necessary Solution, Right-Sized Solution, and Minimum Viable Scope. MVP language should be used carefully. A product MVP is often a mechanism or a learning-release variant, not the whole archetype.

Promotion candidates include Minimum Viable Learning Release and Satisficing Threshold Design. Reconciliation controls preserve them by decision stage, so this draft records them without silently collapsing them.

Minimum Viable Process

short_definition: Use the smallest process that reliably performs the required coordination, control, or governance function.

distinctive_feature: The solution being minimized is a process rather than a product, policy, model, or physical artifact.

distinct_from_parent: The parent can apply to any solution; this variant applies sufficiency logic to recurring procedural structure.

still_same_parent_because: The same test governs it: retain only the steps needed to satisfy the core requirement and protected invariants.

source_primes: minimalism parsimony function

use_when: A workflow or governance routine has accumulated steps, meetings, forms, approvals, or handoffs beyond what the function requires.

use_when: The system needs repeatability but not a heavyweight process architecture.

use_when: A team needs to reduce operational burden while preserving accountability, safety, or compliance invariants.

Core Requirement

role: Defines the function the process must perform.

Nonessential Feature Filter

role: Removes procedural steps that do not support the core requirement.

Review Trigger

role: Signals when the process needs additional control or simplification.

Minimum Viable Process

role: Implements a lean recurring workflow.

Scope-Cut Review

role: Reviews steps and deliverables for removal or deferral.

example_domains:
operations
governance
education administration
clinical workflow

domain: operations

example: A team replaces a multi-stage approval routine with one review and one exception path while preserving auditability.

domain: education administration

example: A school uses the few required intake questions and one escalation rule instead of a long form that delays support.

failure_modes: May remove control steps that are rare but necessary for accountability or safety.

failure_modes: May turn into informal improvisation if the minimum process is not explicit enough to repeat.

Essential Feature Set

variant_type: subtype

short_definition: Define the smallest set of features or capabilities that lets the solution satisfy the core user or system need.

distinctive_feature: The minimized object is a capability or feature inventory, with sufficiency tested against the core need.

distinct_from_parent: The parent includes processes, policies, interventions, and documentation; this variant focuses on feature scope.

still_same_parent_because: It preserves the same minimum-sufficiency logic and expansion path rather than becoming pure feature pruning.

use_when: Feature requests are expanding beyond the core job the solution must perform.

use_when: Delivery is delayed because useful additions are treated as launch requirements.

use_when: A product, service, form, or interface needs a clear boundary between required capability and optional enhancement.

Core Requirement

role: Anchors the feature list in the need being served.

Sufficiency Test

role: Checks whether the feature set can satisfy the requirement.

Deferred Enhancement Backlog

role: Keeps nonessential additions visible without making them launch requirements.

Essential Feature Set

role: A scoped list of required capabilities.

Must/Should/Could Filter

role: Separates launch-critical features from deferrable enhancements.

example_domains:
software product design
public forms
service design
hardware design

domain: public forms

example: A benefits form keeps only the fields needed to determine eligibility and routes unusual cases to review.

domain: hardware design

example: A field device ships with the few controls needed for safe operation rather than every diagnostic option.

failure_modes: May treat accessibility, safety, or support features as optional because they are not visible to the primary builder.

failure_modes: May defer integration work that later becomes more expensive than including it early.

Minimum Viable Documentation

short_definition: Create the smallest documentation package that lets the intended users operate, maintain, audit, or hand off the solution safely.

distinctive_feature: The minimized solution is a support representation rather than the operating solution itself.

distinct_from_parent: The parent minimizes any solution; this variant minimizes the documentation needed for safe use and transfer.

still_same_parent_because: Documentation remains sufficient only if it supports the core requirement and protected invariants of use.

source_primes: minimalism representation compression

use_when: Documentation work is delaying delivery or becoming unreadable through excess detail.

use_when: Users need enough guidance to act without needing a comprehensive manual.

use_when: A team needs to preserve handoff, maintenance, or compliance information without documenting everything.

Core Requirement

role: Defines what users must be able to do with the documentation.

Sufficiency Test

role: Checks whether a user can act correctly from the documentation.

Review Trigger

role: Signals when omissions have begun to create errors or support burden.

Minimum Viable Documentation

role: A compact documentation package focused on necessary operation and handoff.

Quick-Start Guide

role: Gives the smallest action-oriented guide for common use.

example_domains:
software operations
manufacturing
education
policy implementation

domain: software operations

example: A service ships with a runbook for the top failure modes and escalation contacts instead of a complete internal history.

domain: policy implementation

example: A policy rollout includes the rule, eligibility test, exceptions, and escalation path, not every drafting rationale.

failure_modes: May hide rationale needed for future maintenance or audit.

failure_modes: May support common cases but leave users stranded during rare failures.

Simple Intervention Package

short_definition: Bundle the few intervention elements required to produce the target effect while leaving optional supports out until needed.

distinctive_feature: The minimized object is an intervention bundle whose components must work together to produce an effect.

distinct_from_parent: The parent covers all solution types; this variant emphasizes causal intervention packages and implementation capacity.

still_same_parent_because: The package is still judged by whether it satisfies the core requirement while preserving protected invariants.

use_when: An intervention is being overdesigned with many mutually dependent elements.

use_when: Implementation capacity is limited and the core causal path is reasonably understood.

use_when: The team needs a package simple enough to train, deliver, monitor, and adapt.

Core Requirement

role: Names the target effect and minimum delivery need.

Preserved Invariant Set

role: Protects safety, equity, legality, and fidelity constraints.

Expansion Path

role: Allows extra supports to be added when delivery evidence shows they are needed.

Simple Intervention Package

role: Implements a small coordinated set of intervention elements.

Pilotable Solution

role: Tests whether the package is sufficient in a controlled context.

example_domains:
public health
education
organizational change
community programs

domain: public health

example: A clinic starts with reminder calls and a simple appointment script before adding a full care-management platform.

domain: organizational change

example: A team launches one decision template and one review cadence instead of a complete operating-model redesign.

failure_modes: May omit enabling supports that are essential for uptake in under-resourced contexts.

failure_modes: May oversimplify a multi-causal problem into a package too small to produce the target effect.

near_names:
Minimum Viable Solution
Minimum Necessary Solution
Right-Sized Solution
Minimum Viable Product
Minimum Viable Scope
Pilotable Solution


Minimum Viable Learning Release

type: archetype

source: generated

batch: First Iteration/Batch 46

aliases:
Minimum Viable Release
Learning MVP
Minimum Viable Solution Release
Minimum Viable Learning Unit
Smallest Usable Learning Release

source_primes: mvp feedback design_for_implementation minimalism

slug: feedback

slug: iteration

slug: uncertainty

slug: parsimony

components:
Core User Need
Minimum Viable Scope
Viable Value Threshold
Real Context Release
Learning Signal
Expansion or Pivot Criteria
Target Use Case
Participant or Rollout Boundary
Measurement Window
Support Boundary
Safety or Ethics Guardrail
Learning Record

mechanisms:
Minimum Viable Product
Pilot Service
Concierge Test
Alpha Release
Limited Cohort Rollout
Small-Batch Policy Pilot
Minimum Viable Process
Feature-Flag Release

essence_one_line: Release the smallest usable solution that can validate core need and guide the next design step.

compression_statement: When full buildout is premature, define a minimum viable release that delivers enough real value to be used in context, captures a decisive learning signal, and triggers an explicit expand, pivot, revise, or stop decision.

core_intuition: A stripped-down solution is not valuable merely because it is small. It becomes valuable when it is small in the right way: complete enough to test the core need in reality, narrow enough to remain reversible, and instrumented enough to change the next decision.

canonical_formula: core need → minimum viable scope → real context release → learning signal → expand / pivot / revise / stop criterion

structural_problem: A solution expands in scope, polish, infrastructure, or institutional commitment before its core need, demand, user behavior, workflow fit, or operating logic has been validated in a real context.

condition: The team can deliver a narrow real version before full buildout.

why_it_matters: A real release can test demand and use before major resources are committed.

condition: The core need is plausible but still unvalidated.

why_it_matters: The solution may solve a problem that users, beneficiaries, or implementers do not actually prioritize.

condition: Scope is expanding because stakeholders are adding desirable but nonessential features.

why_it_matters: Scope creep can hide whether the essential value proposition works.

condition: The next step would create sunk cost, political lock-in, technical debt, or operational dependency.

why_it_matters: A minimum release preserves reversibility while still producing evidence.

condition: Feedback from mockups or interviews is no longer enough.

why_it_matters: The team needs evidence from actual use, not only stated preference or simulated behavior.

symptom: The roadmap contains many features, workflows, or integrations, but no clear answer to what must be true for the solution to deserve expansion.

interpretation: The team is building without a learning threshold.

symptom: Users say the concept sounds useful, but no one has relied on even a narrow version of it.

interpretation: Desirability has not yet been tested as behavior.

symptom: Sponsors ask for full polish before the core workflow has survived real use.

interpretation: Presentation quality is being confused with validated value.

symptom: A pilot exists, but its success criteria are vague or purely activity-based.

interpretation: The release may become demonstration theater rather than a learning release.

symptom: Every stakeholder adds one more prerequisite before launch.

interpretation: The minimum viable scope has not been protected from expansion pressure.

root_tension: The release must be small enough to preserve speed, reversibility, and scope discipline, but real enough that use, demand, friction, and operational consequences can be observed honestly.

case: The core need and operating model are already validated, and the issue is ordinary delivery execution.

why_not: The team likely needs implementation planning, scaling, or quality control rather than a learning release.

case: A partial release would create unacceptable harm, rights violations, safety exposure, or irreversible consequences.

why_not: Use simulation, expert review, formal assurance, or guarded piloting before exposing a partial solution to real users.

case: The proposed minimum version cannot deliver any real value or credible experience.

why_not: That is a prototype, concept test, or fake-door test, not a viable release.

case: The organization has already decided to scale regardless of evidence.

why_not: Without a real decision link, the release is a staged rollout or political demonstration rather than a learning archetype.

structural_intervention: Identify the core need, define the smallest coherent scope that can satisfy it in real context, release within explicit boundaries, observe a learning signal, and use pre-set criteria to expand, revise, pivot, or stop before broader commitment.

action: Name the core user or beneficiary need.

purpose: Anchor the minimum around value, not around technical convenience or internal preference.

action: Define the minimum viable scope.

purpose: Include only what is necessary to deliver the core value and expose the decisive uncertainty.

action: Set a viable value threshold.

purpose: Ensure the release is real enough, safe enough, and complete enough to generate valid evidence.

action: Choose the real context and rollout boundary.

purpose: Expose the solution to actual use while limiting risk, scale, and commitment.

action: Capture the learning signal.

purpose: Observe behavior, demand, workflow fit, support burden, error, retention, outcomes, or other evidence tied to the core uncertainty.

action: Apply expansion, pivot, revise, or stop criteria.

purpose: Turn learning into a decision rather than treating the release as a milestone by itself.

action: Record what changed and what remains uncertain.

purpose: Preserve the logic of the next iteration or expansion decision.

rule: Define viability by real core value, not by the smallest buildable artifact.

reason: A too-thin release produces invalid feedback because users are reacting to incompleteness rather than the core value proposition.

rule: Cut scope until removing anything else would invalidate the learning signal or make the release unusable.

reason: The minimum should be lean, but not hollow.

rule: Use the realest safe context available for the question being asked.

reason: The archetype depends on evidence from use, demand, workflow, or operation, not only opinion.

rule: Choose signals before release.

reason: Predefined signals reduce retrospective rationalization and launch-success bias.

rule: Escalate only when evidence meets the expansion criteria.

reason: The release protects against premature commitment only if scale-up is evidence-gated.

rule: Stop or pivot when the core need, use behavior, or operating logic fails under fair conditions.

reason: Learning has value only if negative evidence can change direction.

invariant: Core need anchoring

why_preserve: The release must test whether the essential need is real, not whether an arbitrary feature subset can be shipped.

invariant: Usable minimum

why_preserve: The release must deliver enough value that behavior and consequences are meaningful.

invariant: Real-context evidence

why_preserve: The archetype loses force if learning comes only from internal guesses or non-useful demonstrations.

invariant: Explicit decision linkage

why_preserve: The evidence must govern expand, revise, pivot, or stop decisions.

invariant: Bounded exposure

why_preserve: Scale, participant set, duration, or context should remain bounded until learning justifies expansion.

invariant: Mechanism humility

why_preserve: MVPs, pilots, alpha releases, and feature flags are implementation mechanisms, not the archetype itself.

outcome: Validated or invalidated core need

indicator: Real users, beneficiaries, or implementers show whether the minimum release solves a meaningful problem.

outcome: Reduced premature scope expansion

indicator: Nonessential features and infrastructure are delayed until evidence supports them.

outcome: Faster evidence-based decision cycles

indicator: The team makes an expansion, revision, pivot, or stop decision after the release window.

outcome: Improved implementation fit

indicator: Operational friction, support burden, adoption barriers, and workflow mismatches surface early.

outcome: Lower sunk-cost exposure

indicator: Large investments, policy commitments, and scaling decisions are postponed until after real learning.

prose_essence:
Minimum Viable Learning Release is the intervention pattern for learning from a real but deliberately narrow release before committing to full buildout. It is not simply “ship less.” The release must be small in a disciplined way: it must satisfy a core need, operate in a real context, generate evidence, and force a decision about whether to expand, revise, pivot, or stop.

The useful minimum is therefore not the smallest artifact the team can produce. It is the smallest usable solution that can tell the truth about the core need. A mockup may reveal comprehension. A prototype may reveal interaction problems. A minimum viable learning release reveals whether people can actually use, rely on, or operate the solution in bounded reality.

prose_when_to_use:
Use this archetype when a team is tempted to build the full version before the basic value proposition, demand, workflow fit, or implementation logic has survived real use. It is especially useful when the next investment would create technical debt, political lock-in, operational dependency, or reputational exposure.

It works best when a narrow release can still provide real value. A single use case, one cohort, one site, one benefit type, one workflow, or one customer segment may be enough if it genuinely exercises the core logic. It is weak when a partial release would be unsafe, deceptive, too incomplete to be meaningful, or unable to change the next decision.

prose_structural_problem:
The structural problem is premature buildout. A solution expands before its essential assumptions have encountered reality. Teams add features, integrations, governance layers, polish, or scale because they feel necessary, impressive, or politically reassuring. Yet the most important question remains unresolved: does the core solution meet a real need under actual conditions?

This creates a familiar trap. By the time the team learns that the need was misunderstood, the workflow does not fit, or the implementation burden is too high, the design has become expensive to change. The organization then defends the investment rather than learning from the release.

prose_intervention_logic:
The intervention begins by naming the core need. The team then defines the smallest coherent scope that can satisfy that need and reveal the decisive uncertainty. The release boundary is deliberately narrow, but the experience must be viable enough to produce valid evidence. That release is placed in a real context, often with bounded users, duration, geography, eligibility, or feature exposure.

The learning signal is chosen before release. It may be adoption, continued use, task completion, demand, willingness to pay, staff burden, error rate, equity impact, support load, retention, or observed behavior. Once the measurement window closes, the team applies pre-set criteria: expand if evidence is strong, revise if the need is real but the design is weak, pivot if the need or use case is misframed, and stop if the core assumption fails.

prose_key_components:
### Core User Need

The core user need is the smallest real problem the release must solve. It keeps the minimum from becoming arbitrary. A release that is easy to ship but irrelevant to the user's actual need is not viable learning; it is just a convenient subset.

### Minimum Viable Scope

Minimum viable scope draws the release boundary. It includes what is needed for a truthful use experience and excludes everything that does not affect the learning decision. The art is to cut scope without cutting away the conditions that make the feedback valid.

### Viable Value Threshold

The viable value threshold prevents hollow releases. A release can be narrow, rough, or manually supported, but it must provide enough usefulness, safety, reliability, and completeness that user behavior means something.

### Real Context Release

Real context release distinguishes this archetype from pure prototyping. The release operates in a real or sufficiently real setting where users, implementers, constraints, and consequences can appear. It does not merely ask people what they think; it lets them use or operate something bounded but real.

### Learning Signal

The learning signal defines what evidence will be read from the release. Good signals are tied to the core uncertainty. They are not vanity metrics, activity counts, or general satisfaction scores unless those measures actually govern the next decision.

### Expansion or Pivot Criteria

Expansion or pivot criteria close the loop. They determine what evidence will justify scaling, revising, narrowing, pausing, or stopping. Without this component, a minimum viable release becomes a launch milestone rather than an evidence-generating intervention.

prose_common_mechanisms:
Minimum viable products are product-domain mechanisms for this archetype. They instantiate the pattern only when they deliver real core value and create learning about actual use. A poorly built product labeled “MVP” is not automatically this archetype.

Pilot services implement the archetype by delivering a limited version of a service to a bounded population or location. Their value depends on whether the pilot has explicit learning and decision criteria rather than becoming a symbolic demonstration.

Concierge tests use manual or semi-manual delivery to test value before automation exists. They are powerful when the team needs to learn whether the outcome matters before building infrastructure, but they can overstate scalability if manual support is hidden or exceptional.

Alpha releases, limited cohort rollouts, feature-flag releases, and small-batch policy pilots all control exposure while creating real-use evidence. These mechanisms should be selected by the kind of context that needs to be tested: product adoption, service burden, policy impact, operational fit, or workflow integrity.

Minimum viable processes apply the archetype to operations and organizations. The release unit is a workflow rather than a product: a smallest process that does real work and reveals handoffs, role burden, exception patterns, and throughput.

prose_failure_modes:
A common failure mode is the hollow minimum: the team removes so much that users cannot experience the core value. Negative feedback then reflects underbuilding rather than the solution's true potential.

Another failure mode is launch theater. The team celebrates release activity without allowing evidence to change the roadmap. The release becomes a milestone, not a learning intervention.

Scope creep before learning is the opposite problem. The team keeps adding “must-have” features until the minimum has become a near-full build. Learning arrives late and expensively.

Friendly-cohort bias can also distort interpretation. Early adopters, insiders, or unusually tolerant users may make the release look more viable than it will be later.

Manual-support illusion appears when exceptional concierge effort makes the early release succeed in a way the scalable solution cannot reproduce. This is not always bad, but the team must name what was validated: value, not yet scale.

prose_neighbor_distinctions:
Minimum Sufficient Solution is about satisfying a requirement with the smallest adequate solution. Minimum Viable Learning Release is about learning from the smallest usable release in real context.

Rapid Prototype Learning Loop is about testing a design assumption with a low-cost artifact. Minimum Viable Learning Release is about releasing something usable enough to produce behavioral and operational evidence.

Satisficing Threshold Design is a decision rule for good-enough closure. This archetype is a release structure for validating need and guiding expansion.

Staged Commitment sequences investment. This archetype is a specific evidence-producing gate inside staged commitment.

Implementation Feasibility Alignment adapts designs to real-world constraints. This archetype tests a minimum real version to reveal whether the constraints, capabilities, and workflows actually fit.

prose_cross_domain_examples:
In product development, a scheduling product may begin with only reminders and manual rescheduling to learn whether users rely on the core workflow before calendar integrations are built.

In service design, a nonprofit may operate a limited neighborhood service manually before investing in a citywide platform.

In policy, a city may pilot a simplified permit process for one permit category while measuring completion time, error rates, staff burden, and applicant experience.

In training, a company may release a short onboarding path to one role before redesigning the entire curriculum.

In internal operations, a team may trial a lightweight incident-review workflow in one product line before formal governance is created.

prose_non_examples:
A landing page for a nonexistent service is not this archetype because it does not deliver real value. It may be a demand test or fake-door experiment.

A prototype shown in a workshop is not this archetype because it does not operate as a usable release in real context.

A stripped-down public launch with no learning signal is not this archetype because minimal scope alone is insufficient.

A pilot that expands automatically regardless of evidence is not this archetype because the learning signal does not govern the next decision.

prose_tradeoffs:
The central tradeoff is between speed and validity. Smaller releases are faster, but if they are too thin they generate misleading evidence. Bounded cohorts reduce risk, but may not represent broader users. Manual delivery can validate value, but may hide scalability problems. Real context produces stronger evidence, but also creates ethical and operational responsibility for participants.

The archetype therefore requires judgment: make the release small enough to learn quickly, but complete enough to be fair to the idea and safe for the people exposed to it.

prose_invariants_to_preserve:
Preserve core need anchoring. The release exists to validate a need, not to prove that the team can launch something.

Preserve usable minimum. Minimal scope is acceptable only if the release still delivers enough value to produce meaningful behavior and feedback.

Preserve real-context evidence. The archetype depends on interaction with actual use conditions, not only interviews, internal opinions, or demonstrations.

Preserve explicit decision linkage. The evidence must govern what happens next: expand, revise, pivot, pause, or stop.

Preserve bounded exposure. Users, geography, duration, features, or operating contexts should remain bounded until evidence justifies expansion.

prose_target_outcomes: A good minimum viable learning release validates or invalidates the core need earlier than a full launch would. It reduces wasted build effort by delaying nonessential scope until evidence supports it. It reveals workflow, support, adoption, and implementation problems while they are still cheap enough to address. It also creates a disciplined stop point: if the release fails under fair conditions, the team can redirect before commitment hardens.

prose_parameter_dimensions:
The first tuning dimension is scope narrowness. A narrower release learns faster and costs less, but an overly narrow release may fail because it lacks the context required for real use.

The second dimension is context realism. More realism increases evidence quality but also increases risk, cost, and coordination burden. High-stakes domains need stronger safeguards or simulations before real exposure.

The third dimension is cohort boundary. A small friendly cohort may protect the organization while producing biased evidence. A more representative cohort improves generalizability but increases support and risk.

The fourth dimension is support transparency. Manual support can make a release viable, but the team must distinguish value validation from scalability validation.

The fifth dimension is decision threshold. Loose criteria encourage rationalization; overly strict criteria may kill a promising direction before it has had a fair test.

prose_variants_and_near_names:
Concierge Learning Release uses manual delivery to make the minimum viable before automation exists. Limited-Cohort Learning Release controls exposure through a bounded group. Policy Pilot Learning Release adapts the archetype to public or institutional contexts where legitimacy, equity, and safeguards matter. Minimum Viable Process Release applies the pattern to workflows and operations rather than products.

Near names include MVP, minimum viable product, pilot launch, alpha release, beta release, and minimum viable process. These names should be treated as mechanisms or variants unless they include the full structure: core need, viable scope, real-context release, learning signal, and expansion/pivot/stop criteria.

Concierge Learning Release

short_definition: Deliver the core value manually or semi-manually to learn whether the value proposition is real before building scalable machinery.

distinctive_feature: The minimum release is viable because human support substitutes for missing systems while preserving a real user outcome.

distinct_from_parent: The parent can use many release forms; this variant specifically uses manual delivery as temporary implementation scaffolding.

still_same_parent_because: The decisive structure is still a smallest real release that generates learning for expand, pivot, or stop decisions.

source_primes: mvp feedback design_for_implementation

condition: The core value can be delivered with human effort before automation or infrastructure exists.

condition: The team needs evidence of need, workflow fit, or willingness to engage before investing in full buildout.

condition: The manual support can be disclosed, bounded, and operated safely.

Support Boundary

role: Names what manual support is being used and where it stops.

Core User Need

role: Keeps the manual effort focused on the real value being tested.

Learning Signal

role: Determines whether manual fulfillment shows enough evidence to justify building infrastructure.

Concierge Test

mechanism_type: workflow

Manual Service Pilot

mechanism_type: procedure

domain: Internal tools

example: A team manually prepares weekly reports for one department before building an automated dashboard.

domain: Services

example: A new advising service is delivered by staff to a small cohort before the scheduling platform is built.

failure_mode: Users value the unusually high human support rather than the eventual scalable solution.

failure_mode: The team hides manual fulfillment in a way that creates trust, privacy, or consent problems.

Limited-Cohort Learning Release

short_definition: Release the minimum viable solution to a bounded cohort so real-use evidence is obtained without full-scale exposure.

distinctive_feature: The minimum is controlled by exposure boundary as much as by feature scope.

distinct_from_parent: The parent emphasizes smallest viable scope; this variant emphasizes bounded scale and controlled rollout.

still_same_parent_because: The release still delivers real value and produces a learning signal for the next design decision.

source_primes: mvp feedback constraint

condition: Full rollout would create operational, reputational, financial, safety, or coordination risk.

condition: A small group can generate evidence about adoption, value, friction, and support requirements.

condition: The cohort boundary does not distort the core use case beyond usefulness.

Participant or Rollout Boundary

role: Limits initial exposure to a meaningful group.

Measurement Window

role: Defines when evidence from the cohort will be interpreted.

domain: Training

example: A course redesign is released to one cohort before the full program changes.

domain: Software

example: A new capability is enabled for a small customer segment before global release.

failure_mode: The cohort is too friendly or unusual, so success does not generalize.

failure_mode: The boundary becomes permanent under the name of learning.

Policy Pilot Learning Release

short_definition: Implement a bounded policy or program version in a real jurisdiction, unit, or population to validate core need and operating logic.

distinctive_feature: The release is constrained by governance, equity, legitimacy, and public accountability requirements.

distinct_from_parent: The parent is cross-domain; this variant applies the same logic to public or institutional decisions where partial rollout has legitimacy implications.

still_same_parent_because: The pilot still functions as a minimum viable real-context release designed to guide expand, revise, or stop decisions.

condition: A policy or public-service design can be tried under bounded authority, geography, duration, or eligibility rules.

condition: The learning signal includes implementation burden, beneficiary experience, unintended effects, or compliance behavior.

condition: The pilot has safeguards against inequitable access, rights impacts, or political lock-in.

Safety or Ethics Guardrail

role: Protects participants and legitimacy during bounded policy exposure.

Expansion or Pivot Criteria

role: Determines whether the policy should expand, change, or stop.

Small-Batch Policy Pilot

mechanism_type: protocol

domain: Public services

example: A benefits-navigation process is tested in two offices before being adopted statewide.

domain: Education policy

example: A new advising requirement is piloted with one program before becoming a graduation policy.

failure_mode: The pilot becomes a symbolic demonstration with no real criteria for expansion or stopping.

failure_mode: Bounded access creates unfair treatment or excludes the people whose experience matters most.

Minimum Viable Process Release

short_definition: Run the smallest operational process that can satisfy a core need and reveal workflow fit before formalizing or scaling it.

distinctive_feature: The viable unit is an operating process, not a product artifact.

distinct_from_parent: The parent includes products, services, policies, and tools; this variant focuses on workflow viability and operating burden.

still_same_parent_because: It still releases a minimum real solution to learn before wider commitment.

condition: The solution is a workflow, service operation, internal routine, or organizational process rather than a product.

condition: The team must learn about handoffs, timing, role burden, exceptions, or support needs.

condition: The process can be safely bounded while still doing real work.

Real Context Release

role: Ensures the process is run in an actual workflow.

Learning Signal

role: Tracks adoption, burden, handoff failures, quality, and throughput.

domain: Healthcare operations

example: A new referral workflow is run by one clinic before being embedded across a network.

domain: Internal operations

example: A lightweight approval process is tried by one team before becoming organizational policy.

failure_mode: The process works only because exceptional attention is being paid during the trial.

near_names:
Minimum Viable Product
MVP
Learning MVP
Pilot Launch
Alpha Release
Minimum Viable Process


Missingness-Aware Estimator Selection

batch: Second Iteration/Batch 08

aliases: missingness mechanism estimator matching

alias_records: missingness mechanism estimator matching

slug: validation

slug: causality

slug: confounding

slug: robustness

slug: counterfactuals

components:
Missingness Pattern Inventory
Missingness Mechanism Assumption Frame
MCAR Assumption Validation Check
Observed-Covariate Support Model
Estimator–Identification Match
Estimand Preservation Statement
Sensitivity and Tipping-Point Plan
Diagnostic Trace and Reporting Record
Auxiliary Variable Strategy
Positivity or Overlap Check
Imputation Model Congruence Check
Analysis Path Registry

mechanisms: Full-Information Maximum Likelihood Path

essence_one_line: Choose the missing-data estimator only after stating why values are absent and what assumption makes the target estimand recoverable.

compression_statement: Missingness-Aware Estimator Selection turns incomplete data from a generic cleanup problem into an inference-design problem: first represent the missingness pattern and response mechanism, then choose complete-case analysis, likelihood, multiple imputation, inverse-probability weighting, doubly robust adjustment, or MNAR sensitivity modeling according to the assumption that identifies the estimand.

core_intuition: A missing value is not just an empty cell. It is evidence that the observation process interacted with people, devices, institutions, time, incentives, health, risk, or the outcome itself. An estimator is trustworthy only to the extent that its missingness assumption matches that response process or transparently bounds what remains unidentified.

canonical_formula: Given response indicator R, outcome Y, observed covariates X, unobserved drivers U, and estimand θ, select estimator E only if assumption A about P(R | Y, X, U) identifies θ under available support; otherwise report θ across sensitivity scenarios S rather than as a single unqualified estimate.

structural_problem: An analysis must estimate a target quantity from incomplete data, but the chosen estimator may be valid only under a missingness mechanism that has not been stated, checked, or sensitivity-tested.

trigger_conditions: Outcomes, covariates, units, events, waves, readings, or follow-up measurements are missing or partially observed.

trigger_conditions: The missingness pattern may differ across groups, time periods, treatment arms, devices, locations, or response channels.

trigger_conditions: Complete-case analysis, listwise deletion, simple fill-in, default imputation, or software defaults are being considered without explicit mechanism justification.

trigger_conditions: The target estimand could change if incomplete cases are excluded or differentially weighted.

trigger_conditions: The absence process may depend on observed covariates, prior values, administrative rules, device failures, respondent behavior, or unobserved outcomes.

trigger_conditions: A result will inform a high-stakes claim, policy, product decision, scientific inference, safety conclusion, or resource allocation.

symptoms: Reports state how many observations were dropped but not why those observations were missing.

symptoms: Analysts use complete-case analysis because it is convenient rather than because MCAR or estimand preservation is plausible.

symptoms: Multiple imputation is used as a generic repair tool even when the imputation model omits key predictors, interactions, time structure, or outcome-dependent dropout risk.

symptoms: Inverse-probability weights are unstable because some response probabilities are near zero or overlap is weak.

symptoms: A single adjusted estimate is reported even though non-ignorable missingness could reverse the conclusion.

symptoms: Different analysts choose different missing-data methods and obtain different answers without a principled selection rule.

root_tension: Simpler estimators are easier to explain and audit, but they often require stronger missingness assumptions. More flexible estimators can reduce bias under richer assumptions but add modeling choices, variance, opacity, and sensitivity to misspecification. The design must preserve the estimand while making assumptions visible enough to challenge.

anti_signatures: The data are complete or missingness is irrelevant to the target quantity.

anti_signatures: The task is a data-quality repair or collection-improvement problem with no inferential estimand yet defined.

anti_signatures: Absence represents a true zero, structural non-applicability, censoring rule, truncation rule, or design feature that requires a different modeling frame before treating it as missing data.

anti_signatures: The main threat is measurement error, confounding, or sampling nonrepresentativeness unrelated to incomplete observation.

anti_signatures: No estimator choice is being made and the only appropriate action is transparent descriptive reporting of observed cases.

structural_intervention: Inventory missingness, state a mechanism assumption, verify support for that assumption, match the estimator to the identifying condition, and report sensitivity bounds when the mechanism cannot be justified.

action_logic: Define the estimand, target population, outcome, covariates, timing, and decision context before choosing a missing-data method.

action_logic: Map missingness patterns by variable, unit, group, time, treatment arm, device, site, or process stage, and distinguish missing, not applicable, censored, truncated, and structurally absent cases.

action_logic: Form candidate missingness mechanisms using both statistical diagnostics and process knowledge: MCAR, MAR conditional on observed variables, MNAR/non-ignorable, or mixed mechanisms across variables or waves.

action_logic: Evaluate whether observed covariates, prior measurements, auxiliary variables, and overlap can support the intended estimator.

action_logic: Choose the estimator whose identifying assumption matches the mechanism frame: complete-case or likelihood path for defensible MCAR/ignorable cases, imputation or weighting for supportable MAR, doubly robust adjustment when both response and outcome models are useful, and sensitivity models when MNAR remains plausible.

action_logic: Check whether the estimator preserves the target estimand or silently changes the population, contrast, time horizon, or weighting scheme.

action_logic: Run diagnostics and sensitivity analyses, including tipping-point or bound-style reporting when assumptions remain fragile.

action_logic: Document the rejected paths, assumption rationale, diagnostics, estimator choice, uncertainty, and interpretation limits.

decision_rules: Do not choose complete-case analysis merely because the missing fraction is small; choose it only when excluded cases do not threaten the estimand or when the limitation is explicitly acceptable.

decision_rules: Use MAR-style imputation, likelihood, or weighting only when observed variables plausibly explain the response process and have adequate support.

decision_rules: Use doubly robust adjustment when both outcome and response models can be specified and reviewed, but do not treat double robustness as immunity to bad data or poor overlap.

decision_rules: When missingness may depend on unobserved outcomes or unmeasured causes, present sensitivity, bounds, or tipping points rather than a single overconfident estimate.

decision_rules: If different variables have different mechanisms, allow method plurality rather than forcing one global missingness label.

decision_rules: If diagnostics and process knowledge disagree, escalate to sensitivity reporting or collection-process review instead of choosing the convenient method.

target_invariants: The estimand stays explicit and is not silently replaced by the complete-case population.

target_invariants: The missingness mechanism assumption is stated as an assumption, not as a discovered fact.

target_invariants: The selected estimator and the claimed identifying condition remain aligned.

target_invariants: Model-based adjustments preserve uncertainty introduced by missingness rather than pretending completed values were observed.

target_invariants: Overlap, positivity, and support limits are visible when weighting or imputation is used.

target_invariants: Sensitivity findings are part of the result, not an appendix detached from interpretation.

expected_outcomes: Fewer analyses rely on unjustified deletion, default imputation, or hidden software assumptions.

expected_outcomes: Incomplete data are handled in a way that better preserves the intended population, contrast, and uncertainty.

expected_outcomes: Stakeholders can see which conclusions depend on MCAR, MAR, or MNAR assumptions.

expected_outcomes: Results become easier to audit because diagnostics, estimator choice, and sensitivity checks are linked in one trace.

expected_outcomes: False certainty decreases when non-ignorable missingness remains plausible.

prose_essence:
Missingness-Aware Estimator Selection is the pattern of refusing to treat missing values as merely empty cells. It asks why values are absent, what that absence implies about the observation process, and which estimator can still support the intended inference. The key move is not “fill in the data.” The key move is to align the estimator with the missingness mechanism and to show how fragile the conclusion is when that mechanism is uncertain.

A missing value can mean many things: a respondent refused, a patient dropped out, a sensor lost power, an administrator did not collect a field, a value was censored by a rule, a device failed under extreme conditions, or an outcome made follow-up less likely. Each story supports different assumptions. This archetype keeps those assumptions visible before the analysis commits to complete-case analysis, maximum likelihood, multiple imputation, inverse-probability weighting, doubly robust adjustment, or MNAR sensitivity modeling.

Complete-Case Defensibility Gate

short_definition: A conservative variant that allows complete-case or listwise deletion only when missingness and estimand-change risks are explicitly checked.

distinctive_feature: Its central decision is whether a simple estimator is defensible, not which complex correction to apply.

distinct_from_parent: Narrower than the parent because it decides whether no explicit adjustment is acceptable.

still_same_parent_because: It still conditions estimator choice on the missingness mechanism and the target estimand.

use_when: The missing fraction is modest or structurally bounded.

use_when: Complete cases plausibly represent the target estimand after diagnostics.

use_when: A simple analysis would otherwise be chosen without checking its missingness assumptions.

example_domains:
clinical registries
administrative data
sensor logs

MAR-Conditioned Imputation or Weighting

short_definition: A variant that treats missingness as ignorable only conditional on observed covariates and then uses imputation, likelihood, weighting, or hybrid adjustment.

distinctive_feature: Its key move is conditional ignorability: absence can be adjusted for only after conditioning on meaningful observed information.

distinct_from_parent: Narrower because it stays inside the MAR family of assumptions.

still_same_parent_because: It selects estimators by matching a missingness mechanism assumption to the desired inference.

use_when: Observed variables plausibly explain response or dropout.

use_when: Auxiliary variables and prior measurements are available before missingness occurs.

use_when: The analysis needs to preserve the original estimand rather than restrict itself to complete cases.

example_domains:
longitudinal studies
social surveys
economic panels

MNAR Sensitivity-Bounded Inference

short_definition: A variant that treats non-ignorable missingness as unresolved and reports conclusions across explicit sensitivity scenarios rather than pretending the mechanism is harmless.

distinctive_feature: It preserves uncertainty about the response process instead of collapsing it into a single adjusted estimate.

distinct_from_parent: Narrower because it focuses on non-ignorable missingness and sensitivity-bounded reporting.

still_same_parent_because: It remains an estimator-selection and reporting strategy driven by missing-data mechanism assumptions.

use_when: Missingness may depend on unobserved outcomes or unmeasured causes.

use_when: MAR cannot be defended from observed covariates and process evidence.

use_when: The conclusion is high stakes enough to require bounds, tipping points, or scenario analysis.

example_domains:
clinical dropout
income nonresponse
adverse-event follow-up

Longitudinal Attrition Adjustment

short_definition: A repeated-measurement variant that adjusts for dropout, intermittent missing waves, or follow-up loss while preserving time-dependent estimands.

distinctive_feature: Timing and prior-state information become central to the missingness mechanism.

distinct_from_parent: Domain-specific to longitudinal and panel designs.

still_same_parent_because: Estimator choice still depends on the missingness mechanism and estimand preservation.

use_when: Units are followed over time and response depends on prior measurements or evolving status.

use_when: Dropout could change the interpretation of trends, treatment effects, or incidence rates.

example_domains:
panel surveys
clinical follow-up
education cohorts


Misuse-Resistant Affordance Design

batch: Batch 01

canonical_family: Adversarial Hardening & Rehearsal

aliases:
Designed-Out Misuse
Misuse-Resistant Design
Abuse-Resistant Interface Design
Asymmetric Affordance Hardening
Affordance-Level Misuse Prevention
Preventive Affordance Shaping
Legitimate-Path-Preserving Hardening
Design-Out Abuse Pattern

slug: affordance

slug: interface

slug: deterrence

slug: asymmetry

slug: risk

slug: intervention

components: Proportionality and Accessibility Review

mechanisms:
Physical Keying or Interlock
Permission-Scoped Default
Constrained Input Control
Safe Default Setting
Progressive Disclosure of Risky Options
Point-of-Action Confirmation
Role-Based Access Control
Rate Limit or Cooling Hold
Exception Review Queue
Misuse Monitoring Dashboard

essence_one_line: Shape affordances and defaults so the harmful path is unavailable, costly, or unattractive while the legitimate path stays easy.

compression_statement: Misuse-Resistant Affordance Design applies when a system relies on users, operators, customers, or adversaries not taking an available harmful path. The intervention changes the action space itself: identify the legitimate path, map the misuse path, compare their relative friction, then remove, gate, delay, expose, or de-reward the misuse path while preserving the legitimate path through proportional exceptions, accessibility checks, and feedback from real workarounds.

core_intuition: The best enforcement is often not better punishment after the wrong action but a better-shaped environment before it. A good design does not merely say “do not misuse this”; it makes the desired use the path of least resistance and makes the damaging path hard to reach, hard to repeat, or impossible to complete.

canonical_formula: misuse_risk_after_design = f(misuse_path_availability × misuse_path_friction × legitimate_path_preservation × exception_quality × adaptation_feedback)

structural_problem: A harmful, erroneous, abusive, or off-label action remains available and low-friction inside the ordinary action space, while prevention depends on vigilance, rules, detection, deterrence, or punishment after the fact. Broad restrictions can reduce harm, but they also burden legitimate users and create workarounds.

trigger_conditions: A predictable misuse or error path is materially available to ordinary users, operators, customers, insiders, or adversarial actors.

trigger_conditions: The organization is relying on training, policy, signs, warnings, monitoring, or punishment even though the harmful path could be structurally redesigned.

trigger_conditions: The legitimate path can be made easier, clearer, or more available than the misuse path without blocking core work.

trigger_conditions: Misuse occurs at a point of action where defaults, permissions, sequences, shapes, labels, or interface affordances can be changed.

trigger_conditions: Prevented harm is significant enough to justify added friction, but blanket denial would be disproportionate or inaccessible.

trigger_conditions: There is evidence of repeated bypass, support burden, near misses, abuse, fraud, accidental error, unsafe shortcutting, or policy evasion.

trigger_conditions: The system must accommodate legitimate exceptions without converting exceptions into a new uncontrolled channel.

symptoms: Users routinely can select dangerous options faster than safe options.

symptoms: Teams respond to misuse by adding warnings, training, monitoring, or sanctions while leaving the harmful path unchanged.

symptoms: The same misuse recurs because the environment silently invites it.

symptoms: Legitimate users are burdened by broad restrictions even though the harmful path is narrower than the population being restricted.

symptoms: Support logs, incident reports, or desire-path traces show users creating unofficial workarounds around a poorly designed path.

symptoms: High-risk functions ship enabled by default or with privileges broader than ordinary use requires.

symptoms: Mistakes are blamed on users even though the interface, layout, process, or permission structure makes the mistake easy.

root_tension: The system needs openness, usability, and legitimate adaptation, but the same available action space also admits predictable misuse. The design challenge is to target the harmful path without destroying the useful path.

anti_signatures: The problem is unknown failure discovery rather than a known or predictable misuse path; failure_mode_anticipation may be closer.

anti_signatures: The main need is to express constraints explicitly, not embed them into action affordances; constraint_formulation may be closer.

anti_signatures: The intervention occurs only after a system fails; fail_safe_default may be closer.

anti_signatures: The design makes a wrong physical action impossible and nothing broader is needed; physical_constraint_design_for_impossibility may be closer.

anti_signatures: The problem is mostly unwanted variation in a process rather than asymmetric misuse of an available path; standardization_and_simplification or variance_reduction may be closer.

anti_signatures: The goal is to validate an output before it propagates; self_checking_operation may be closer.

anti_signatures: The added friction burdens legitimate users as much as misusers, with no asymmetry; that is blunt restriction, not this archetype.

structural_intervention: Reconfigure the action environment so legitimate use remains the easiest path while misuse becomes unavailable, slower, more visible, higher-cost, role-gated, reversible, or exception-routed before enforcement must act.

action_logic: Define the legitimate use cases, users, contexts, urgency levels, accessibility needs, and success criteria that must be preserved.

action_logic: Map misuse paths as concrete sequences of actions, defaults, affordances, permissions, incentives, and bypasses rather than as moral labels.

action_logic: Compare the legitimate and misuse paths for friction, visibility, reachability, reversibility, feedback, privilege level, and reward.

action_logic: Choose the least blunt structural move that changes the misuse path more than the legitimate path: removal, physical keying, permission scoping, default change, sequence constraint, confirmation, rate limit, delay, visibility, or exception routing.

action_logic: Install a legitimate exception and recovery path for rare, expert, urgent, repair, or accessibility cases.

action_logic: Test whether the redesign shifts burden onto legitimate users, creates discriminatory exclusion, or motivates uncontrolled workarounds.

action_logic: Instrument the design for residual misuse, false blocks, support burden, bypass attempts, and desire-path traces.

action_logic: Revise the affordance map as users, adversaries, and operational contexts adapt to the new action space.

decision_rules: If a risky action is unnecessary for ordinary legitimate use, remove it from the default capability set.

decision_rules: If a risky action is sometimes legitimate, gate it by context, role, sequence, delay, confirmation, or exception review instead of banning it globally.

decision_rules: If the misuse path and legitimate path share the same affordance, search for a discriminating context signal before adding uniform friction.

decision_rules: If added friction falls mostly on legitimate or accessibility-sensitive users, redesign the intervention or add an exception path before deployment.

decision_rules: If users repeatedly bypass the control for legitimate reasons, treat the bypass as evidence about the use model rather than only as noncompliance.

decision_rules: If adversaries adapt by moving to a neighboring path, update the misuse inventory and avoid pretending the original control solved the whole problem.

decision_rules: If the design relies on shame, confusion, hidden traps, or dark patterns, reject it even if it reduces measured misuse.

target_invariants: The legitimate path remains discoverable, accessible, timely, and proportionate.

target_invariants: The misuse path is burdened by construction, not only by post-hoc enforcement.

target_invariants: Exceptions are governed rather than informal backdoors.

target_invariants: The design distinguishes accidental error, opportunistic misuse, adversarial abuse, and legitimate adaptation.

target_invariants: Controls are auditable and reversible where false blocks can cause harm.

target_invariants: The intervention does not punish users for design failures that the system itself creates.

target_invariants: Feedback from real behavior is used to update the affordance map over time.

expected_outcomes: Predictable misuse becomes less frequent because the harmful path is harder to find, harder to complete, or unavailable.

expected_outcomes: Legitimate users experience less burden than they would under blanket restriction, heavy monitoring, or after-the-fact enforcement.

expected_outcomes: Recurring errors and abuse shift from user-blame problems into design-correction problems.

expected_outcomes: Exception handling becomes explicit, reviewable, and safer than informal workarounds.

expected_outcomes: Residual misuse signals become easier to interpret because the most obvious harmful paths have been structurally reduced.

expected_outcomes: Design teams gain a reusable habit of comparing path friction rather than only adding rules.

Physical Poka-Yoke Misuse Blocking

short_definition: A variant where the misuse or error path is blocked by shape, orientation, interlock, fixture, or material incompatibility.

distinctive_feature: The affordance edit is physical or material rather than primarily procedural, digital, or permission-based.

distinct_from_parent: The parent includes all asymmetric affordance/default moves; this variant covers physical impossibility and physical keying.

still_same_parent_because: It still burdens the misuse path before enforcement while preserving the legitimate path.

use_when: The wrong action is physically identifiable.

use_when: The correct action can remain easy while the wrong action is made impossible or obviously rejected.

domain: manufacturing

example: A jig allows a part to be inserted only in the correct orientation.

failure_modes: A physical block also excludes legitimate repair or accessibility cases.

failure_modes: Users bypass the interlock because exceptions are not supported.

Permission-Scoped Misuse Prevention

short_definition: A variant where risky capabilities are withheld from the default action set and released only through role, context, authorization, or review.

distinctive_feature: The misuse path is controlled by starting permissions rather than physical form.

distinct_from_parent: The parent covers any affordance/default asymmetry; this variant centers capability scoping and authority boundaries.

still_same_parent_because: It preserves ordinary legitimate use while selectively burdening risky misuse paths.

use_when: The same action is legitimate for some actors but dangerous as a default.

domain: software

example: A plugin starts with read-only access until a review grants destructive permissions.

failure_modes: Overbroad permissions recreate the misuse path.

failure_modes: Underbroad permissions generate shadow processes and informal credential sharing.

Safe Default Path Biasing

short_definition: A variant where the starting state, selected option, or easiest path is safe unless the actor deliberately and legitimately changes it.

distinctive_feature: The design mainly changes starting conditions and option ordering.

distinct_from_parent: The parent includes path removal and gating; this variant focuses on default-state asymmetry.

still_same_parent_because: It reduces misuse by changing the path of least resistance before enforcement is needed.

use_when: The harmful path depends on permissive initial settings or unchecked continuation.

domain: privacy

example: A service starts with private-by-default sharing and makes public sharing an explicit choice.

failure_modes: Default manipulation becomes paternalistic or opaque.

failure_modes: Expert users cannot efficiently reach legitimate advanced options.

near_names:
Designed-Out Misuse
Misuse-Resistant Design
Abuse-Resistant Interface Design
Poka-Yoke
Mistake Proofing
Error Proofing