Dependency Exposure

batch: First Iteration/Batch 08

Hidden Dependency Exposure

notes: Emphasizes the discovery of dependencies that are not visible in ordinary documentation or mental models.

Dependency Visibility

notes: Names the desired visibility state; dependency exposure is the intervention that creates and uses that state.

Dependency Discovery

notes: Often names the initial discovery stage, but the full archetype also includes criticality, ownership, monitoring, and response logic.

source_primes: relation coupling observability

slug: relation

slug: accountability

slug: transparency

components:
Dependency Scope Boundary
Dependency Map
Dependency Type Catalog
Criticality Classification
Evidence and Confidence Basis
Owner Assignment
Failure Path Model
Monitoring Signal
Contingency or Substitution Path
Assumption Record
Single Point of Failure Marker
Freshness Review Cadence
Sensitivity or Disclosure Filter
Dependency Change Trigger

mechanisms:
Dependency Registry
Dependency Graph
Software Bill of Materials
Supply Chain Mapping
Vendor Risk Map
Assumption Log
Impact Analysis
Dependency Review Workshop
Critical Dependency Dashboard
FMEA Dependency Table
Architecture Dependency Review
Contract and SLA Review

essence_one_line: Reveal hidden dependencies so risks, obligations, failure paths, and coordination needs become visible before they cause failure.

compression_statement: When a system depends on unseen actors, resources, assumptions, components, data, vendors, permissions, or processes, expose those dependencies, classify their criticality, assign ownership, and connect them to monitoring or contingency action so fragility becomes governable instead of surprising.

core_intuition: Many systems look self-contained because their dependencies are outside the focal diagram, buried in habit, hidden in contracts, embedded in technical stacks, or assumed as background conditions. Dependency Exposure changes the object of attention: not just what the system does, but what it quietly requires in order to keep doing it.

canonical_formula: dependency_exposure = scoped_dependency_map + dependency_type_catalog + criticality_classification + evidence_basis + owner_assignment + monitoring_or_contingency_loop

structural_problem: A system appears independent, stable, or well-understood while actually depending on unseen components, resources, actors, approvals, suppliers, data, assumptions, or processes whose failure would disrupt outcomes.

description: Elements are operationally coupled even though documentation, incentives, or organizational structure treats them as separate.

description: A team, product, process, role, or policy is believed to be self-contained until a change reveals unrecognized reliance.

description: External providers, upstream suppliers, outsourced services, contracts, or logistics paths are not visible enough to assess fragility.

description: A plan, model, budget, or policy depends on implicit premises that have not been stated, tested, or assigned to an owner.

description: Before migration, redesign, launch, deprecation, or policy change, decision makers cannot say what hidden dependencies may break.

description: The system may depend on one person, supplier, dataset, approval, service, facility, or undocumented workaround.

description: A dependency is known informally but no accountable person or role owns its validation, monitoring, or contingency.

symptom: A local failure cascades through supposedly unrelated systems.

interpretation: The dependency structure existed, but it was not exposed or governed before failure.

symptom: A migration, rollout, or policy change repeatedly discovers blockers late.

interpretation: Hidden dependencies are being found reactively rather than exposed before commitment.

symptom: A key process stops when one person, vendor, dataset, or tool is unavailable.

interpretation: The system relied on a single point of failure without explicit contingency or ownership.

symptom: Risk reviews list hazards but cannot connect them to operational prerequisites.

interpretation: Risk is being tracked as an abstract issue rather than as a dependency relation with concrete failure paths.

symptom: Teams disagree about what a service, program, report, or decision actually depends on.

interpretation: Dependency knowledge is scattered across partial mental models and informal experience.

symptom: Incident postmortems repeatedly say that an assumption turned out to be wrong.

interpretation: Assumption dependencies were not exposed, tested, or monitored beforehand.

root_tension: Dependency exposure must reveal enough hidden reliance to support resilience and accountability without creating endless mapping burden, false certainty, surveillance, blame, or unnecessary disclosure of sensitive vulnerabilities.

case: The dependency is already explicit, owned, monitored, and covered by response paths.

why_not: Use ordinary maintenance, monitoring, or governance rather than a discovery-oriented exposure intervention.

case: The main need is to map many kinds of relations, not dependency-specific fragility.

why_not: Use relation_mapping when the relevant relations include influence, ownership, obligation, compatibility, evidence, or association rather than hidden depends-on relations.

case: The dependencies are known and the problem is sequencing work around them.

why_not: Use dependency_ordering when the relation structure is already explicit and the intervention is order, scheduling, or prerequisite sequencing.

case: The solution is already selected and the task is building redundancy or failover.

why_not: Use failover, redundancy, bulkhead isolation, or resilience design patterns when exposure is no longer the central intervention.

case: A risk register records general risks but does not ask what the system relies on.

why_not: A risk register can be a mechanism or downstream artifact, but the archetype requires exposing dependency relations and acting on them.

structural_intervention: Surface dependency relations that were previously implicit or hidden, classify their criticality and evidence basis, assign accountable ownership, and connect exposed dependencies to monitoring, contingency, redesign, or governance action.

logic: State what system, process, program, service, model, artifact, role, or decision is being examined and why dependency visibility is needed now.

logic: Choose the relevant time horizon, lifecycle stage, entities, dependency types, and depth of upstream or downstream search.

logic: Use documents, interviews, incidents, logs, contracts, traces, work observation, architecture review, and counterfactual questions to reveal what the focal system relies on.

logic: Separate technical, human, vendor, resource, data, permission, timing, knowledge, assumption, infrastructure, and legal dependencies because each requires different governance.

logic: Record how each dependency is known, how current the evidence is, and whether the dependency is observed, inferred, reported, contractual, or assumed.

logic: Determine what happens if the dependency fails, degrades, delays, changes, or becomes invalid, including blast radius, lead time, reversibility, and substitutability.

logic: Assign who validates the dependency, who monitors it, who can change it, who is affected by it, and who escalates when it weakens.

logic: Define signals, review cadence, fallback paths, redundancy, substitution, escalation, contract changes, or redesign work for dependencies that matter.

logic: Require dependency review before launches, migrations, deprecations, staffing changes, vendor changes, major policy changes, or architecture decisions.

logic: Update dependency records when incidents, audits, vendor events, organizational changes, or environmental shifts reveal new dependency facts.

description: Prioritize dependencies that affect safety, continuity, legality, accountability, cost, service quality, or change risk.

description: Treat a relation as dependency exposure only when the focal system requires the other element or condition to function, decide, deliver, comply, or remain valid.

description: Do not prescribe redundancy, failover, substitution, or contract changes before understanding dependency type, criticality, and failure path.

description: A high-criticality dependency without an owner is still hidden in governance terms even if it has been named.

description: Dependency records should indicate how they are known and when they need review, because stale maps can create false confidence.

description: Expose dependencies to the people who need to govern them, but control disclosure when publication could increase security, privacy, labor, or negotiation harm.

description: The point is not eliminating all dependency. Some dependencies are legitimate and economical; exposure supports informed acceptance as well as mitigation.

description: Dependencies capable of materially disrupting the focal system should not remain implicit background assumptions.

description: Each important dependency should state what kind of dependency it is and how the claim is known.

description: For important dependencies, someone must be accountable for validation, monitoring, escalation, or contingency planning.

description: Dependency exposure should feed change, risk, procurement, staffing, architecture, or policy decisions rather than remain a static diagram.

description: Making dependencies visible should not recklessly disclose exploit paths, private labor details, confidential contracts, or vulnerable populations.

outcome: Earlier discovery of fragile reliance

description: Hidden dependencies are found before incidents, launches, migrations, or policy changes expose them under pressure.

outcome: Better change impact assessment

description: Decision makers can ask what will break, slow down, or become invalid when a dependency changes.

outcome: Clearer accountability for resilience

description: Dependency owners, affected parties, and escalation paths become visible enough to coordinate.

outcome: Improved contingency planning

description: High-criticality dependencies can be paired with substitutes, buffers, contracts, monitoring, or graceful degradation.

outcome: Reduced cascading failure

description: Failure paths are identified early enough to isolate, buffer, diversify, or monitor critical dependency chains.

outcome: More honest planning assumptions

description: Plans and models become less brittle because they expose what must remain true for them to work.

prose_essence:
Dependency Exposure is the archetype for making hidden reliance visible before it fails. A system may appear self-contained because its users see only a product, process, policy, model, team, or service. Underneath, it may rely on suppliers, APIs, licenses, staffing coverage, tacit knowledge, data freshness, legal permissions, contracts, assumptions, infrastructure, or manual workarounds.

The core move is not merely to draw a dependency diagram. The intervention turns a hidden prerequisite into a governed relation: this outcome requires that actor, resource, condition, component, or assumption. Once the dependency is visible, it can be classified, owned, monitored, accepted, mitigated, substituted, buffered, or redesigned.

Use this archetype when surprise dependence is the danger. The goal is not dependency elimination. The goal is informed dependency governance.

prose_when_to_use:
Use Dependency Exposure when a system looks stable or independent but likely relies on prerequisites that are poorly documented, scattered across people, hidden in technical layers, embedded in contracts, or assumed as background conditions. It is especially useful before launches, migrations, deprecations, staffing changes, vendor changes, audits, incident reviews, resilience planning, and policy rollouts.

Typical questions include: what does this system need in order to function; who or what could silently break it; what assumptions must remain true; which vendors, people, data feeds, approvals, or infrastructure are critical; what fails if this dependency disappears; who owns the dependency; and what signal would tell us it is weakening.

Do not use the archetype only because dependencies exist. Every system depends on something. Use it when dependency visibility changes planning, accountability, risk, continuity, compliance, or design decisions.

prose_structural_problem:
The structural problem is false independence. The focal system is treated as if it can be understood alone, but its real behavior depends on hidden relations to other actors, resources, components, conditions, or assumptions. The hidden relation may be technical, social, contractual, logistical, legal, data-based, cognitive, or environmental.

This produces characteristic failures. A software team removes a service and discovers that a legacy report still calls it. A public agency announces a policy whose local implementation depends on county staffing that does not exist. A manufacturer thinks it has many products but later discovers they share one fragile supplier. A hospital process appears standardized but depends on one experienced coordinator’s informal knowledge. A model output seems automated but depends on an upstream data refresh and an undocumented imputation rule.

The root tension is that dependency visibility is valuable but costly and potentially sensitive. Too little exposure creates fragility and surprise. Too much exposure can create mapping burden, false confidence, security risk, blame, or disclosure of vulnerable human labor. The archetype works only when exposure is scoped, evidenced, and connected to action.

prose_intervention_logic:
Dependency Exposure begins by defining the focal system and the decision that dependency visibility must support. A dependency review for software migration, supply-chain resilience, role coverage, model governance, and policy rollout will search for different kinds of dependencies.

The next move is to set the exposure boundary. The boundary decides how many upstream layers to trace, which dependency types count, what time horizon matters, and when additional discovery no longer changes the decision. Without this boundary, dependency exposure becomes infinite upstream analysis.

The central work is surfacing hidden dependencies. Good exposure uses multiple sources: interviews, logs, contracts, incidents, architecture diagrams, runtime traces, procurement records, model cards, staffing schedules, work observation, and “what would break if…” questions. Candidate dependencies are then typed, evidenced, and classified by criticality. A dependency on a commodity office supply is not the same as a dependency on a single regulatory approval, unmaintained package, tacit workaround, or irreplaceable supplier.

Finally, exposed dependencies must be connected to governance. High-criticality dependencies need owners, monitoring signals, review cadence, contingency paths, substitution options, escalation rules, or explicit risk acceptance. Without that connection, the result is a list. With it, hidden fragility becomes a managed relation.

prose_key_components:
### Dependency Scope Boundary

The dependency scope boundary defines the focal system, decision use, time horizon, and search depth. It prevents dependency exposure from becoming an unbounded effort to map everything that causally matters. The boundary should be explicit enough that reviewers know why some dependencies were included and others were excluded.

### Dependency Map

The dependency map records the depends-on relations themselves. It shows that a process depends on a role, a model depends on a dataset, a product depends on a supplier, a policy depends on an implementation agency, or a service depends on another service. A dependency map is central, but it becomes the archetype only when it is tied to criticality, evidence, ownership, monitoring, and response.

### Dependency Type Catalog

The dependency type catalog distinguishes resource, vendor, technical, data, human, timing, legal, permission, infrastructure, knowledge, and assumption dependencies. This distinction matters because each type breaks differently and requires different governance. A staffing dependency cannot be mitigated in the same way as a transitive software package.

### Criticality Classification

Criticality classification ranks dependencies by consequence, likelihood, substitutability, lead time, blast radius, reversibility, and tolerance for interruption. It turns dependency exposure from a flat list into a decision tool. High-criticality dependencies deserve owners, monitors, contingencies, or explicit risk acceptance.

### Evidence and Confidence Basis

The evidence and confidence basis records how each dependency is known. Some dependencies are observed in logs, some appear in contracts, some are reported by domain experts, and some are inferred from incidents or architecture. Capturing evidence prevents uncertain claims from hardening into false authority and helps reviewers know where to verify.

### Owner Assignment

Owner assignment makes exposed dependencies governable. An owner may validate the record, monitor status, maintain a contingency, escalate degradation, or coordinate mitigation. Without ownership, even a well-documented dependency can remain operationally hidden because no one is accountable for its state.

### Failure Path Model

The failure path model explains what happens when a dependency fails, degrades, delays, changes, or becomes invalid. It answers questions such as: what breaks first, who notices, how far does the failure propagate, how quickly must we respond, and what options remain. This component links dependency exposure to resilience and risk planning.

### Monitoring Signal

A monitoring signal is an observable cue that a dependency is weakening or drifting. It may be a service-level metric, supplier status, contract date, staffing coverage indicator, data freshness check, vulnerability alert, or assumption validation result. Monitoring turns one-time exposure into continuing observability.

### Contingency or Substitution Path

A contingency or substitution path defines what will happen if a critical dependency fails. It may be a backup supplier, manual process, cross-trained role, failover service, buffer inventory, contract option, escalation path, or graceful degradation mode. Not every dependency needs a backup, but critical ones need some explicit response.

prose_common_mechanisms:
Dependency registries implement the archetype by maintaining structured dependency records with owners, criticality, status, evidence, and review dates. They are useful when many dependencies must be governed over time.

Dependency graphs implement the archetype visually by showing nodes and depends-on edges. They are powerful for seeing concentration and failure paths, but a graph alone is not the archetype. It must be connected to criticality, evidence, ownership, and action.

Software bills of materials expose package and component dependencies in software systems. They are especially useful for vulnerability response, licensing review, and technical resilience planning. Their limitation is that they may miss runtime, data, service, or human dependencies.

Supply-chain maps expose suppliers, logistics paths, facilities, materials, jurisdictions, and contractual dependencies. They help reveal upstream concentration that is invisible from a direct vendor view.

Vendor risk maps connect external providers to the services, data flows, contracts, controls, and outcomes that depend on them. They are useful when outsourced or third-party services create operational fragility.

Assumption logs implement the assumption-focused variant. They expose plans, budgets, forecasts, models, or policies that rely on premises that may not remain true.

Impact analysis tests the consequences of dependency failure or change. It turns exposure into practical questions: what breaks, who is affected, how quickly, and with what available substitutes.

Dependency review workshops are useful when dependency knowledge is distributed across people. They surface tacit work, informal handoffs, and lived operational knowledge that documents may miss.

Critical dependency dashboards track high-criticality dependencies over time. They are helpful when the main risk is drift: an approaching contract date, degrading supplier performance, unpatched component, staffing gap, or stale data feed.

FMEA-style dependency tables adapt failure mode analysis to dependency failure paths. They help compare severity, likelihood, detectability, and mitigation priority.

Architecture dependency reviews operationalize the archetype before technical changes, migrations, launches, and deprecations. Contract and SLA reviews operationalize it when external providers, support terms, and service commitments define dependency risk.

prose_failure_modes:
A flat dependency inventory is the most common failure mode. It lists dependencies but omits type, evidence, owner, criticality, and failure path. This creates an artifact but not governance.

False completeness occurs when a dependency map is treated as exhaustive even though it was created from limited interviews, static documents, or narrow tooling. The cure is to record scope, evidence, confidence, and blind spots.

Stale maps are dangerous because they create confidence after reality has changed. Refresh cadence, change triggers, automated signals, and incident feedback are essential.

Overexposure without action creates anxiety and bureaucracy. High-criticality dependencies need a next step; low-criticality dependencies can be accepted or reviewed lightly.

Sensitive dependency leakage can create real harm. Detailed maps may help attackers, reveal labor vulnerabilities, expose confidential arrangements, or stigmatize resource-constrained actors. Govern access and disclosure.

Blame spirals happen when exposed dependencies are used to accuse people rather than address systemic fragility. Owner assignment should clarify stewardship, not create scapegoats.

Infinite upstream search happens when analysts lack a stopping rule. Stop when additional tracing no longer changes the decision or risk response.

Mitigation overreach happens when every dependency is treated as unacceptable. Some dependencies are legitimate. Exposure supports informed acceptance as well as redesign.

prose_neighbor_distinctions:
Relation Mapping is broader. It maps associations, influence, ownership, obligations, constraints, and other relation types. Dependency Exposure focuses specifically on hidden depends-on relations and the fragility they create.

Traceability Linking follows sources, requirements, decisions, artifacts, tests, or outcomes so evidence and change consequences remain auditable. Dependency Exposure asks what a focal system relies on and what happens when that reliance fails.

Dependency Ordering sequences work around known prerequisites. Dependency Exposure comes earlier when the dependencies themselves are hidden, unowned, or under-classified.

Observability Instrumentation creates signals that infer hidden state. Dependency Exposure identifies hidden prerequisites; monitoring may be selected afterward for critical dependencies.

Risk registers record risks. Dependency Exposure reveals the relational structure that often explains those risks. A risk register may be a mechanism, but it is not the archetype by itself.

Failover, redundancy, bulkhead isolation, diversification, and graceful degradation are downstream mitigation patterns. Dependency Exposure helps decide where those patterns are needed.

Source-of-Truth Assignment resolves conflicting authoritative records. Dependency Exposure may reveal reliance on a source of truth, but choosing authority is a separate intervention.

prose_cross_domain_examples:
In software, a team preparing to retire a service exposes all applications, reports, data jobs, vendors, and undocumented scripts that still call it. The result changes migration planning and identifies owners for each dependent system.

In manufacturing, a company discovers that multiple product lines depend on one specialized supplier with a long qualification time. Exposure leads to supplier diversification, buffer inventory, and contract review.

In healthcare operations, a hospital maps which critical workflows depend on a single courier route, equipment technician, vendor portal, or nurse coordinator. Exposure supports coverage planning and incident response.

In public policy, a benefits program exposes dependencies on local staff, translated notices, data-sharing agreements, call-center scripts, and county IT systems before rollout. The policy becomes implementable because hidden prerequisites are visible.

In organizational continuity, a finance team discovers that reporting depends on one analyst’s undocumented spreadsheet and informal reminders. Exposure leads to documentation, cross-training, and backup ownership.

In AI governance, a model owner exposes dependencies on data freshness, third-party identifiers, feature transformations, retraining jobs, and monitoring thresholds. The model becomes easier to audit and safer to change.

prose_non_examples:
A list of tools used by a team is not Dependency Exposure unless it identifies what depends on each tool, how critical the dependency is, who owns it, and what happens if it fails.

A project schedule that orders tasks by known prerequisites is not Dependency Exposure. That is dependency ordering.

A dashboard that tracks uptime for one service is not Dependency Exposure if it does not reveal who or what depends on the service.

A risk register that says “vendor outage” is not enough. The dependency relation must be exposed: which vendor service, which outcomes, which contracts, which substitutes, which owners, and which failure path.

A generic relation diagram is not Dependency Exposure if the lines represent association, communication, influence, or ownership rather than hidden reliance.

prose_tradeoffs:
Dependency exposure trades surprise reduction for mapping and maintenance effort. The more dependencies you expose, the more records you must validate, prioritize, and refresh.

It trades transparency for sensitivity. A useful dependency map may reveal vulnerabilities, concentrated labor, confidential supplier relationships, or exploit paths. Some maps need restricted access or redaction.

It trades speed for assurance. Teams can move quickly by ignoring hidden dependencies, but they may pay later through outages, compliance failures, rework, or public harm.

It trades efficiency for resilience. Once critical dependencies are exposed, responsible mitigation may require redundancy, buffers, substitute suppliers, cross-training, or failover that looks inefficient during normal operations.

It trades individual accountability for systemic learning. Assigning owners is necessary, but misuse can turn exposure into blame. The healthiest use is to repair dependency structure, not punish people for inheriting it.

prose_invariants_to_preserve:
Critical dependencies should not remain implicit. If a dependency can materially disrupt the focal system, it should be named at a level that supports decisions.

Dependency records should remain typed and evidenced. A dependency without type or evidence is hard to govern because no one knows how it breaks or how reliable the record is.

High-criticality dependencies should have owners. Ownership does not mean blame; it means someone is responsible for keeping the dependency visible enough to manage.

Failure paths should remain connected to action. If exposure does not inform monitoring, contingency, procurement, staffing, design, compliance, or risk decisions, it becomes static documentation.

Sensitive dependency information should remain governed. Visibility must be balanced with security, privacy, labor, political, and negotiation risks.

prose_target_outcomes:
The primary outcome is earlier discovery of fragility. Dependencies that would otherwise appear only during incidents, launches, audits, or crises are surfaced while there is still time to respond.

A second outcome is better change impact assessment. Before changing a component, supplier, rule, dataset, role, or interface, decision makers can see what depends on it and what may break.

A third outcome is clearer accountability. Dependency owners, affected parties, and escalation paths become explicit enough for coordination.

A fourth outcome is improved contingency planning. Critical dependencies can be paired with fallback processes, substitute providers, cross-training, buffers, monitoring, or graceful degradation.

A fifth outcome is reduced cascading failure. By seeing dependency chains and single points of failure, designers can isolate, buffer, diversify, or monitor the places where failures would propagate.

A sixth outcome is more honest planning. Plans and models become less brittle because their hidden assumptions are visible and reviewable.

prose_parameter_dimensions:
The first tuning dimension is exposure depth. Some efforts only need direct dependencies; others need second-order or upstream dependencies. The stopping rule should be based on whether deeper tracing changes the decision, risk posture, or contingency plan.

The second dimension is criticality threshold. A low threshold catches more dependencies but creates noise and maintenance burden. A high threshold focuses attention but may miss fragile dependencies before they become visible.

The third dimension is evidence standard. Early discovery may accept reported or inferred dependencies. Safety-critical or high-cost decisions may require logs, contracts, tests, runtime traces, or independent validation.

The fourth dimension is review cadence. Stable environments can tolerate periodic review. Volatile software stacks, staffing models, supplier networks, and regulatory contexts require event-triggered refresh.

The fifth dimension is disclosure level. Dependency information should be visible enough to govern, but sensitive enough to protect when it reveals exploit paths, private labor arrangements, confidential contracts, or vulnerable populations.

The sixth dimension is mitigation commitment. Exposure can lead to acceptance, monitoring, contingency planning, redundancy, diversification, redesign, or elimination. The right level depends on criticality, cost, reversibility, and risk tolerance.

prose_variants_and_near_names:
Supply-Chain Dependency Exposure focuses on suppliers, logistics, materials, facilities, contracts, and jurisdictions. It is useful when upstream concentration is hidden behind direct procurement relationships.

Software Dependency Exposure focuses on packages, APIs, services, data feeds, infrastructure, versions, licenses, maintainers, and security vulnerabilities. It often uses bills of materials, dependency scans, and architecture reviews.

Assumption Dependency Exposure treats premises as dependencies. It is useful when a plan, model, budget, forecast, or policy will fail if an unstated assumption is wrong.

Human Role Dependency Exposure focuses on tacit knowledge, role coverage, informal workarounds, approvals, and relational labor. It requires care because exposing human dependencies can either protect resilience or intensify surveillance and blame.

Data Dependency Exposure focuses on upstream datasets, transformations, freshness, quality assumptions, model inputs, and downstream uses. It borders traceability linking, but its center is fragility and dependence rather than audit continuity.

Near names include dependency discovery, dependency visibility, hidden dependency mapping, dependency registry, dependency graph, vendor risk mapping, assumption log, and bill of materials. Most of these are mechanisms or phase names unless they include the full exposure-to-governance logic.

Supply-Chain Dependency Exposure

short_definition: Expose suppliers, logistics paths, facilities, materials, geopolitical exposures, and contractual dependencies that can disrupt delivery or production.

distinctive_feature: The exposed dependencies are often outside direct organizational control and may require negotiation, buffering, diversification, or contract redesign.

distinct_from_parent: The parent applies to any hidden dependency; this variant emphasizes material, vendor, logistics, and geopolitical chains.

still_same_parent_because: The core move is still to reveal hidden dependencies and link them to risk, ownership, monitoring, and contingency action.

use_when: the focal system depends on external suppliers, logistics, inputs, facilities, or jurisdictions

use_when: disruption risk is hidden behind a direct vendor or immediate process view

use_when: resilience planning requires seeing upstream and downstream dependencies

role: maps supplier and logistics dependencies

role: prioritizes fragile or irreplaceable inputs

role: defines alternate suppliers, buffers, or reroutes

role: maps supplier and logistics relations

role: records external provider risk

example_domains:
manufacturing
healthcare logistics
public procurement
food systems

domain: manufacturing

example: A manufacturer discovers that two unrelated product lines depend on the same single overseas component supplier.

failure_modes: stops at tier-one suppliers and misses upstream concentration

failure_modes: treats supplier disclosure as complete without validation

Software Dependency Exposure

short_definition: Expose libraries, services, APIs, infrastructure, data feeds, versions, licenses, maintainers, and security dependencies that software relies on.

distinctive_feature: The dependency landscape can change quickly through package updates, deprecations, transitive dependencies, and infrastructure changes.

distinct_from_parent: The parent is cross-domain; this variant emphasizes technical dependencies, transitive packages, service calls, runtime infrastructure, and maintenance status.

still_same_parent_because: It still exposes hidden dependence and connects it to ownership, criticality, monitoring, and contingency response.

use_when: software behavior, security, licensing, or reliability depends on components not visible to users or decision makers

use_when: a migration, release, incident, or vulnerability review requires knowing what depends on what

use_when: technical debt hides reliance on unsupported libraries, opaque APIs, or fragile services

role: separates library, service, data, infrastructure, and license dependencies

role: records scans, manifests, runtime traces, or architecture evidence

role: watches version, vulnerability, uptime, and deprecation signals

role: records software components and versions

role: reviews technical dependency structure before change

example_domains:
software engineering
cybersecurity
data platforms
AI systems

domain: cybersecurity

example: A security team traces which applications depend on a vulnerable transitive package before patch prioritization.

failure_modes: records declared dependencies while missing runtime or transitive dependencies

failure_modes: exposes dependencies but leaves them unowned

Assumption Dependency Exposure

short_definition: Expose plans, models, forecasts, policies, or designs that depend on untested assumptions rather than visible resources or actors.

distinctive_feature: The dependency is a premise that must be named, validated, monitored, or bounded rather than a tangible component or supplier.

distinct_from_parent: The parent exposes dependencies generally; this variant makes implicit assumptions inspectable as dependencies.

still_same_parent_because: The structural intervention still reveals a hidden reliance and links it to evidence, owner, monitoring, and contingency.

source_primes: relation observability uncertainty

use_when: a plan or model will fail if unstated premises are wrong

use_when: decision makers treat assumptions as facts because they are embedded in projections, schedules, or requirements

use_when: the main dependency is belief-like, contextual, or environmental rather than physical

role: captures the premise

role: grades support for the premise

role: defines when the assumption must be revisited

role: documents assumptions and validation status

role: tests consequences if the assumption changes

example_domains:
strategy
policy design
research planning
model governance

domain: policy design

example: A program exposes that its implementation plan depends on local agencies having staff capacity that has never been verified.

failure_modes: assumptions are recorded but never tested

failure_modes: assumption exposure becomes blame assignment rather than learning

Human Role Dependency Exposure

short_definition: Expose dependency on particular people, tacit knowledge, role coverage, informal workarounds, approvals, or relational labor.

distinctive_feature: The dependency may be socially sensitive because exposure can affect bargaining power, privacy, recognition, workload, or blame.

distinct_from_parent: The parent is general; this variant emphasizes human coverage, tacit knowledge, informal roles, and organizational resilience.

still_same_parent_because: It still reveals hidden reliance and connects it to ownership, monitoring, backup, and governance.

source_primes: relation coupling accountability

use_when: a system relies on one person, informal relationship, undocumented skill, or role holder

use_when: turnover, leave, burnout, or organizational change could reveal fragile reliance

use_when: work appears standardized but actually depends on tacit coordination

role: distinguishes owner from person being depended on

role: limits harmful disclosure

role: defines coverage or cross-training paths

role: surfaces tacit work and role reliance

role: tracks high-risk coverage gaps

example_domains:
operations
healthcare staffing
education administration
software maintenance

domain: operations

example: A team discovers that month-end close depends on one analyst’s undocumented spreadsheet and vendor contacts.

failure_modes: tacit labor is exposed but not compensated or protected

Data Dependency Exposure

short_definition: Expose datasets, data quality assumptions, upstream transformations, model inputs, freshness constraints, and downstream uses that decisions or systems depend on.

distinctive_feature: The dependency often operates through provenance, transformation, freshness, and quality rather than direct organizational handoff.

distinct_from_parent: The parent is general; this variant emphasizes data feeds, transformations, lineage, freshness, and quality dependencies.

still_same_parent_because: The intervention remains exposure of hidden reliance, followed by criticality, ownership, monitoring, and contingency decisions.

source_primes: relation data_integrity observability

use_when: decisions, models, reports, or automations depend on data whose lineage or quality is unclear

use_when: a data source change could silently alter downstream results

use_when: model or policy reliability depends on hidden data assumptions

role: maps data feed and transformation dependencies

role: tracks freshness, drift, and quality

role: records lineage and validation evidence

role: tests downstream consequences of data changes

role: tracks important data dependencies

example_domains:
analytics
AI governance
public reporting
finance operations

domain: AI governance

example: A model review exposes that a risk score depends on a third-party field with undocumented refresh lag.

failure_modes: lineage is mapped but decision consequences are not classified

failure_modes: data exposure ignores privacy and access-control constraints

near_names:
Dependency Discovery
Hidden Dependency Mapping
Dependency Visibility
Dependency Graph
Dependency Registry
Bill of Materials
Vendor Risk Mapping


Dependency Ordering

type: archetype

source: generated

batch: First Iteration/Batch 07

source_primes: order well_foundedness pipeline

related_primes: relation graph_network constraint causality hierarchy

slug: order

slug: pipeline

slug: constraint

slug: causality

slug: hierarchy

components:
Dependency Map
Prerequisite Check
Sequencing Rule
Completion Evidence
Rollback or Return Path
Stage Gate
Critical Path Marker
Exception Override Rule
Dependency Owner

mechanisms:
Dependency Graph
Topological Sort
Critical Path Method
Prerequisite Matrix
Deployment Runbook
Curriculum Prerequisite Map
Treatment Sequencing Protocol
Manufacturing Process Plan

essence_one_line: Arrange actions or components according to prerequisite dependencies so later steps do not begin before required conditions exist.

compression_statement: When unordered action causes rework, failure, or invalid states, impose a dependency order so each step occurs only after its prerequisites are satisfied.

core_intuition: A dependency is not merely something that comes earlier; it is something later work needs in order to be valid. Dependency Ordering works by turning hidden prerequisite relations into an explicit partial order, then using that order to prevent premature action, invalid states, avoidable rework, and unsafe progression.

canonical_formula: map prerequisites → impose valid partial order → verify readiness → advance dependent work

structural_problem: A process contains prerequisite relations, but actions are attempted out of order or without required preconditions.

condition: Later work consumes outputs, permissions, resources, knowledge, or states produced by earlier work.

why_it_matters: Starting the dependent step before those prerequisites exist creates invalid work rather than merely early work.

condition: Dependencies are implicit, distributed across people or tools, or remembered informally.

why_it_matters: Informal dependency knowledge is easy to lose during handoffs, scaling, turnover, or exception handling.

condition: Multiple valid orders may exist, but some order constraints are non-negotiable.

why_it_matters: The system needs a partial order, not necessarily a single rigid sequence.

condition: Failed steps cause cascading rework, unsafe states, or blocked downstream work.

why_it_matters: The cost of premature action is higher than the cost of checking prerequisites.

symptom: Teams repeatedly redo work because a missing predecessor is discovered late.

diagnostic_hint: The process is acting as though prerequisites are optional or obvious.

symptom: Work is blocked downstream by upstream decisions, data, approvals, materials, or capabilities that were assumed complete.

diagnostic_hint: The dependency map may be missing, stale, or unenforced.

symptom: Parallel work creates conflicts because tasks thought to be independent actually depend on one another.

diagnostic_hint: The system has hidden ordering constraints.

symptom: A procedure sometimes works and sometimes fails depending on who remembers the correct order.

diagnostic_hint: Ordering knowledge is embodied in experts rather than represented in the process.

root_tension: The system wants speed, flexibility, and parallelism, but some states cannot be validly reached until prerequisite states are already true.

case: Items can be processed in any order without changing validity or outcome.

why_not_this: Order-independent processing or simple batching is likely more relevant.

case: The main issue is fairness, priority, or service order among waiting items.

why_not_this: Queue Discipline Design is the closer neighbor.

case: The order is chosen only for stable comparison, serialization, or presentation.

why_not_this: Canonical Ordering is the closer pattern.

case: A stage must be approved for organizational reasons even though no prerequisite structure is at issue.

why_not_this: Stage-Gate Progression or procedural governance is likely closer.

structural_intervention: Map dependencies, impose a partial or total order, and enforce prerequisite satisfaction before progression.

step: Identify dependent units.

logic: Name the actions, components, decisions, states, or deliverables whose validity depends on other units.

step: Map prerequisite relations.

logic: Represent which predecessor outputs, conditions, resources, or permissions must exist before each dependent unit can begin.

step: Convert relations into an enforceable order.

logic: Use a partial order when independent branches can proceed in parallel; use a total order only where the dependency structure requires it.

step: Check readiness at transition points.

logic: Before a dependent step starts, verify that its prerequisites are actually satisfied, not merely planned or assumed.

step: Handle violations explicitly.

logic: If a prerequisite is missing, block, defer, reroute, or roll back rather than allowing invalid progression.

step: Maintain the dependency map as the system changes.

logic: Update dependency relations when designs, constraints, stakeholders, or environments change.

rule: A step may start only if all declared hard prerequisites are satisfied.

purpose: Prevents premature progression into invalid states.

rule: Soft preferences should not be encoded as hard dependencies.

purpose: Avoids unnecessary serialization and protects useful parallelism.

rule: If the dependency graph contains a cycle, redesign the units, introduce a base case, or define an iterative loop with explicit stop conditions.

purpose: Prevents circular waiting and nonterminating prerequisite chains.

rule: Exceptions require named ownership, risk acceptance, and a return path.

purpose: Allows pragmatic overrides without erasing the dependency logic.

Prerequisite Satisfaction

description: No dependent action proceeds unless the conditions it relies on are already true or explicitly waived.

Dependency Traceability

description: Each order constraint can be traced to a real prerequisite, not merely tradition or preference.

Valid State Progression

description: The process moves from valid state to valid state rather than producing out-of-domain or unrecoverable intermediates.

Parallelism Preservation

description: Independent work remains parallel where no prerequisite relation requires serialization.

Reduced Rework

description: Fewer downstream tasks must be repeated because missing prerequisites are caught before work begins.

Fewer Invalid Sequences

description: Processes avoid actions that cannot succeed or cannot be interpreted because earlier conditions are missing.

Safer Progression

description: Safety-critical or high-cost steps occur only after required evidence, state, or capability exists.

Clearer Coordination

description: Participants understand which work can proceed independently and which work must wait.

prose_essence:
Dependency Ordering arranges actions, decisions, components, or states according to prerequisite relations. It is useful when a later step is not merely later by convention, but depends on something earlier being true, available, completed, learned, approved, stabilized, or produced.

The key move is to turn hidden prerequisite structure into an explicit order of permissible progression. That order can be a partial order, where independent branches move in parallel, or a total order, where each step must follow the previous one. The archetype is not “do things in sequence.” It is “do dependent things only after the conditions they rely on exist.”

prose_when_to_use:
Use Dependency Ordering when premature action creates invalid states, rework, safety risk, blocked downstream work, or procedural failure. The pattern is especially strong when prerequisites cross team boundaries, disciplines, jurisdictions, tools, or physical processes, because no single actor can reliably remember all dependencies.

It is also useful when a process has become over-serialized. A clear dependency map can reveal which steps truly must wait and which branches can safely run in parallel. In that sense, dependency ordering can increase speed by removing false order while preserving true order.

Do not use this archetype when order is chosen only for fairness, priority, presentation, or reproducibility. Those cases are closer to queue discipline, priority admission, or canonical ordering.

prose_structural_problem:
The structural problem is that the system contains prerequisite relations, but work proceeds as though those relations were absent, obvious, or optional. A dependent action begins before its required predecessor state exists. The immediate result may look like progress, but the structural result is invalid work: a deployment without rollback readiness, a treatment without diagnostic prerequisites, a legal action without notice, a course without prerequisite mastery, or an assembly step before material preparation.

This failure often appears as late discovery. People find the missing prerequisite only after downstream work has started. By then, the system has already spent effort in the wrong state.

prose_intervention_logic:
The intervention begins by naming the units that depend on one another. These may be tasks, components, decisions, permissions, resources, states, capabilities, or deliverables. The next step is to map prerequisite relations among them and distinguish hard prerequisites from soft preferences.

Once the dependency structure is known, the system imposes a valid order. A good dependency order is not necessarily rigid. It should permit parallel work wherever no dependency relation exists. Before a dependent step begins, a prerequisite check verifies readiness through evidence, not assumption. If a prerequisite is missing, the process blocks, defers, reroutes, or returns to the missing predecessor rather than continuing in an invalid state.

The intervention must also maintain the dependency map. A stale map can be worse than no map because it gives false confidence.

prose_key_components:
### Dependency Map

A dependency map represents the prerequisite structure. It shows which actions, components, states, resources, or decisions must precede others. The map may be a graph, matrix, runbook, checklist, process diagram, or textual dependency list. Its function is not documentation for its own sake; it makes hidden prerequisite relations inspectable and governable.

### Prerequisite Check

A prerequisite check tests whether the necessary predecessor conditions are actually satisfied before dependent work begins. It distinguishes real readiness from scheduled readiness, claimed readiness, or assumed readiness. In safety-critical and high-cost systems, this check is often the difference between controlled progression and dangerous improvisation.

### Sequencing Rule

A sequencing rule translates the dependency map into permitted action. It says which steps must wait, which may proceed, and which can run in parallel. A strong sequencing rule avoids two opposite errors: it does not allow invalid premature action, and it does not serialize independent work unnecessarily.

### Completion Evidence

Completion evidence shows that a prerequisite has produced the condition the next step needs. This evidence may be a test result, stable data state, signed filing, delivered material, demonstrated skill, inspection result, or verified environmental condition. Without completion evidence, dependency ordering can degrade into trust, ritual, or optimistic planning.

### Rollback or Return Path

A rollback or return path defines what happens when work begins too early or discovers a missing prerequisite. The path may send the process back to an unfinished predecessor, defer the dependent task, trigger remediation, or undo a partial change. Without this component, actors may continue in a known-invalid state because backing up is awkward.

### Optional Stage Gate

A stage gate can enforce Dependency Ordering when prerequisite evidence must be formally reviewed. It is optional. If the gate exists mainly for approval, certification, or governance, the neighboring Stage-Gate Progression archetype may be more central.

### Optional Critical Path Marker

A critical path marker highlights the dependency chain whose delay or failure controls the whole process. It is useful when several dependency-valid orders exist but some chains create disproportionate schedule or risk exposure.

### Optional Exception Override Rule

An exception override rule defines when a dependency may be bypassed, who owns the risk, and how the system returns to validity. This preserves pragmatism without letting exceptions silently destroy the ordering logic.

prose_common_mechanisms:
### Dependency Graphs

A dependency graph is a representation mechanism. It shows predecessor-successor relations in a form that can be inspected, tested for cycles, and updated. The graph is not the archetype; it is one way to represent the structure that the archetype governs.

### Topological Sort

Topological sort is an algorithmic mechanism for producing a valid order from an acyclic dependency graph. It is useful in build systems, package managers, workflows, and planning tools. It should not be drafted as a standalone solution archetype here because it implements the broader intervention rather than replacing it.

### Critical Path Method

Critical Path Method implements a time-sensitive variant of Dependency Ordering. It identifies which dependency chain controls total duration and where slack exists. Its value is not merely scheduling; it helps focus coordination attention on the prerequisite chain that most constrains progress.

### Prerequisite Matrix / Prerequisite Matrices

A prerequisite matrix lists each unit of work against required predecessor conditions, owners, evidence, and allowed next actions. It is especially useful when dependencies cross teams or disciplines and cannot be inferred from a simple linear checklist.

### Deployment Runbooks

A deployment runbook operationalizes Dependency Ordering in systems operations. It orders technical actions, readiness checks, monitoring steps, and rollback paths so later actions are not attempted before required technical states exist.

### Curriculum Prerequisite Maps

A curriculum prerequisite map uses Dependency Ordering in learning design. It sequences activities so later tasks depend on capabilities already developed and verified. The mechanism may include placement tests, mastery gates, or remediation loops, but the underlying logic is prerequisite structure.

### Treatment Sequencing Protocols

A treatment sequencing protocol orders clinical actions around diagnostic, stabilization, consent, contraindication, and safety prerequisites. It implements the archetype by ensuring that irreversible or high-risk interventions do not begin from an invalid clinical state.

### Manufacturing Process Plans

A manufacturing process plan sequences preparation, tooling, inspection, transformation, and assembly steps around physical and quality dependencies. It prevents defective output caused by performing a later transformation before the required earlier state exists.

prose_failure_modes:
Over-serialization occurs when soft preferences are treated as hard prerequisites. The process becomes slower without becoming safer.

A hidden cyclic dependency occurs when two or more units each wait on the other. This requires redesign, a base case, or an explicit iteration rule; otherwise the system may deadlock.

A stale dependency map occurs when the system changes but the map is not updated. The process then blocks valid work or permits invalid work.

Checkbox readiness occurs when people satisfy the form of a prerequisite check without producing the actual required condition. This is common when signoff rituals replace evidence.

Exception drift occurs when bypasses become routine. The ordering rule then loses authority and the system returns to informal sequencing.

prose_neighbor_distinctions:
Dependency Ordering is distinct from Stage-Gate Progression. A stage gate may enforce prerequisites, but Stage-Gate Progression centers on criteria-based advancement through gates. Dependency Ordering centers on prerequisite structure, whether or not there is a formal gate.

It is distinct from Pipeline Staging. Pipeline Staging divides work into ordered stages for specialization, throughput, or handoff. Dependency Ordering imposes order because later work is invalid without earlier conditions.

It is distinct from Order-Sensitive Configuration. Order-Sensitive Configuration controls sequence because sequence changes the meaning or function of a whole. Dependency Ordering controls sequence because a later action requires a predecessor state.

It is distinct from Queue Discipline Design. Queue discipline chooses service order among waiting items. Dependency Ordering decides whether an item is ready to be served or acted on at all.

It is distinct from Canonical Ordering. Canonical Ordering creates a stable order for comparison, serialization, or reproducibility. Dependency Ordering creates a prerequisite-valid order.

It is also distinct from Dependency Exposure. Exposure reveals dependencies; ordering uses them to govern progression.

prose_cross_domain_examples:
In software deployment, a release may require database migration, integration tests, observability checks, and rollback readiness before production rollout.

In construction, foundation curing must precede framing, even if crews and materials are available earlier.

In education, advanced coursework depends on demonstrated prerequisite capabilities rather than on calendar time alone.

In clinical procedure, diagnosis, stabilization, consent, and contraindication checks precede high-risk intervention.

In legal procedure, filings, notice, jurisdictional requirements, and discovery may need to occur before a hearing or judgment can validly proceed.

In manufacturing, surface preparation and inspection must precede coating or assembly steps that would lock in defects.

prose_non_examples:
Alphabetizing a bibliography is not Dependency Ordering. It creates a stable presentation order, but one entry does not depend on another.

First-come-first-served ticket handling is not Dependency Ordering when tickets are independent. It is a queue discipline.

A ceremonial executive signoff is not Dependency Ordering unless the signoff verifies a real prerequisite condition.

A single rigid checklist is not necessarily Dependency Ordering. It becomes this archetype only when the checklist reflects actual prerequisite relations.

A process where every operation is genuinely order-independent does not need Dependency Ordering. It may need Order-Independent Processing instead.

prose_tradeoffs:
The main tradeoff is validity versus speed. Prerequisite checks slow apparent early movement but prevent waste and failure later.

Another tradeoff is explicitness versus maintenance overhead. A dependency map improves coordination only while it remains current.

There is also a tradeoff between safety and flexibility. Hard prerequisites protect the system, but if they are overused they can block adaptive action.

Finally, there is a tradeoff between partial-order complexity and simple-sequence clarity. A simple sequence is easy to follow, but a partial order may be more accurate and faster because it allows independent work to proceed in parallel.

prose_invariants_to_preserve:
The main invariant is prerequisite satisfaction: no dependent action proceeds unless the conditions it relies on are already true or explicitly waived.

A second invariant is dependency traceability. Each hard order constraint should point to a real prerequisite, not merely tradition, rank, preference, or habit.

A third invariant is valid state progression. The system should move from valid state to valid state, rather than producing out-of-domain, unsafe, or procedurally invalid intermediate states.

A fourth invariant is parallelism preservation. Dependency Ordering should not turn all work into a single sequence. Independent branches should remain independent.

prose_target_outcomes:
A successful Dependency Ordering intervention reduces rework because missing prerequisites are caught before downstream effort begins. It reduces invalid sequences because actions are attempted only from states where they can succeed or be interpreted.

It also improves coordination. Participants can see what they are waiting for, what can proceed independently, and what evidence is required to advance. In safety-critical contexts, it protects people from irreversible or high-risk action before diagnostic, legal, technical, or consent conditions are met.

prose_parameter_dimensions:
Dependency granularity determines how small the units in the map should be. Coarse maps are easier to maintain but can hide blockers. Fine-grained maps reveal more structure but create overhead.

Order strictness determines which relations are hard prerequisites, soft preferences, or conventions. Too much strictness slows the system; too little strictness permits invalid progression.

The readiness evidence threshold determines what counts as proof that a prerequisite is satisfied. A high threshold protects safety and quality, while a low threshold preserves speed but increases risk.

Exception policy determines when a dependency can be bypassed and how the bypass is governed. No exceptions can freeze a system; casual exceptions destroy the intervention.

Parallelization policy determines which branches can proceed independently once hard prerequisites are satisfied. Good Dependency Ordering should enable safe parallelism rather than defaulting to a single serial chain.

Maintenance cadence determines how often dependencies are reviewed. Dependencies can change as designs, laws, suppliers, environments, teams, and technologies change.

prose_variants_and_near_names:
Prerequisite-Gate Ordering is a recognized variant where explicit gates prove prerequisites before advancement. It should remain under Dependency Ordering when the gate exists mainly to verify readiness. If the gate logic becomes mostly about approval, certification, or staged governance, it belongs nearer Stage-Gate Progression.

Critical-Path Dependency Ordering is a candidate variant where the dependency chain controlling duration or risk receives special attention. It remains a variant unless path-length governance develops distinct cross-domain components and failure modes.

Near names include prerequisite ordering, dependency sequencing, and precedence ordering. Topological sort, sorting, dependency graphs, prerequisite matrices, and runbooks should be treated as mechanisms or artifacts rather than standalone archetypes.

Mastery-Gate Progression is a promotion candidate for later review. It uses dependency order but may deserve separate treatment in learning contexts because assessment validity, remediation, and learner progression introduce distinct concerns.

Prerequisite-Gate Ordering

short_definition: Uses explicit gates to prove prerequisites are satisfied before dependent work advances.

distinctive_feature: The order is enforced through inspectable readiness gates rather than only through a planned sequence.

distinct_from_parent: The parent can impose a dependency order without any formal approval checkpoint; this variant adds explicit gate evidence.

still_same_parent_because: The reason for the gate is prerequisite satisfaction, not generic approval, stakeholder sign-off, or quality review.

use_when: Prerequisites are safety-critical, regulated, expensive to redo, or difficult to verify informally.

use_when: The system needs visible evidence of readiness rather than tacit sequencing knowledge.

Prerequisite Check

role: Confirms that required upstream conditions are present before the gate opens.

Completion Evidence

role: Provides inspectable proof that a predecessor has produced the needed output or state.

Stage Gate

role: Serves as the optional checkpoint mechanism that enforces the prerequisite rule.

Checklist Gate

role: A checklist or signoff artifact records readiness before advancement.

Release Readiness Review

role: A review meeting verifies deployment prerequisites before launch.

example_domains:
software release
clinical procedure
capital project
education

domain: software release

example: A service cannot deploy until integration tests, rollback plans, and dependency migrations are complete.

domain: clinical procedure

example: An intervention is delayed until diagnosis, consent, and stabilization prerequisites are confirmed.

failure_modes: Gate bureaucracy replaces dependency reasoning.

failure_modes: Gate evidence becomes stale while the system state changes.

Critical-Path Dependency Ordering

short_definition: Orders dependent work while highlighting the dependency chain that controls total duration, risk, or delivery timing.

distinctive_feature: It adds path-length and bottleneck attention to the prerequisite graph.

distinct_from_parent: The parent asks whether a step may validly occur; this variant also asks which dependency chain governs schedule or risk.

still_same_parent_because: The ordering remains driven by prerequisites; timing optimization is a secondary emphasis.

source_primes: order pipeline boundedness

use_when: Several dependency-valid orders exist, but some orders create avoidable delay or bottleneck risk.

use_when: The dominant problem is not merely invalid sequence but the time exposure of prerequisite chains.

Dependency Map

role: Shows predecessor-successor links that can form long chains.

Critical Path Marker

role: Identifies the dependency chain that deserves priority attention.

Critical Path Method

role: Calculates dependency paths and highlights the controlling chain.

Project Network Diagram

role: Visualizes task dependencies and slack.

example_domains:
construction
manufacturing
software delivery
event planning

domain: construction

example: Foundation cure time controls when framing and utilities can begin.

failure_modes: Schedule optimization hides non-time prerequisites such as safety, legality, or consent.

near_names:
Prerequisite Ordering
Dependency Sequencing
Precedence Ordering
Topological Sort
Dependency Graph


name: Design-Principle Extraction and Reapplication

batch: Second Iteration/Batch 04

aliases: analogical design principle reapplication

alias_records: analogical design principle reapplication

slug: abstraction

slug: analogy

slug: optimization

slug: decomposition

slug: invariance

slug: adaptation

slug: validation

components:
Source Artifact Selection Frame
Function-Behavior-Structure Map
Constraint and Context Inventory
Optimization Objective Trace
Essential/Incidental Feature Filter
Design Principle Abstraction
Target Context Translation Map
Adaptation Hypothesis
Reapplication Prototype
Transfer Validation Loop
Provenance and Rights Boundary
Negative Case Comparison
Multi-Source Principle Triangulation
Scale Shift Assessment
Implementation Capacity Screen

mechanisms:
Teardown Workshop
Function-Behavior-Structure Matrix
Constraint Laddering Interview
Essential/Incidental Feature Sort
Design Principle Card
Analogy Mapping Canvas
Benchmark Deconstruction Grid
Biomimetic Translation Sheet
Transfer Prototype Experiment
Post-Transfer Boundary Review
IP and Provenance Checklist

essence_one_line: Learn from a source artifact or practice by extracting the design principle that makes it work, then reapply that principle to a new context after translating constraints and validating fit.

compression_statement: A reverse-engineering transfer archetype that converts an existing artifact, system, routine, or natural structure into a reusable design lesson. It decomposes the source into function, behavior, structure, constraints, tradeoffs, and optimization objectives; abstracts the invariant principle behind the observed success; separates that principle from incidental style, history, material, scale, and local constraint; maps the receiving context's constraints; creates an adapted reapplication; and validates whether the new design preserves the source logic while meeting the target context's needs.

core_intuition: Copying a successful artifact often fails because the visible form is only the surface expression of a deeper logic. A leaf vein, aircraft wing, interface pattern, supply-chain routine, or competitor feature works because specific structures solve specific constraints under specific conditions. The useful lesson is not merely what the source looks like. It is the function-constraint relationship that explains why the source works. Once that relationship is abstracted, the receiving design can imitate the principle while changing the materials, scale, language, governance, incentives, or user experience.

canonical_formula: transferable_design_value = validated_reapplication(source_function + source_constraints + source_structure + optimization_logic - surface_mimicry - source_specific_artifacts)

structural_problem: A designer, organization, researcher, or institution sees an effective external artifact or practice and wants to reuse its value, but the source's working logic is entangled with surface features, local constraints, tacit know-how, historical accidents, materials, scale, incentives, or context. Direct copying risks cargo-cult imitation, while ignoring the source wastes a transferable lesson.

trigger_conditions: A source artifact, system, organism, process, competitor feature, or institutional practice performs unusually well and appears worth learning from.

trigger_conditions: The receiving context differs from the source context in scale, users, materials, incentives, regulation, culture, climate, data, infrastructure, or organizational maturity.

trigger_conditions: The visible source form is tempting to copy, but it is unclear which feature actually produces the desirable performance.

trigger_conditions: Stakeholders want to adapt a best practice, benchmark, biomimetic pattern, design precedent, or open-source implementation to a new use case.

trigger_conditions: A team must preserve the source's functional logic while changing implementation details to fit target constraints.

trigger_conditions: The source includes tacit decisions, hidden tradeoffs, or optimization priorities that are not explicit in documentation.

trigger_conditions: Prior copying attempts reproduced the appearance of a source but failed to reproduce its benefits.

trigger_conditions: A learning or design process needs a disciplined bridge between observation, abstraction, adaptation, and validation.

symptoms: Teams describe an external example as inspiring but cannot state the principle that should transfer.

symptoms: Benchmarking produces feature lists rather than causal explanations or design hypotheses.

symptoms: A copied design pattern performs poorly because source assumptions about scale, data, users, incentives, materials, or maintenance do not hold.

symptoms: Different stakeholders argue over whether the source should be copied, rejected, or merely admired because the transferable core is unnamed.

symptoms: Design reviews focus on resemblance to the source rather than fit to the receiving problem.

symptoms: The target implementation preserves incidental aesthetics while losing the structure that made the original effective.

symptoms: Adapted practices are adopted ceremonially as best practices without measuring whether the relevant outcomes improve.

symptoms: Reverse-engineering work produces detailed parts lists but no reusable abstraction or transfer rule.

root_tension: The source is valuable because it is concrete and proven in context, but transfer requires abstraction away from that context. Too little abstraction becomes imitation; too much abstraction becomes vague inspiration. The archetype manages this by extracting a testable design principle and then re-grounding it in target-context constraints.

anti_signatures: The goal is only to document or expose how an artifact is assembled, with no transfer or reapplication intent.

anti_signatures: The source must be replicated exactly for compatibility, audit, restoration, or legal reasons; use direct reconstruction rather than principle transfer.

anti_signatures: The relevant lesson is already a known design pattern that can be applied directly without new source analysis.

anti_signatures: The source is being copied mainly for prestige, aesthetics, or branding rather than functional learning.

anti_signatures: The source cannot be inspected enough to infer function, behavior, constraints, or tradeoffs.

anti_signatures: The target context has hard constraints that make the source principle inapplicable, not merely in need of translation.

anti_signatures: The central issue is whether the source's apparent purpose should be inferred from function; use function_without_intent_caution for that interpretive problem.

anti_signatures: The task is competitive intelligence or legal compliance only, with no design abstraction or reapplication.

structural_intervention: Install a source-to-principle-to-target transfer loop: choose a source whose performance matters; decompose its observed form into functions, structures, behaviors, constraints, and tradeoffs; infer candidate principles that explain the performance; separate invariant design logic from source-specific artifacts; map the receiving context; adapt the principle into one or more target designs; prototype or pilot the reapplication; and validate whether the transferred principle works under target conditions.

action_logic: Define the desired learning target: what outcome, function, capability, efficiency, resilience, usability, or coordination advantage should the source help transfer?

action_logic: Select source artifacts or practices with enough evidence of performance and enough inspectability to support responsible inference.

action_logic: Decompose the source into functional goals, observable behaviors, structural features, interfaces, materials, rules, incentives, environmental conditions, and constraints.

action_logic: Identify the optimization objective or tradeoff the source appears to solve, such as minimizing waste, improving flow, increasing robustness, coordinating roles, or reducing cognitive load.

action_logic: Generate candidate design principles that explain the source's performance and mark which observed features are likely essential, optional, incidental, or context-specific.

action_logic: Test candidate principles against negative cases, alternative sources, expert review, historical evidence, simulations, or small experiments when available.

action_logic: Map the receiving context's constraints, users, materials, incentives, risks, implementation capacity, and evaluation criteria.

action_logic: Translate the principle into a target-context design that preserves the source logic while changing surface form, scale, medium, governance, or process as needed.

action_logic: Prototype, simulate, pilot, or otherwise validate the reapplication against the target outcome and compare it with both the source logic and local alternatives.

action_logic: Document the resulting principle, boundary conditions, failed transfer attempts, and future adaptation guidance so the learning can compound.

decision_rules: If a source feature cannot be linked to a function or constraint, treat it as incidental until evidence shows otherwise.

decision_rules: If the target context lacks a constraint that was central to the source solution, do not copy the source response to that constraint without redesign.

decision_rules: If multiple source artifacts solve the same function differently, abstract the shared function-constraint relation rather than choosing the most visible form.

decision_rules: If a proposed reapplication preserves appearance but not the underlying tradeoff logic, classify it as surface mimicry and revise.

decision_rules: If the source involves protected intellectual property, proprietary knowledge, community knowledge, or living systems, add legal, ethical, and provenance review before reuse.

decision_rules: If the principle cannot be expressed as a target-context hypothesis, it is not yet ready for implementation.

decision_rules: If a prototype fails, distinguish failure of the extracted principle from failure of translation, scale, implementation, or measurement.

decision_rules: If the reapplication succeeds only under narrow conditions, record those boundary conditions instead of generalizing the principle too broadly.

target_invariants: The source's functional logic must be distinguished from its visible form.

target_invariants: The receiving context's constraints must be explicitly mapped before reapplication.

target_invariants: The extracted principle must be stated in testable, reusable language rather than as admiration or metaphor.

target_invariants: Surface features must not be copied unless they are causally connected to the target outcome.

target_invariants: Boundary conditions and negative cases must travel with the transferred principle.

target_invariants: Ethical, legal, and provenance limits on learning from the source must be respected.

target_invariants: Validation must test target-context performance, not just resemblance to the source.

target_invariants: The process must preserve room for adaptation rather than forcing target users into the source context's assumptions.

expected_outcomes: More reliable learning from precedents, competitors, natural systems, and organizational practices.

expected_outcomes: Reduced cargo-cult copying and fewer failed best-practice transfers.

expected_outcomes: Reusable design principles that can be documented, taught, recombined, and adapted.

expected_outcomes: Better fit between imported lessons and target-context constraints.

expected_outcomes: More defensible innovation because inspiration is translated into explicit hypotheses and validation tests.

expected_outcomes: Improved cross-domain transfer without confusing analogy, imitation, and verified design logic.

prose_essence:
Design-Principle Extraction and Reapplication is a disciplined way to learn from an existing artifact, process, organism-like structure, benchmark, or organizational practice without merely copying its surface. The central move is to ask: *what function-constraint relationship makes the source work, and how can that relationship be translated into the target context?*

The archetype is most useful when a source example is impressive but not directly portable. A leaf vein, a competitor onboarding flow, an aviation checklist, a modular software architecture, or another city’s transit design may contain a useful lesson. But the lesson is not the whole source. It is the source’s transferable logic: the way structure, behavior, constraints, and objectives interact to produce a result.

prose_intervention_logic:
The intervention starts by defining the learning target. What capability, performance improvement, resilience, efficiency, usability, or coordination advantage is the source supposed to help create? Once that target is explicit, the source is decomposed into functions, behaviors, structures, constraints, tradeoffs, and context.

The key step is feature filtering. Some source features are essential because they directly support the working logic. Others are optional, historical, aesthetic, material-specific, scale-specific, or accidental. The archetype asks the team to separate those categories before adaptation.

A usable extracted principle usually has this form:

> Under these constraints, this structural arrangement produces this function by managing this tradeoff.

That principle is then translated into the receiving context. The target may use different materials, governance, incentives, language, users, technical architecture, or scale. The reapplication should preserve the design logic, not the source’s surface form. Finally, the adapted design is prototyped or piloted and validated against target outcomes.

prose_key_components:
### Source Artifact Selection Frame

The source must be worth learning from. A team should know what performance evidence makes the source interesting and what uncertainty remains. A famous source is not automatically a good source.

### Function-Behavior-Structure Map

This map separates what the source is for, what it does, and how it is organized. It protects against mistaking visible structure for the whole explanation.

### Constraint and Context Inventory

The source worked under specific constraints. These may include materials, users, scale, regulation, economics, climate, culture, incentives, timing, maintenance capacity, or historical development. Many “features” are actually responses to those constraints.

### Optimization Objective Trace

The team identifies what tradeoff the source seems to optimize. It may reduce waste, increase robustness, preserve optionality, lower cognitive load, speed handoffs, distribute flow, or make exceptions visible.

### Essential/Incidental Feature Filter

This is the main defense against cargo-cult design. Every source feature is classified as essential, supporting, optional, accidental, or source-specific. Features that do not carry the design logic should not be copied merely because they are visible.

### Design Principle Abstraction

The extracted principle converts source analysis into reusable design knowledge. It should be specific enough to guide a target design and testable enough to be wrong.

### Target Context Translation Map

The receiving context has its own constraints. The translation map asks what must change so the principle can function under those constraints.

### Reapplication Prototype and Transfer Validation Loop

The adapted principle must be tested. A prototype, simulation, pilot, or controlled comparison can reveal whether the principle transferred, whether translation failed, or whether the source was misunderstood.

### Provenance and Rights Boundary

Reverse-engineering can cross ethical, legal, and trust boundaries. The process must track intellectual property, confidentiality, attribution, community knowledge, and safety limits.

prose_common_mechanisms:
A teardown workshop exposes parts and interfaces. A function-behavior-structure matrix documents how source structures produce behaviors that serve functions. A constraint laddering interview asks why each source feature exists. A benchmark deconstruction grid compares multiple sources so shared design logic can be separated from local implementation. A design principle card records the extracted principle, evidence, transfer conditions, and failure warnings. A transfer prototype experiment tests the adapted principle under target conditions.

These mechanisms are not the archetype by themselves. Benchmarking without abstraction is just comparison. Disassembly without reapplication is exposition. Biomimetic sketching without functional translation is visual borrowing. The archetype requires the full loop from source analysis to target-context validation.

prose_failure_modes: The most common failure is surface mimicry: copying what the source looks like instead of why it works. Another failure is over-abstraction, where the “principle” becomes too general to guide action. Source-context blindness ignores the conditions that made the source work. Target-context misfit imports a principle into a setting where the needed constraints or capacities do not exist. False causal inference credits the wrong feature for success. Appropriation risk appears when protected, proprietary, or community knowledge is reused without permission or attribution.

prose_neighbor_distinctions: This archetype is adjacent to Reverse-Engineered Learning, which may become its broader parent. It is distinct from Artifact Disassembly and Structure Exposition because it does not stop at exposing structure. It is distinct from Reverse-Engineering via Inversion because inversion is one way to infer hidden logic, not the whole transfer loop. It is distinct from Comparative Benchmark Validation because benchmarking checks performance against references, while this archetype extracts and adapts design logic from a reference. It is distinct from Function-Without-Intent Caution because that archetype warns against over-attributing purpose; this one focuses on responsible design transfer.

prose_non_examples: A mood board that borrows visual style is not this archetype. A parts diagram without transfer is not this archetype. A best-practice import that ignores local constraints is not this archetype. A regulatory copy adopted for political convenience is not this archetype unless the design logic is extracted, translated, and validated.

prose_tradeoffs: The more abstract a principle becomes, the easier it is to transfer but the easier it is to make vague. The more detailed the source analysis becomes, the more reliable it can be but the more effort it requires. Learning from competitors and precedents can accelerate design but can also narrow imagination. Provenance review protects trust and rights but may limit easy reuse.

prose_invariants_to_preserve: The source’s functional logic must remain distinct from its visible form. The target context must be mapped before reapplication. The extracted principle must be stated as a testable hypothesis, not a metaphor. Boundary conditions must travel with the principle. Ethical and legal limits must be respected. Success must be judged by target performance, not by resemblance to the source.

Biomimetic Principle Transfer

short_definition: Extract a functional principle from a biological or ecological source and translate it into a human design context.

distinctive_feature: The source is a living or ecological system whose material, scale, and evolutionary constraints differ sharply from the target setting.

distinct_from_parent: It adds biological interpretation, scale translation, and nature-inspired analogy risks.

still_same_parent_because: The core process remains source analysis, principle abstraction, target-context translation, and validation.

source_primes: reverse_engineering analogy abstraction

use_when: A natural structure or process appears to solve a design problem under relevant constraints.

use_when: The target design must translate function rather than copy biological form literally.

example_domains:
architecture
materials engineering
water management
robotics

domain: water systems

example: Use leaf-vein branching as a source for distributed flow redundancy.

failure_modes: Literal shape copying without verifying function

name: Competitive Benchmark Principle Extraction

short_definition: Study competitor or peer performance to infer transferable design principles rather than copy visible features.

distinctive_feature: It is shaped by competitive intelligence, legal boundaries, and benchmarking evidence.

distinct_from_parent: The parent can learn from any source; this variant specializes in market or peer examples.

still_same_parent_because: It still extracts source logic, translates it to a target context, and validates local performance.

use_when: A competitor, peer institution, or reference product outperforms on a target outcome.

use_when: The team needs learning without illegal copying or surface mimicry.

example_domains:
software products
consumer devices
service design
business operations

domain: software

example: Extract progressive-disclosure principles from a competitor onboarding flow.

failure_modes: Mistaking brand advantage for design logic

Organizational Practice Reapplication

short_definition: Extract the operating principle behind another organization's practice and adapt it to local roles, incentives, capabilities, and governance.

distinctive_feature: The source is a social process with tacit routines and institutional dependencies rather than a physical artifact.

distinct_from_parent: It emphasizes incentives, roles, tacit knowledge, and change management.

still_same_parent_because: The pattern remains abstraction, translation, pilot, and validation of a source-derived principle.

use_when: A practice works in one organization and another organization wants to adapt it.

use_when: Local incentives, roles, or capacities differ enough that direct adoption would fail.

example_domains:
healthcare
education
public administration
operations

domain: healthcare

example: Adapt aviation checklist principles to surgical handoffs.

failure_modes: Ignoring tacit culture and incentive differences

name: Artifact Disassembly and Structure Exposition

short_definition: Expose the parts, interfaces, and structure of an artifact so its design can be understood.

distinctive_feature: It centers on revealing structure rather than transferring a principle.

distinct_from_parent: The parent requires reapplication; this variant may stop at exposition.

still_same_parent_because: When used for transfer, disassembly supplies evidence for principle abstraction.

use_when: The first need is to understand how an artifact is built or organized.

use_when: Transfer may come later, but the immediate gap is structural exposition.

example_domains:
hardware teardown
software architecture analysis
process mapping

domain: hardware

example: Disassemble a device to map component interfaces.

failure_modes:
Parts-list thinking
No causal or transfer inference

Reverse-Engineering via Inversion

short_definition: Infer hidden inputs, rules, or generative mechanisms by working backward from observed outputs or behavior.

distinctive_feature: It works backward from outputs rather than decomposing an inspectable source.

distinct_from_parent: The parent may use inversion, but it requires target-context reapplication and validation of a design principle.

still_same_parent_because: Inversion can supply the inferred source logic that later becomes transferable design learning.

use_when: The source's internal structure must be inferred indirectly.

example_domains:
black-box model analysis
algorithmic behavior inference
legacy system reconstruction

example: Infer an algorithm's ranking logic from repeated outputs.

failure_modes:
Overfitting to observed outputs
Mistaking correlation for internal rule

near_names:
Reverse-Engineered Learning
Design Logic Extraction
Principle Abstraction and Transfer
Artifact-to-Principle Transfer