Change Scoped Revalidation

After a change, re-derive only the facts inside a justified affected closure, retain the rest by a defeasible persistence presumption, and test that the boundary did not leak.

After a change, re-derive only the facts inside a justified affected closure, retain the rest by a defeasible persistence presumption, and test that the boundary did not leak.

Structural pattern

Represent the semantic delta; traverse invalidation-relevant dependencies to form the smallest defensible affected closure; revalidate members in dependency order; keep nonmembers only while their validity conditions, expiry, and exception rules remain satisfied; and use boundary-escape evidence to widen, roll back, or escalate the scope when the model proves incomplete.

The pattern answers two coupled questions after a change: what must be reconsidered, and what is still allowed to count as true. It does not solve the first by silently assuming the second. Instead, it treats the affected boundary as a falsifiable model and the unchanged remainder as a rebuttable claim.

Why this is a full archetype

A dependency graph, traceability matrix, cache invalidation rule, regression suite, or impact report can support this work, but none by itself owns the complete intervention. The transferable pattern combines semantic change representation, dependency-bounded invalidation, ordered revalidation, explicit persistence, exception ownership, and escape detection. Those responsibilities recur across software, data, engineering, policy, rule systems, and scientific modeling, with stable tradeoffs and failure modes.

Problem signature

A system changes locally, but downstream facts, artifacts, decisions, or obligations depend on that state in ways that are costly or impossible to reconsider globally. The organization therefore needs a principled boundary between what must be re-derived and what can continue to be treated as true.

The characteristic failure is not simply that dependencies are hidden. It is that a change decision has no defensible stopping rule. One organization rechecks everything and becomes unable to change; another checks only the edited object and carries stale downstream state forward. Change-scoped revalidation creates a reviewable middle path.

Trigger conditions

• A value, rule, relationship, assumption, source, interface, policy, or model version changes.
• Some outputs or commitments are derived from upstream state rather than independently observed.
• Full recomputation or review is materially costly, slow, disruptive, or cognitively infeasible.
• The consequences of missing a dependency are nontrivial enough to require a reviewable scope argument.
• A baseline state and at least partial dependency evidence are available or can be constructed.

Anti-signatures

• The change invalidates the entire model or source of authority, so there is no meaningful unaffected remainder.
• Dependencies are fundamentally unknown and consequences are catastrophic, making scoped review unjustified until discovery improves.
• Full recomputation is cheap, deterministic, and safer than maintaining a scope model.
• The task is merely to document dependencies without making a post-change validity decision.
• The intervention is only to preserve one invariant, with no need to derive an affected set.

Intervention logic

Convert a change into an auditable revalidation scope by combining a semantic delta, typed dependencies, invalidation rules, closure and ordering logic, a defeasible persistence presumption, and independent checks for effects outside the predicted boundary.

1. Anchor the review to a versioned, accepted state snapshot and its sources of truth.
2. Describe the semantic delta, including changes to values, rules, assumptions, relationships, and validity conditions.
3. Declare the dependency scope boundary, edge types, time horizon, and known blind spots.
4. Apply change-type-specific invalidation rules to identify directly affected items.
5. Traverse invalidation-relevant dependencies until a justified propagation stop condition is reached.
6. Order the affected closure by prerequisites; isolate cycles for iterative or joint resolution.
7. Revalidate each affected item with evidence proportional to criticality, uncertainty, and reversibility.
8. Retain items outside the closure only under an explicit persistence presumption and applicable exception rules.
9. Probe the boundary with sentinels, samples, broad invariants, or independent traces.
10. Record decisions, widen or roll back on escape, and schedule broad review for accumulated model drift.

The affected closure is not defined by organizational ownership, file location, or who requested the change. It follows validity-relevant dependencies. Likewise, an item outside the closure is not declared eternally true; it persists only relative to a coherent snapshot, unchanged validity conditions, and the absence of contrary boundary evidence.

Core components

Component	Description
State Snapshot ↗	Captures the last accepted state against which the change and all persistence claims are evaluated. The snapshot must identify its version, validity interval, and authoritative sources; otherwise the unchanged set has no reliable baseline.
Change Delta Record ↗	Expresses what changed semantically, including altered values, rules, relationships, assumptions, and validity conditions. A textual diff is insufficient when a small edit changes meaning or dependency structure; the record must expose the operational delta.
Dependency Scope Boundary ↗	Declares the system, fact classes, edge types, and time horizon within which change consequences will be traced. The boundary is a claim to be tested, not merely a project-management limit; excluded regions need an explicit justification.
Dependency Map ↗	Represents which claims, artifacts, decisions, or states depend on which upstream conditions. Edges should distinguish causal, logical, data-lineage, contractual, temporal, and resource dependencies where those differences affect propagation.
Persistence Presumption ↗	Treats facts outside the justified affected closure as continuing to hold unless evidence rebuts that presumption. The presumption is defeasible and confidence-bounded. It must never silently override expiry, nonlocal coupling, or a safety rule requiring full review.
Invalidation Rule ↗	Determines which dependency relations make a downstream fact stale, suspect, or conditionally reusable after a particular kind of change. Invalidation should be typed: not every dependency propagates every change, and some edges require translation rather than simple invalidation.
Affected Dependency Closure ↗	Collects the smallest justified set reachable from the change through invalidation-relevant dependencies. The closure is a review scope, not proof that everything outside it is safe; escape checks and uncertainty annotations remain necessary.
Dependency Order ↗	Sequences re-derivation so prerequisites are established before dependent facts are reconsidered. Cycles require strongly connected grouping, iteration, or escalation rather than pretending a total order exists.
Revalidation Rule ↗	Specifies what evidence is sufficient to keep, revise, replace, or withdraw each affected item. Rules should scale with criticality and uncertainty; low-risk deterministic outputs and high-stakes judgments should not share an undifferentiated check.
Source-of-Truth Reference ↗	Links each revalidated fact to the authoritative input, rule, owner, or evidence base from which it is derived. Without source references, local recomputation can preserve a stale branch while the actual authority has changed elsewhere.
Boundary Escape Check ↗	Tests whether effects appear beyond the predicted affected closure or through omitted dependency classes. Use sentinel cases, sampling, independent traces, or broad invariants to challenge the scope model before accepting persistence outside it.
Propagation Stop Condition ↗	Defines when consequence tracing may stop because downstream meaning, validity, or decision impact is demonstrably unchanged. Stopping for budget or convenience is not equivalent to demonstrating that propagation has become irrelevant.
Exception Owner ↗	Assigns responsibility for unresolved dependencies, contested persistence claims, and deliberate deviations from the normal revalidation path. Ownership prevents uncertainty from disappearing between teams and makes escalation time-bounded.
Audit Trace ↗	Records the delta, traversed paths, invalidations, retained facts, revalidation evidence, exceptions, and final acceptance decision. The trace must make both action and non-action reviewable: why an item was not rechecked is as important as why another was.

Optional components. These often strengthen the draft when the situation calls for them.

Component	Description
Uncertainty Annotation ↗	Attaches confidence and model-limit information to dependency edges and persistence decisions. Useful where dependencies are learned, incomplete, probabilistic, or socially interpreted.
Change Log ↗	Maintains the sequence of accepted deltas and their scope decisions. Helps detect cumulative interactions that individually small change reviews may miss.
Rollback or Stop Condition ↗	Defines when unexpected propagation, failed validation, or mixed-version state requires reversal or a halt. Especially important where partial updates can expose users or operations to inconsistent snapshots.
Revalidation Cadence ↗	Schedules periodic broad checks that compensate for model drift and dependencies missed by event-triggered review. Cadence should follow hazard, change rate, and evidence decay rather than a purely administrative calendar.

How the components interact

The state snapshot and change delta record establish what changed relative to what. The dependency scope boundary, dependency map, and invalidation rules convert that delta into an affected dependency closure. The dependency order and revalidation rules determine how closure members regain accepted status. The persistence presumption and source-of-truth references govern the remainder. The boundary escape check challenges the model, while the propagation stop condition, exception owner, and audit trace make stopping, uncertainty, and accountability explicit.

Common mechanisms

Dependency Graph

Encodes typed upstream-downstream relations used to traverse possible change consequences.

Most useful when edge provenance, direction, confidence, and freshness are maintained.

Impact Analysis

Interprets a change delta against dependency types and criticality to propose an initial affected set.

Human review may be needed when the delta alters semantics rather than only values.

Dependency Closure Traversal

Computes reachability through only those dependency edges whose invalidation rules match the change type.

Typed traversal avoids both indiscriminate fan-out and unjustified early stopping.

Selective Revalidation Worklist

Queues affected items in dependency-aware order, re-enqueuing downstream items when an upstream conclusion changes.

A worklist supports incremental closure while preserving explicit completion and cycle handling.

Truth-Maintenance System

Tracks justifications for beliefs and retracts or reinstates conclusions as supporting assumptions change.

Appropriate for rule-rich systems; it must expose justification quality rather than treating every stored inference as equally reliable.

Change Impact Report

Summarizes the delta, predicted closure, retained facts, revalidation results, exceptions, and residual uncertainty.

Provides a decision artifact, not a substitute for the underlying trace.

Requirements Traceability Matrix

Links changed requirements to designs, tests, controls, and operational obligations.

Particularly useful for regulated engineering and product change control.

Cache Invalidation Review

Checks whether reusable results remain valid after upstream inputs or assumptions change.

It instantiates one narrow case of persistence and invalidation; the archetype is broader than caching.

Regression Test Suite

Re-executes representative behavior checks for affected and boundary cases.

Coverage must follow the dependency hypothesis and include escape sentinels, not only known changed modules.

Boundary Escape Sampling

Samples supposedly unaffected regions or sentinel outcomes to detect consequences outside the modeled closure.

Sampling reduces but cannot eliminate miss risk; high-consequence domains may require a broader independent check.

Persistence Exception Register

Records fact classes that may not persist by default, together with expiry, owner, and required evidence.

Makes nonlocal, time-sensitive, and safety-critical exceptions visible before change review begins.

Data Diff and Merge Tool

Compares versions and supports controlled reconciliation of changed and retained records.

Useful for concrete state deltas, but semantic changes still require interpretation.

A mechanism is not the archetype. For example, selective regression testing is useful only for behavior represented by tests; a truth-maintenance system works only where justifications are encoded; and a dependency graph is only as trustworthy as its edges. Mechanism choice should follow the evidence structure, not dictate it.

Parameter dimensions

Dimension	Narrow / lightweight setting	Broad / conservative setting	Governing question
Change granularity	Single value or artifact edit	Rule, ontology, authority, or relationship change	Does the delta alter only state, or also the meaning of dependencies?
Dependency confidence	Explicit and tested edges	Inferred, stale, probabilistic, or contested edges	How much scope expansion or independent checking compensates for model weakness?
Propagation semantics	Deterministic invalidation	Conditional, delayed, nonlinear, or translated effects	Which edge types can this change actually traverse?
Consequence level	Low-cost and reversible	Safety-critical, rights-affecting, irreversible, or systemic	How much evidence and independence are required before persistence is accepted?
Revalidation depth	Automated local check	Independent analysis, simulation, stakeholder review, or recertification	What would make the item valid again?
Persistence strength	Strong default with simple exceptions	Weak default requiring affirmative evidence	What is the cost of mistakenly retaining stale state?
Temporal horizon	Immediate direct effects	Delayed, cumulative, and interaction effects	When can an apparently unaffected item become affected later?
Snapshot strategy	Eventual convergence tolerated	Atomic or staged coherent release required	Can users safely observe mixed versions?
Escape sensitivity	Sampled sentinels	Broad independent review or full recomputation	What evidence would falsify the proposed boundary?
Review cadence	Change-triggered only	Change-triggered plus periodic broad audit	How quickly can dependency and validity models drift?

Invariants to preserve

• No accepted affected item depends on an invalidated or unresolved prerequisite.
• Every retained item has an explicit and still-valid basis for persistence.
• All revalidation decisions refer to one coherent version or declared snapshot relation.
• Safety, legal, ethical, and integrity constraints remain satisfied across both changed and retained state.
• The scope decision, exceptions, and residual uncertainty remain attributable and auditable.

These invariants apply across the boundary. It is not enough for changed items to pass while retained items silently refer to an older source, expired authority, or incompatible snapshot.

Target outcomes

• Less revalidation work than a full-system review without relying on undocumented assumptions.
• Faster and more predictable change incorporation.
• Earlier detection of nonlocal consequences and mixed-version state.
• Clear ownership of exceptions and unresolved dependency uncertainty.
• Reusable evidence about which dependency types actually propagate which changes.
• A reviewable rationale for both changed and deliberately unchanged items.

Success is not measured only by how few items were rechecked. A narrow scope that misses important effects is a failure. Useful metrics combine avoided work with escape rate, stale-state incidents, time to coherent acceptance, exception age, model freshness, and the proportion of retained items with explicit persistence evidence.

Applicability

Works well when

• The system has a stable enough baseline to distinguish changed from retained state.
• At least the critical dependency paths can be represented, observed, or elicited.
• Changes recur often enough that reusable invalidation and revalidation rules are valuable.
• The cost of global review is high relative to maintaining dependency and provenance evidence.
• The organization can escalate uncertainty rather than forcing every item into affected or unaffected certainty.
• Boundary probes and periodic broad checks can independently test scope quality.

Weak when

• The change alters the ontology, governing model, or authority so broadly that prior dependencies cannot be trusted.
• Dependencies are hidden, adversarial, or rapidly changing and there is no credible escape-detection layer.
• The system is small enough that full recomputation is cheaper and more reliable.
• Outputs are not reproducible and no meaningful revalidation rule exists.
• Stakeholders use scope as a political boundary to avoid accountability for external effects.
• Temporal expiry, nonlocal coupling, or emergent behavior dominates local dependency structure.

Recognized variants

Graph-Closed Revalidation

Uses an explicit dependency graph and typed invalidation rules to compute a closed set of items requiring revalidation.

Its distinctive feature is the review boundary is derived by graph closure rather than by organizational ownership or broad manual judgment.

It remains under the parent because it preserves the same intervention logic: bound affected facts, revalidate them, and retain the remainder by a tested presumption.

Risk-Tiered Change Review

Combines dependency scope with consequence and uncertainty tiers so higher-risk items receive broader evidence and escalation.

Its distinctive feature is revalidation depth depends on consequence, reversibility, uncertainty, and exposure rather than reachability alone.

It remains under the parent because it still bounds and rechecks the affected set while preserving low-risk unaffected facts by default.

Event-Driven Incremental Recomputation

Automatically recomputes affected derived state when declared change events invalidate upstream inputs or justifications.

Its distinctive feature is scope construction and revalidation occur continuously as events arrive rather than in a periodic review episode.

It remains under the parent because the event system instantiates the same affected-closure, persistence, and revalidation structure.

Tradeoffs

• Efficiency versus completeness: narrower scopes save work but increase reliance on dependency quality and escape detection.
• Model-maintenance cost versus repeated global review: typed dependencies and invalidation rules require ongoing stewardship.
• Default persistence versus uncertainty: a strong presumption accelerates change but can normalize hidden stale state.
• Automation versus contextual judgment: automated traversal is consistent, while experts may detect semantic and political dependencies the model omits.
• Fast release versus snapshot coherence: incremental updates reduce delay but can expose mixed-version state without transaction or rollback controls.
• Local ownership versus systemic accountability: team boundaries make review manageable but must not define away cross-boundary effects.

Failure modes and mitigations

Failure mode	Cause	Mitigation
Missing dependency escape	A relevant edge, shared assumption, side channel, or stakeholder effect is absent from the dependency model.	Use provenance review, cross-functional elicitation, sentinel outcomes, boundary sampling, broad invariants, and periodic full-scope audits.
Over-invalidation storm	Every edge is treated as propagating every change, so the closure expands to the whole system.	Type change and dependency semantics, define propagation stop conditions, and learn from prior non-effects without deleting uncertainty.
Wrong dependency direction or semantics	The map records association rather than the actual condition under which validity flows.	Record edge meaning and provenance, test with known changes, and require owners to confirm critical paths.
Stale scope model	Dependencies, owners, or sources evolve without updating the map or invalidation rules.	Attach freshness metadata, update on architecture or policy change, and compare predicted with observed impacts.
Persistence beyond validity	An item lies outside the closure but has expired, lost its authority, or depends on an unstated global condition.	Check validity intervals, source references, global assumptions, and exception registers before accepting persistence.
Semantic delta under-specified	A change is represented as a textual or field-level diff that misses altered meaning, thresholds, units, or decision logic.	Require semantic change classification, examples, counterexamples, and owner review of changed validity conditions.
Cyclic revalidation deadlock	Mutually dependent items are forced into an impossible linear order or each waits for the other to become final.	Identify strongly connected groups, iterate to a justified fixed point, solve jointly, or escalate unresolved coupling.
Mixed-snapshot acceptance	Affected and retained items refer to incompatible versions or are updated nonatomically.	Use snapshot identifiers, version constraints, staged activation, transactional publication, and rollback conditions.
Ceremonial boundary check	Escape testing is designed only around known dependencies and cannot falsify the closure.	Select independent sentinels and samples, include adversarial cases, and define widening criteria before results are seen.
Scope gaming	Actors classify dependencies, risks, or organizational boundaries to minimize review burden or externalize harm.	Make scope appealable, separate approval from delivery incentives, include affected stakeholders, and audit distributional omissions.

Neighbor distinctions

Neighbor	Distinction
dependency_exposure — Dependency Exposure	Dependency Exposure makes hidden dependencies visible. Change-Scoped Revalidation uses a dependency model to decide what becomes invalid, what can persist, what evidence is required, and how boundary failure changes the scope.
traceability_linking — Traceability Linking	Traceability Linking creates durable source-to-consequence links. This archetype interprets those links after a change and governs selective re-derivation and retention.
dynamic_subproblem_reuse — Dynamic Subproblem Reuse	Dynamic Subproblem Reuse avoids recomputing recurring subproblems and includes invalidation machinery. This archetype addresses the broader validity of facts, obligations, decisions, and artifacts after any material change, even when no cached solution is being reused.
strategic_caching — Strategic Caching	Strategic Caching places reusable results and governs freshness. Change-Scoped Revalidation determines the affected closure and persistence basis across the system, of which cache invalidation is one implementation case.
constraint_propagation_and_decoupling — Constraint Propagation and Decoupling	Constraint Propagation and Decoupling reduces a problem by propagating implications before solving partitions. This archetype starts from a change to an accepted state and determines which prior conclusions must be revisited.
versioned_evolution — Versioned Evolution	Versioned Evolution preserves and manages successive versions. Change-Scoped Revalidation determines the validity consequences of moving from one version to another.
correspondence_validation — Correspondence Validation	Correspondence Validation checks whether a replacement agrees with legacy behavior in the old domain. This archetype scopes all downstream facts affected by a particular change and preserves the rest by a tested default.
contextual_selective_propagation — Contextual Selective Propagation	Contextual Selective Propagation governs where changed meaning should travel across social and semantic contexts. This archetype governs validity and re-derivation across dependencies after a change, including nonsemantic technical and institutional state.
regime_shift_impact_boundary_characterization — Regime Shift Impact Boundary Characterization	Regime-Shift Impact Boundary Characterization maps consequence zones after a system crosses regimes. This archetype handles ordinary or local changes and makes selective revalidation, persistence, and evidence the central intervention.
invariant_guarding — Invariant Guarding	Invariant Guarding prevents or repairs transitions that violate declared conditions. Change-Scoped Revalidation decides which facts must be reconsidered after a permitted change; invariants are one boundary-checking input.

The closest overlap is with Dependency Exposure, Traceability Linking, and Dynamic Subproblem Reuse. They provide valuable inputs and shared components, but the present draft is warranted only because it adds the combined persistence-and-revalidation decision. A later reconciliation should merge shared component records rather than erase that distinction.

Cross-domain examples

Software and Build Systems

A changed library interface invalidates callers, generated artifacts, integration tests, and operational runbooks reached through typed dependencies; adjacent unaffected modules receive boundary tests rather than a full rebuild of every product.

Why it fits: The baseline, dependency edges, change event, and executable validation evidence are explicit enough to compute and challenge a selective scope.

Data and Analytics

A source-field definition changes, causing lineage-aware recomputation of affected transformations, metrics, dashboards, and decisions while unrelated branches retain their accepted versions.

Why it fits: Derived facts have traceable inputs, and mixed-version or semantic-drift risks make an auditable persistence decision necessary.

Policy and Regulation

An eligibility rule changes; reviewers trace consequences through forms, guidance, training, appeals, reporting, and affected populations, then sample supposedly unaffected provisions for indirect contradictions.

Why it fits: The change has downstream obligations that cannot all be reread indiscriminately, yet consequences extend beyond document edits.

Manufacturing and Engineering Change Control

A material substitution triggers revalidation of specifications, processes, suppliers, tests, maintenance instructions, and hazard controls whose validity depends on the changed property.

Why it fits: Dependency and traceability artifacts exist, but safety requires risk-tiered evidence and escape checks rather than blind reuse.

Knowledge and Rule Systems

Retracting one premise invalidates only conclusions whose justification chains use it; alternative justifications can reinstate a conclusion without recomputing the entire knowledge base.

Why it fits: Justifications define the affected closure and permit explicit persistence or reinstatement decisions.

Scientific Modeling

A revised parameterization triggers reruns of dependent scenarios, sensitivity analyses, figures, and claims, while outputs whose inputs and model assumptions are unchanged remain provisionally valid.

Why it fits: Model lineage and reproducibility evidence permit selective reruns, while boundary checks probe interactions and hidden shared assumptions.

Extended example

A hospital changes the definition used to classify a high-risk patient. The team first freezes the accepted baseline and records that the change affects a threshold, a time window, and the handling of missing data. Its dependency map links the definition to an alerting rule, clinician worklist, staffing forecast, quality dashboard, patient communication, and retrospective study. Typed invalidation rules show that the worklist and alert logic require immediate revalidation, the staffing forecast requires rerun only where cohort size changes materially, and the historical study must preserve its original definition but receive a version annotation. Reviewers process the affected closure in order, retain independent measures under an explicit persistence presumption, and sample units predicted to be unaffected. A sentinel reveals that one local report copied the old threshold without a lineage link. The scope is widened, the report is corrected, the missing dependency is added, and activation waits for a coherent versioned release. The intervention is not merely a dependency diagram or regression test: it is the governed decision about what must change, what may remain, why, and what evidence can overturn that boundary.

Non-examples

• Recomputing and manually approving every artifact after every change, regardless of cost or dependency evidence.
• Publishing release notes that list edited files but do not assess downstream validity.
• Maintaining a graph of dependencies without invalidation rules, revalidation evidence, or retained-state decisions.
• Expiring cached values on a timer without reference to upstream changes.
• Blocking a transaction on one invariant while leaving broader downstream consequences unexamined.
• Declaring all unreviewed items unchanged because they were not assigned to the change project.

Review note

The draft should remain a distinct provisional archetype unless review finds that an accepted neighbor already owns all four defining responsibilities: invalidation-relevant closure, ordered revalidation, defeasible persistence outside the closure, and boundary-escape response. Shared tools or component names are not sufficient grounds for merger.

Common Mechanisms

• Boundary Escape Sampling
• Cache Invalidation Review
• Change Impact Report
• Data Diff and Merge Tool — Compares two divergent copies against their common ancestor, auto-merges the changes that don't overlap, and surfaces the ones that do as explicit, reviewable conflicts.
• Dependency Closure Traversal
• Dependency Graph — Draws the system's depends-on relations as nodes and directed edges so concentration, chains, and single points of failure become visible at a glance.
• Impact Analysis — Traces the blast radius of one specific dependency failing or changing — what breaks first, who is hit, how fast, and what substitutes remain — turning a depends-on relation into a concrete consequence.
• Persistence Exception Register
• Regression Test Suite — Re-runs a corpus of previously-passing cases against each new version so that any unintended loss of working behaviour breaks the build, using the system's own recorded past output as the reference.
• Requirements Traceability Matrix — Threads every requirement through to the design, code, and verification that satisfy it, so any requirement with no downstream link — or no passing test — is a visible coverage hole.
• Selective Revalidation Worklist
• Truth-Maintenance System

Compression statement

Represent the semantic delta; traverse invalidation-relevant dependencies to form the smallest defensible affected closure; revalidate members in dependency order; keep nonmembers only while their validity conditions, expiry, and exception rules remain satisfied; and use boundary-escape evidence to widen, roll back, or escalate the scope when the model proves incomplete.

Canonical formula: Let Δ be the semantic change, D the typed dependency relation, and IΔ the edges whose validity can be affected by Δ. A = closure_{IΔ}(Δ) Revalidate A in dependency order. Presume persistence for V A only while validity, expiry, and escape checks pass. If an escape is observed, widen A, revalidate, or roll back.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (1)

• Frame Problem: After a change, the challenge of bounding which facts now need re-derivation and which persist by default, without re-checking everything.

Also references 16 related abstractions

• Boundedness: Values remain within limits.
• Causality: Cause-effect relationships.
• Closure: Ensures operations remain within a set.
• Cognitive Flexibility: Switching the active frame from a held repertoire when a trigger detects the current one has stopped fitting the context.
• Coupling: Interdependence among subsystems.
• Data Integrity: Accuracy and consistency preserved.
• Fixed Point: A state a transformation leaves unchanged — self-consistency under update — organizing analysis into existence, uniqueness, stability, and basin of attraction.
• Identity-Preserving Modification: An entity undergoes an event that changes some of its properties while an identity-condition licenses calling the after-state a continuation of the same entity rather than its replacement.
• Invariance: Properties unchanged under transformation.
• Modularity: Breaks systems into smaller units.

▸ Show 6 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Graph-Closed Revalidation · implementation variant · recognized

Uses an explicit dependency graph and typed invalidation rules to compute a closed set of items requiring revalidation.

• Distinct from parent: The parent allows hybrid and judgment-based scope construction; this variant relies primarily on formal reachability.
• Use when: Dependencies are sufficiently explicit, directional, and maintainable; Change types can be matched to edge-specific invalidation rules.
• Typical domains: software architecture, data lineage, rule systems, configuration management
• Common mechanisms: dependency graph, dependency closure traversal, selective revalidation worklist, regression test suite

Risk-Tiered Change Review · governance variant · recognized

Combines dependency scope with consequence and uncertainty tiers so higher-risk items receive broader evidence and escalation.

• Distinct from parent: The parent requires proportional validation; this variant makes risk tiering the primary scope and evidence governor.
• Use when: Formal dependencies are incomplete or mixed with expert judgment; The cost of a missed effect varies sharply across items or stakeholders.
• Typical domains: medical devices, public policy, financial controls, industrial operations
• Common mechanisms: impact analysis, change impact report, requirements traceability matrix, boundary escape sampling

Event-Driven Incremental Recomputation · mechanism family variant · recognized

Automatically recomputes affected derived state when declared change events invalidate upstream inputs or justifications.

• Distinct from parent: The parent is implementation-neutral and may be manual; this variant uses event-triggered incremental execution.
• Use when: Changes arrive frequently and affected outputs can be recomputed deterministically; Dependency and event contracts are machine-readable and monitored.
• Typical domains: reactive software, build systems, stream processing, knowledge graphs
• Common mechanisms: selective revalidation worklist, truth maintenance system, data diff and merge tool, rule engine validation

Near names: Selective Revalidation, Dependency-Scoped Revalidation, Bounded Change-Impact Review, Affected-Closure Update, Persistence-by-Default Update, Frame-Problem Resolution.