Platform Core / Extension Design

batch: Batch 24

canonical_family: Interfaces, Roles & Interoperability

source_primes: platform_design modularity interface interoperability

related_primes: versioning composition boundary abstraction indirection scalability network_effect economies_of_scale access_control governance resilience constraint resource_management feedback data_integrity

slug: modularity

slug: interface

slug: interoperability

slug: versioning

slug: composition

slug: boundary

slug: abstraction

slug: indirection

slug: scalability

slug: governance

slug: resilience

slug: constraint

components: Platform Compatibility and Conformance Policy

components: Extension Identity, Discovery, and Registration

components: Platform Dependency and Permission Model

components: Platform Versioning, Deprecation, and Migration Policy

components: Platform Security, Quality, and Safety Guardrail

components: Platform Ecosystem Access and Incentive Rule

components: Platform Observability and Ecosystem Health Signals

components: Platform Portability, Exit, and Contingency Path

mechanisms: Platform Sandbox and Capability Permissions

mechanisms: Platform Semantic Versioning and Release Train

mechanisms: Platform Extension Review and Certification

mechanisms: Platform Migration and Deprecation Tooling

mechanisms: Platform Extension Health and Dependency Dashboard

essence_one_line: Create a stable shared core with explicit extension surfaces, contracts, lifecycle governance, compatibility, safety, evolution, and exit so many independently built variations can reuse the same foundation.

compression_statement: Platform Core / Extension Design converts repeated capability and variation into a maintained architecture. It defines why a platform should exist, keeps the core minimal and invariant, exposes deliberate extension zones, governs extension identity and lifecycle, specifies contracts, dependencies, permissions, compatibility, conformance, security, versioning, migration, ecosystem access, observability, portability, and exit. The core supplies durable leverage while extensions preserve variety and independent innovation. Neither uncontrolled openness nor central ownership of every feature qualifies.

core_intuition: A platform creates leverage when builders can rely on a small stable foundation and add value through supported surfaces faster and more safely than they could rebuild or modify the core. That leverage survives only if the platform governs change, compatibility, participation, failure, power, and exit as carefully as it designs interfaces.

canonical_formula: platform leverage ≈ reusable core value × extension autonomy × contract stability × ecosystem trust / (core bloat + coupling + migration burden + gatekeeper power + extension risk)

structural_problem: Many products, teams, systems, or participants repeatedly need common capabilities and controlled variation, but reuse is trapped inside monoliths, duplicated implementations, bespoke integrations, unstable interfaces, or operator-controlled ecosystems without governed extension and evolution.

trigger_conditions: Multiple builders repeat foundational capability while differentiating at the edges.

trigger_conditions: A shared core could reduce fixed cost or improve trust, quality, compatibility, or discovery.

trigger_conditions: Independent extensions need stable surfaces without access to core internals.

trigger_conditions: Core and extension changes must evolve on different cadences.

trigger_conditions: Participants need discoverable capabilities, predictable governance, and migration support.

trigger_conditions: Network or ecosystem effects could amplify value and power.

symptoms: The core absorbs requests until it becomes slow and fragile.

symptoms: Undocumented hooks become permanent dependencies.

symptoms: Extensions break after releases or require bespoke integration.

symptoms: A registry or marketplace grows without compatibility, security, or exit governance.

symptoms: Platform teams measure adoption while builders experience high cognitive and migration burden.

symptoms: Shared services become mandatory bottlenecks rather than enabling foundations.

symptoms: Participants cannot port value or predict rule changes.

symptoms: Local teams rebuild capabilities because supported services are undiscoverable or inflexible.

symptoms: The platform operator competes with dependent participants under opaque rules.

root_tension: The core must be stable and common enough to create reuse, compatibility, trust, and ecosystem leverage, yet thin and governable enough to preserve extension autonomy, local fit, innovation, exit, and adaptation.

anti_signatures: Only one product or actor needs the capability and no extension ecosystem is expected.

anti_signatures: Variation is rare enough that ordinary configuration or a slot template is sufficient.

anti_signatures: The primary objective is scaling throughput or reducing unit cost rather than supporting extensions.

anti_signatures: The primary problem is enabling independent systems to exchange through a standard without sharing a platform core.

anti_signatures: A prototype is needed only to test an assumption before implementation.

anti_signatures: The proposed core has no stable responsibility or governance owner.

structural_intervention: Design and govern a minimal stable core plus explicit extension surfaces and a full extension lifecycle, including identity, contracts, discovery, dependency and permission boundaries, compatibility, conformance, security, versioning, migration, ecosystem participation, observability, portability, and exit.

action_logic: Define the participant groups, recurring shared capability, outcome, and non-goals that justify a platform.

action_logic: Decide the smallest coherent responsibilities and guarantees that belong in the stable core.

action_logic: Map extension zones and supported surfaces while closing accidental internal hooks.

action_logic: Specify behavioral contracts, lifecycle events, errors, performance, and compatibility for each extension point.

action_logic: Provide identity, registration, discovery, provenance, ownership, dependency, and permission models for extensions.

action_logic: Create conformance, security, quality, safety, isolation, and risk-tier review controls.

action_logic: Govern proposal, release, update, suspension, transfer, deprecation, and retirement across the extension lifecycle.

action_logic: Version core and contracts, expose support windows, and provide migration, fallback, and rollback paths.

action_logic: Align access, contribution, distribution, cost, ranking, governance voice, portability, and exit with shared value.

action_logic: Instrument core, extension, dependency, migration, concentration, burden, and participant health.

action_logic: Evolve the platform through transparent change governance while resisting core bloat, lock-in, and operator capture.

decision_rules: Place a capability in the core only when shared ownership creates durable leverage or protects a platform-wide invariant.

decision_rules: Keep differentiated domain logic in extensions unless its duplication creates unacceptable risk or incompatibility.

decision_rules: Expose supported contracts rather than internals; treat accidental dependence as migration debt.

decision_rules: Scale review depth with extension privilege, propagation risk, irreversibility, and affected-party consequence.

decision_rules: Preserve backward compatibility when its ecosystem value exceeds complexity; otherwise coordinate an explicit breaking migration.

decision_rules: Use adapters and compatibility layers temporarily, with owners and retirement conditions.

decision_rules: Do not require platform adoption when independent alternatives impose no material interoperability or safety cost.

decision_rules: Treat fees, ranking, access, data, and self-preferencing rules as governance, not implementation details.

decision_rules: Measure builder and participant outcomes alongside core utilization and growth.

decision_rules: Maintain a credible path to export, substitute, federate, or exit.

target_invariants: The platform purpose and core responsibility remain bounded and explainable.

target_invariants: Extensions depend on supported contracts rather than undocumented internals.

target_invariants: Core changes preserve declared compatibility or provide governed migration.

target_invariants: Extension identity, owner, provenance, permissions, dependencies, and lifecycle state remain traceable.

target_invariants: Core and extension failures are isolated in proportion to risk.

target_invariants: Entry, review, distribution, suspension, and appeal criteria remain legible and consistently applied.

target_invariants: Builders retain meaningful autonomy inside extension contracts.

target_invariants: Participants can detect material platform and rule changes before they become irreversible.

target_invariants: Safety, security, privacy, accessibility, fairness, and public-interest constraints survive growth pressure.

target_invariants: Portability and exit remain operational rather than symbolic.

expected_outcomes: Builders reuse high-value capabilities without modifying or forking the core.

expected_outcomes: Extensions can be developed, tested, released, discovered, upgraded, and retired independently within contracts.

expected_outcomes: Compatibility incidents and bespoke integrations decline.

expected_outcomes: Core change becomes slower and more deliberate while extension innovation remains faster.

expected_outcomes: Participant onboarding and time to first extension improve.

expected_outcomes: Platform-wide risk is detected and contained without reviewing every low-risk extension identically.

expected_outcomes: Migration and deprecation burden becomes visible and shared.

expected_outcomes: Ecosystem value grows without proportional lock-in, concentration, or operator discretion.

expected_outcomes: The platform can evolve or be replaced without catastrophic loss of participant value.

prose_essence:
Platform Core / Extension Design creates a shared foundation that many independent builders can rely on and extend without changing the foundation for every variation. The decisive structure is not simply reuse, modularity, scale, or an API. It is a maintained partition between a minimal stable core and governed extension surfaces, together with the contracts, identity, compatibility, safety, versioning, ecosystem, and exit rules that keep the partition useful over time.

A platform succeeds when the core provides durable leverage while extensions preserve differentiated value and local autonomy. The core should own capabilities whose shared implementation protects an invariant, reduces repeated burden, creates interoperability, or sustains trust. Everything else should remain outside unless evidence shows that extension is unsafe or structurally infeasible.

Platform leverage is relational. Builders must trust the core contract, participants must trust ecosystem governance, and the operator must be able to contain harmful extensions without arbitrary power. An extensible system without lifecycle governance becomes fragile; a governed core without meaningful extension becomes a monolith or shared service.

prose_when_to_use:
Use this archetype when several products, teams, systems, institutions, or complementors repeatedly need common foundational capabilities while also needing independent variation. Strong cases include internal developer platforms, product families, research infrastructure, public digital foundations, payment ecosystems, learning platforms, shared organizational capabilities, and tool ecosystems.

The pattern becomes relevant when core and edge need different rates of change. Identity, audit, safety, data integrity, or transaction primitives may need deliberate evolution, while domain features and extensions must change quickly. A platform lets those cadences coexist through stable contracts and versioned migration.

Another trigger is repeated bespoke integration. If every new participant negotiates a unique connection, the system may need shared extension surfaces, conformance, discovery, and lifecycle governance. Repeated forks and local copies are also a signal that the foundation does not expose enough supported variation.

Do not use the archetype merely because “platform” sounds strategic. If only one product exists, if extension demand is speculative, or if no team can sustain contracts, support, governance, and migration, ordinary modular architecture is more honest. If the objective is only cost pooling, scale growth, interoperability standards, stable templates, or prototype learning, use the narrower accepted neighbor.

prose_structural_problem:
Platform problems begin with a reuse–variation tension. Common capabilities are expensive, risky, or trust-sensitive enough to share, but participants need different domain behavior and cannot wait for every request to enter one core backlog. Without a deliberate boundary, two pathologies appear: duplicated foundations and an expanding monolith.

Duplicated foundations waste effort and fragment identity, data, semantics, security, accessibility, and user experience. The monolith centralizes every feature, slows change, couples failures, and transfers local knowledge to a platform team that cannot possess it. Both destroy the leverage a platform should create.

Accidental extensibility is another structural failure. Internal tables, undocumented hooks, copied libraries, and operator exceptions become de facto contracts. Dependents cannot predict changes, and the core cannot evolve without breakage. A platform must decide which surfaces it supports and migrate accidental dependents rather than silently accepting them forever.

Ecosystem power compounds technical coupling. The operator may control entry, ranking, data, fees, interfaces, and exit while competing with extensions. Growth can conceal dependency concentration, unfair burden, or systemic fragility. Platform design therefore includes governance and portability, not only architecture.

prose_intervention_logic:
Begin with purpose. Identify the recurring shared capabilities, participant groups, expected value, and non-goals that justify a platform. A shared capability belongs in the core only when common ownership creates durable leverage or protects a system-wide invariant.

Define the core as a responsibility boundary. State its guarantees, owner, change threshold, and exclusions. Then map extension zones: what builders may configure, augment, replace, compose, register, distribute, or federate. Close accidental internal hooks and replace them with supported contracts.

Specify each extension point as behavior, not only syntax. Include lifecycle, events, errors, timeouts, performance, compatibility, failure containment, and observability. Add a registry and manifest model so extension identity, ownership, provenance, dependencies, permissions, versions, and lifecycle state remain traceable.

Calibrate governance by risk. Low-risk extensions should face lightweight, predictable entry. High-privilege or high-consequence extensions need deeper conformance, security, quality, accessibility, safety, and evidence review. Every consequential decision needs reasons, conflict controls, appeal, and revalidation.

Govern evolution as a shared transition. Version contracts, publish support windows, inventory dependents, provide migration tools and adapters, stage breaking changes, preserve rollback, and close deprecated surfaces with evidence. Compatibility is an economic and governance choice, not an unlimited technical promise.

Finally, measure the whole ecosystem. Core uptime and extension count are insufficient. Track builder burden, dependency concentration, extension failure, compatibility, migration, safety, accessibility, participant value, portability, and exit. Use those signals to change the core boundary, contracts, access, and governance.

prose_key_components:
### Platform Purpose and Value Boundary

This component states why a platform should exist, whom it serves, which repeated capability it shares, and what remains out of scope. It prevents speculative platform work and exposes whether the true objective is reuse, trust, interoperability, scale, ecosystem participation, or operator control.

### Stable Core Responsibility

The stable core owns minimal invariant capabilities and guarantees. “Common” is not enough; a core capability should create durable cross-participant leverage or protect a foundation-wide constraint. A thin core is easier to evolve and less politically attractive, but too thin a core can duplicate risk-sensitive work.

### Extension Zone and Surface Map

The map names supported locations and forms of variation and distinguishes them from closed internals. It records whether extensions configure, augment, replace, compose, subscribe, contribute, or federate. It also defines failure containment.

### Extension Point Contract

A real extension contract specifies lifecycle and failure semantics as well as inputs and outputs. Builders need to know initialization, events, timeouts, concurrency, errors, performance, observability, shutdown, and version compatibility. A function signature alone is not enough.

### Platform Capability and Service Catalog

The catalog makes supported capabilities, contracts, owners, versions, access, status, examples, and support discoverable. It reduces shadow duplication and directs builders away from internal hooks. Every listing needs an accountable maintainer and clear experimental, supported, deprecated, or retired state.

### Modularity and Isolation Boundary

Isolation keeps extension change, failure, resource use, security, and ownership local where possible. Technical platforms may use processes, sandboxes, quotas, or network boundaries. Product and institutional platforms use responsibility, funding, authority, and service boundaries. Names alone do not create containment.

### Platform Compatibility and Conformance Policy

This policy defines what extensions must preserve and how evidence is obtained. Compatibility may include semantics, safety, quality, accessibility, timing, data integrity, and governance. Conformance can be self-attested, automated, reviewed, certified, or tiered by risk.

### Extension Identity, Discovery, and Registration

Extensions need stable identity, provenance, owner, versions, status, and discoverability. Registration makes approval, update, suspension, transfer, and retirement possible. It should not become opaque gatekeeping.

### Platform Dependency and Permission Model

The model declares direct and transitive dependencies, platform capabilities, data scopes, resource limits, and prohibited interactions. Least privilege reduces supply-chain and propagation risk. Permissions must be revocable and connected to meaningful audit.

### Platform Versioning, Deprecation, and Migration Policy

Platforms cannot preserve every contract forever. This policy makes change predictable through version semantics, support windows, notice, dependency evidence, tooling, staged migration, fallback, rollback, and retirement authority. Migration cost should not be invisibly dumped on dependents.

### Extension Lifecycle Governance

The lifecycle covers proposal, review, registration, release, distribution, update, monitoring, suspension, ownership transfer, deprecation, and retirement. It distinguishes experimental surfaces from supported ones and gives abandoned or harmful extensions an orderly path out.

### Platform Security, Quality, and Safety Guardrail

Extensibility increases attack, abuse, quality, and systemic-risk surface. Guardrails use threat and harm models, minimum controls, risk tiers, containment, detection, response, and remedy. Passing a pre-release checklist never eliminates runtime responsibility.

### Platform Ecosystem Access and Incentive Rule

Access, discovery, ranking, fees, data, contribution, governance voice, and exit shape who can create value and who captures it. These are architectural governance choices. Transparent criteria and conflict controls matter most when the operator competes with dependents.

### Platform Observability and Ecosystem Health Signals

Health signals connect core reliability and extension behavior to dependency, concentration, migration, burden, and participant outcomes. Usage, extension count, and operator revenue can rise while the platform becomes more fragile or extractive.

### Platform Portability, Exit, and Contingency Path

Portability covers usable state, identity, configuration, contracts, and value—not only raw export. Exit includes substitution, fallback, federation, ownership transfer, continuity, and residual obligations. A credible exit path disciplines platform power and improves resilience.

prose_common_mechanisms:
### Platform Architecture Blueprint

The blueprint records purpose, core responsibilities, extension zones, contracts, governance, and non-goals. It is a decision record, not a decorative system diagram, and should change only through accountable review.

### Platform API and SDK

APIs and SDKs expose supported core capabilities and reduce correct-use cost. They should implement contracts rather than leak internals, provide safe defaults, and remain synchronized with specifications and examples.

### Plugin and Extension Registry

The registry supplies authoritative identity, ownership, provenance, versions, permissions, compatibility, distribution metadata, and lifecycle state. It requires stale-record review, suspension, transfer, and appeal controls.

### Extension Manifest

A manifest declares dependencies, permissions, resources, extension points, compatibility, and lifecycle hooks in verifiable form. It automates policy but cannot prove that an extension is safe or truthful.

### Conformance Test Suite

The suite turns contracts and invariants into reusable evidence. Include errors, downgrade, migration, accessibility, performance, security, and adversarial cases—not only the happy path. Update tests after incidents and contract change.

### Sandbox and Capability Permissions

Isolation and least privilege contain extensions that execute code, access data, consume resources, or trigger side effects. Stronger integration may require more capability, but every grant should have purpose, owner, audit, and revocation.

### Semantic Versioning and Release Train

Version semantics and release cadence coordinate core, extensions, support, compatibility, and migration. Emergency fixes need an exception path, but routine breaking change should not be hidden as a minor release.

### Reference Implementation

A reference implementation makes intended use executable and demonstrates safe defaults, failure handling, conformance, and migration. It must not become the only permitted implementation when alternatives meet the contract.

### Extension Review and Certification

Risk-tiered review combines automated evidence and human judgment. Criteria, reviewers, conflicts, conditions, reasons, appeal, monitoring, and recertification should be visible. Review burden should be proportional to consequence.

### Migration and Deprecation Tooling

Dependency inventory, adapters, transforms, dual operation, staged rollout, progress views, and verification reduce the cost and risk of platform evolution. A deadline without a usable path is not migration governance.

### Capability Catalog and Portal

The portal makes supported capabilities and extension paths discoverable. It connects contracts, status, examples, ownership, support, access, versions, and migration. Ranking and curation should be transparent.

### Ecosystem Change Council

A representative body can govern breaking changes, access, fees, ranking, certification, and retirement. It needs actual authority, evidence, recusal, participant representation, decision records, and appeal rather than consultation theater.

### Extension Health and Dependency Dashboard

A bounded dashboard supports action on core and extension failures, dependency concentration, compatibility, migration, burden, safety, and participant outcomes. It should not become a surveillance or vanity-growth instrument.

prose_failure_modes:
**Core bloat** occurs when every common request becomes a core responsibility. Apply a strict admission rule and maintain explicit non-goals.

**Accidental platform** occurs when undocumented hooks and shared internals become permanent dependencies. Inventory dependents, publish supported surfaces, and migrate deliberately.

**Extension chaos** occurs when hooks lack identity, permissions, dependencies, conformance, monitoring, and revocation. Build the extension lifecycle before inviting scale.

**Platform monolith** occurs when the operator owns every feature and local teams lose meaningful autonomy. Move differentiated logic outward and improve extension capability.

**Interface ossification** occurs when compatibility has no review or retirement. Version, measure dependency, provide migration, and close support windows.

**Leaky abstraction** forces builders to understand internals. Improve contract completeness, adapters, observability, and failure semantics while acknowledging unavoidable leakage.

**Dependency and privilege sprawl** creates supply-chain and systemic risk. Declare transitive dependencies, enforce least privilege, and cap resources.

**Gatekeeper capture** concentrates entry, ranking, fees, data, rules, and competition. Use transparent criteria, conflicts controls, participant governance, appeal, and portability.

**Mandated adoption without value** turns the platform into a compliance burden. Measure builder outcomes, permit safe alternatives, and earn adoption.

**Migration burden dumping** lets the core move fast by forcing dependents to absorb cost. Share inventory, tooling, support, notice, and impact review.

**Ecosystem fragility** concentrates critical value in one provider, registry, extension, or interface. Build substitution, federation, fallback, and exit.

**Extension abandonment** leaves dependencies and risk after the owner disappears. Require ownership transfer, maintenance signals, deprecation, and retirement.

**Vanity ecosystem growth** counts extensions and activity while ignoring value, burden, safety, concentration, and compatibility. Use system health measures.

**Prototype-to-platform confusion** treats experimental surfaces as durable commitments. Label experiments, limit dependents, and require graduation evidence.

prose_neighbor_distinctions:
**Network Effect Bootstrapping** seeds participation or value until adoption becomes self-reinforcing. A platform can exist without network effects, and network effects can be bootstrapped without a governed extensible core.

**Scale Economy Consolidation** pools repeated activity to reduce unit cost. A shared service built for cost does not become a platform unless it supports independent governed extension.

**Network Effect Governance** controls lock-in, exclusion, power, abuse, portability, and fragility after self-reinforcing growth. It remains a focused governance neighbor.

**Scalable Architecture Design** prepares a system to grow along capacity, users, geography, organization, or another dimension. Platform design focuses extensible reuse and ecosystem lifecycle, not growth alone.

**Unity-Variety Balancing** preserves coherence while allowing variation. The platform parent adds extension identity, permissions, contracts, registry, lifecycle, migration, ecosystem access, and exit.

**Modular Decomposition** breaks complexity into bounded modules. A modular system may have no shared core or independent extension ecosystem.

**Interoperability Standardization** lets independent systems work together through shared standards. A standard can exist without platform capabilities, operator, registry, lifecycle, or ecosystem.

**Slot Template Design** supports bounded substitution into predefined slots. Platform extensions can have independent lifecycle, dependency, permissions, distribution, and governance.

**Compatibility Management** governs coexistence and migration across versions. It is one critical platform lifecycle concern rather than the full parent.

**Versioned Evolution** preserves lineage, comparison, reversibility, and audit across changes. It does not establish the core-extension architecture.

**Compositional Assembly** creates one coherent whole from selected parts. Platform design creates a foundation for open-ended future assembly and extension.

**Decoupling via Interface** reduces coupling through a mediated contract. It lacks platform purpose, core ownership, extension lifecycle, ecosystem governance, and exit.

**Virtual Resource Abstraction** exposes a logical resource interface over a substrate. It may be a core capability but not the platform lifecycle.

**Metasystem Integration** creates a higher-order system from interacting systems. A platform may support extensions without integrating existing systems into a new metasystem.

**Rapid Prototype Learning Loop** tests a risky assumption with a low-cost artifact. It should test platform choices, not absorb a durable platform architecture as an alias.

prose_cross_domain_examples:
**Internal developer platform.** The core owns identity, deployment contracts, telemetry, policy, and supported runtime abstractions. Teams extend through APIs, templates, events, and services within permissions and compatibility rules. A portal, conformance suite, release train, and migration tools make the supported path easier than local reinvention.

**Product family.** A vehicle family shares chassis, electronics, safety, interface, and certification invariants. Models extend body, capability, market configuration, and accessories. The platform measures common-core bloat, variant explosion, supplier compatibility, and migration.

**Research infrastructure.** A platform provides data provenance, identity, compute, instrument, workflow, and registry capabilities. Independent methods register with declared dependencies, evidence, permissions, versions, and retirement paths.

**Payment ecosystem.** The core exposes identity, ledger, settlement, risk, disputes, and events. Merchant, bank, fraud, accounting, and finance extensions enter through tiered review. Access, ranking, data, fees, portability, and rule change receive ecosystem governance.

**Public digital foundation.** Identity, consent, eligibility primitives, notification, audit, and common records form the core. Agencies add domain services while preserving legal authority and local policy. Open standards, certification, portability, and public-interest oversight constrain operator power.

**Learning platform.** Learner identity, enrollment, content, assessment, accessibility, and records form a trusted core. Institutions and vendors add curricula, analytics, and support extensions with privacy, evidence, versioning, and exit controls.

prose_non_examples:
A monolithic application is not a platform merely because many users access it. Without supported independent extension, the pattern does not apply.

A generic API is not the archetype. It can expose a contract and still lack core discipline, lifecycle, compatibility, governance, migration, and exit.

A shared service center created only for cost reduction belongs to Scale Economy Consolidation.

An app marketplace with opaque ranking and removal rules is a distribution mechanism with governance risk, not a mature platform design.

A design-system library may instantiate platform logic but often belongs to Unity-Variety Balancing or Interoperability Standardization when coherence and compatibility are decisive.

A document or product template with fixed slots belongs to Slot Template Design.

A standards consortium that defines exchange without providing a shared core belongs to Interoperability Standardization.

A rough prototype testing user understanding belongs to Rapid Prototype Learning Loop.

prose_tradeoffs:
Reuse and autonomy pull in opposite directions. The core makes common capability easier and constrains how extensions interact with it. Every core admission should justify why central ownership creates more leverage than coupling.

Stability and evolution also conflict. Dependents need predictability; the platform needs to improve. Versioning and migration transform the conflict into governed cost rather than eliminate it.

Open ecosystems produce novelty and increase attack, quality, support, and governance surface. Curated ecosystems protect trust and can suppress competition or unconventional value. Risk-tiered entry is usually better than one blanket rule.

Registries, portals, and councils improve discovery and governance while concentrating power. Transparency, representation, recusal, appeal, federation, and portability counterbalance that concentration.

Strong isolation protects the core and can prevent deep integration. Use capability grants and explicit risk acceptance rather than casually expanding privilege.

Network effects can make a platform more useful and harder to leave. Platform design should make interoperability and exit credible before growth makes them politically difficult.

prose_invariants_to_preserve:
Preserve a bounded platform purpose and core responsibility. If every shared request becomes core, the architecture ceases to be extensible.

Preserve supported extension surfaces and close accidental internals. Dependents deserve explicit contracts, and the core deserves freedom to change what it never promised.

Preserve traceable identity, ownership, provenance, dependencies, permissions, compatibility, and lifecycle state for every governed extension.

Preserve proportional isolation and review. Low-risk contribution should not face high-risk bureaucracy, and high-consequence extensions should not enter through low-friction paths.

Preserve governed evolution. Material change carries version, notice, impact, migration, fallback, and closure evidence.

Preserve participant autonomy and fair access within the platform contract. The core should enable extension rather than absorb it.

Preserve safety, security, privacy, accessibility, fairness, and public-interest constraints as growth and network pressure increase.

Preserve portability and exit. Essential value should not disappear merely because a platform operator changes terms, fails, or retires a surface.

prose_target_outcomes:
Builders should reach supported capabilities quickly and create independent extensions without modifying the core. Correct extension should become easier than internal coupling or local duplication.

Core evolution should become deliberate and infrequent relative to extension evolution. Breaking change should be visible, justified, supported, and closed rather than discovered through failure.

Compatibility, security, quality, and safety incidents should decline while evidence and containment improve. The platform should know which dependents and participants are affected when a core or extension state changes.

Participant value should grow without proportional gatekeeper discretion, migration burden, or lock-in. Smaller builders should have predictable entry, review, discovery, appeal, and exit.

Platform health should become broader than adoption. Reliability, concentration, accessibility, portability, builder experience, support load, extension quality, and affected-party outcomes should guide change.

prose_parameter_dimensions:
**Core thickness.** A thicker core increases reuse, consistency, and centralized safeguards but expands coupling and change cost. A thinner core preserves extension autonomy but may duplicate foundational work. Admit core capabilities through evidence, not popularity.

**Extension openness.** Open contribution accelerates diversity; curated access improves trust and support. Use risk tiers so low-risk participation remains accessible while privileged or high-consequence extensions receive deeper review.

**Contract stability.** Long support windows protect dependents and accumulate complexity. Short windows enable evolution and shift burden. Tune by dependency scale, switching cost, consequence, and migration capacity.

**Isolation strength.** Strong process, data, resource, or authority isolation contains failure and may limit performance or integration depth. Increase isolation with untrusted code, sensitive data, irreversible effects, or wide propagation.

**Governance centralization.** Operator control can make fast coherent decisions and invite capture. Federated or representative governance adds knowledge and legitimacy but costs time. Separate routine stewardship from ecosystem-shaping change.

**Compatibility strategy.** Backward compatibility, adapters, negotiated versions, dual operation, and coordinated breaks have different complexity and migration costs. Choose deliberately and retire temporary bridges.

**Discovery and ranking.** Curated portals reduce search but shape opportunity. Make ranking goals, evidence, conflicts, and appeal visible, especially when the operator offers competing extensions.

**Economic model.** Fees, subsidies, cost allocation, revenue share, and support funding affect contribution and dependence. Track who creates, captures, and bears platform value and cost.

**Release cadence.** Core, contracts, extensions, and governance need not share one cadence. Coordinate where compatibility demands it and preserve independent release elsewhere.

**Exit strength.** Export, portability, substitution, federation, fallback, and migration range from symbolic to operational. Test exit in proportion to criticality and lock-in risk.

prose_variants_and_near_names:
**Technical plugin platform** emphasizes executable hooks, APIs, manifests, permissions, isolation, registries, and runtime containment. It remains a variant because the same core-extension lifecycle transfers beyond software.

**Product-family platform** emphasizes shared physical or service architecture and governed configurations. It should not collapse into a template when extensions have independent lifecycle and ecosystem consequences.

**Organizational shared-capability platform** provides reusable enabling services to autonomous teams. It remains a platform only when teams can extend or compose capabilities through supported contracts; pure central consolidation belongs elsewhere.

**Multi-sided ecosystem platform** adds complementor access, discovery, fees, ranking, network power, portability, and participant governance. Network-effect archetypes remain separate neighbors.

Frozen names `platform architecture`, `shared foundation`, `modular platform`, and `ecosystem foundation` route to the parent when stable core plus governed extension is intended. An API, SDK, registry, portal, app store, design system, or shared service alone routes to a mechanism or neighbor.

The reconciliation name `platform_core_extension_design` is retained because it states the boundary precisely and prevents a generic “platform” label from absorbing unrelated marketplaces, standards, prototypes, or centralized services.

Technical Plugin Platform

short_definition: Exposes governed APIs, lifecycle hooks, permissions, registries, and sandboxes for independently built software extensions.

distinctive_feature: Executable extension lifecycle and isolation dominate.

distinct_from_parent: Technical specialization of the general core-extension lifecycle.

still_same_parent_because: Uses the same core boundary, contract, registry, compatibility, governance, migration, and exit structure.

source_primes: platform_design interface modularity

use_when: Compatibility and security are enforceable

example: An IDE platform loads permissioned plugins through versioned extension points.

failure_modes:
Privilege escalation
API ossification
dependency conflict

Product-Family Platform

short_definition: Uses common product architecture, shared components, interfaces, and governed variation to produce a family of offerings.

distinctive_feature: Physical or service product variety and configuration dominate.

distinct_from_parent: Emphasizes product-line assets and bounded variant configuration.

still_same_parent_because: Retains stable core, extension zones, compatibility, lifecycle, governance, and migration.

source_primes: platform_design modularity composition

use_when: Reuse can exceed coordination and rigidity cost

example: A vehicle family shares chassis, electronics, interfaces, and certification while body and use variants extend them.

failure_modes:
Common-core bloat
forced fit
variant explosion

short_definition: Provides reusable institutional capabilities, service contracts, tooling, and extension paths to autonomous teams or units.

distinctive_feature: Service ownership, funding, adoption, and local-team experience dominate.

distinct_from_parent: Translates core-extension design into organizational operating architecture.

still_same_parent_because: Uses the same purpose, core, contracts, catalog, compatibility, governance, signals, and exit controls.

use_when: Shared services can expose stable contracts

example: A shared people-operations platform supplies identity, payroll, policy, data, and governed local extensions.

failure_modes:
Mandated adoption
shared-service bottleneck
local capability loss

Multi-Sided Ecosystem Platform

short_definition: Provides shared capabilities and governed interaction surfaces through which multiple participant sides create and exchange complementary value.

distinctive_feature: Cross-side access, ranking, fees, power, portability, and network effects dominate.

distinct_from_parent: Adds market or community ecosystem governance to the core-extension architecture.

still_same_parent_because: The technical and institutional platform still uses the same core, surface, registration, compatibility, lifecycle, signals, and exit logic.

use_when: Complementors and users depend on one another

example: A commerce platform connects buyers, sellers, logistics, payments, and third-party tools through governed services and rules.

failure_modes:
Lock-in
self-preferencing
abuse
ecosystem fragility

near_names:
Platform Architecture
Shared Foundation
Modular Platform
Ecosystem Foundation
Platform Core / Extension Architecture
Extensible Core Design
Stable Core with Governed Extensions
Shared Core / Extension System
Platform Operating Architecture
Plugin Platform Architecture
Product Platform Architecture
Internal Platform Model
Platform Ecosystem Architecture
Core and Extension Governance


Policy Evaluation Before Deployment

type: archetype

source: generated

batch: First Iteration/Batch 31/Wave 2

slug: probability

slug: uncertainty

slug: robustness

slug: optimization

slug: accountability

slug: feedback

slug: observability

slug: threshold

components:
Policy Rule
Deployment Context Boundary
Scenario or Trace Set
Trajectory Evaluation Model
Outcome Metric
Comparison Baseline
Deployment Gate
Edge-State Catalog
Subgroup or Context Slice
Evaluation Evidence Log
Rollback or Monitoring Handoff

mechanisms:
Policy Simulation
Historical Replay
Off-Policy Evaluation
Scenario Testing
Digital Twin Trial
Shadow-Mode Evaluation
Simulation-Based Validation Report

essence_one_line: Evaluate a decision policy across simulated or historical states before deploying it in the real system.

compression_statement: When a policy will make repeated state-dependent decisions, test its behavior across plausible trajectories, historical traces, edge states, and outcome metrics before authorizing live deployment.

core_intuition: A policy can look sensible when judged one decision at a time yet produce bad behavior once repeated over time. Pre-deployment evaluation makes the sequence visible and creates a gate before real-world consequences begin.

canonical_formula: candidate policy + deployment context + scenario/trace set + outcome metrics + comparison baseline + gate criteria -> deploy, limit, revise, pilot, or withhold

structural_problem: A rule or policy is ready to be deployed because it appears locally reasonable, but no one has checked how it behaves across sequences of states, plausible future scenarios, historical traces, edge cases, or affected contexts.

trigger_conditions: A policy will operate repeatedly, automatically, or semi-automatically across many cases.

trigger_conditions: Actions taken under the policy alter future states, options, costs, risk, or service quality.

trigger_conditions: The policy may affect safety, access, fairness, capacity, compliance, or irreversible outcomes.

trigger_conditions: Historical traces, simulated scenarios, shadow-mode outputs, or expert-constructed cases can approximate likely deployment conditions.

trigger_conditions: There is enough time and authority to revise, constrain, pilot, or withhold the policy before full release.

symptoms: Stakeholders can describe the policy rule but cannot say how it behaves over multiple steps.

symptoms: The policy was optimized or designed on narrow examples and has not been checked against realistic trajectories.

symptoms: Aggregate performance looks acceptable while edge states, subgroups, or stress scenarios remain untested.

symptoms: Deployment discussions focus on whether the rule is elegant, efficient, or locally rational rather than whether it is safe and effective in use.

symptoms: There is no explicit go/revise/limit/withhold decision point tied to evaluation evidence.

root_tension: Decision-makers want the speed and consistency of a repeatable policy, but repeated action over changing states can create harms that are invisible in isolated examples or design-stage reasoning.

anti_signatures: The decision is a one-off choice rather than a repeated policy or rule.

anti_signatures: The policy is already live and the primary need is monitoring, rollback, or adaptive recalibration rather than pre-deployment evaluation.

anti_signatures: No meaningful scenario, trace, model, historical replay, or expert review can approximate deployment behavior.

anti_signatures: The main unresolved task is choosing objectives or weights rather than evaluating an already specified policy.

anti_signatures: The setting is low-stakes and reversible enough that lightweight trial-and-monitoring is more appropriate than a formal gate.

structural_intervention: Turn a proposed repeated decision rule into an evaluated deployment candidate: state the policy, define the deployment boundary, exercise it across scenarios or traces, compare outcomes against baselines and thresholds, document known limits, and use a gate to decide whether to deploy, revise, restrict, pilot, monitor, or withhold it.

action_logic: Specify the candidate policy in executable or consistently interpretable form.

action_logic: Define the deployment context, affected cases, state variables, operating horizon, and assumptions.

action_logic: Construct a scenario or trace set that covers ordinary cases, stress cases, edge states, and relevant contexts.

action_logic: Choose outcome metrics and guardrail metrics before inspecting favorable results.

action_logic: Run the policy through simulation, replay, shadow mode, or structured review and compare it against baselines.

action_logic: Route results through a documented deployment gate with explicit disposition options.

action_logic: Record residual uncertainty and create a handoff to monitoring, rollback, or staged rollout when deployment is allowed.

rule: deploy

condition: Evidence meets benefit, safety, fairness, reliability, and operational thresholds within the defined deployment boundary.

rule: revise

condition: Evaluation reveals fixable failures in edge states, metrics, assumptions, or policy wording.

condition: Evidence is promising but valid only for a narrower context, lower-stakes use, supervised release, or staged rollout.

rule: withhold

condition: Evaluation reveals unacceptable harm, instability, brittle behavior, or evidence gaps that cannot be resolved before deployment.

condition: Deployment is allowed only if post-release monitoring, triggers, and rollback authority are in place.

target_invariants: The policy being evaluated remains clearly specified and does not change silently during evaluation.

target_invariants: Evaluation scenarios or traces are tied to the stated deployment context.

target_invariants: Outcome metrics include guardrails, not only the primary optimization target.

target_invariants: The deployment gate is explicit, documented, and authorized.

target_invariants: Known limits of evidence are carried forward into deployment conditions and monitoring.

expected_outcomes: Earlier discovery of brittle, unsafe, unfair, or operationally unstable policy behavior.

expected_outcomes: Clearer deployment decisions: deploy, revise, limit, pilot, monitor, or withhold.

expected_outcomes: Better evidence for policy release decisions and later audits.

expected_outcomes: Reduced live-system harm from policies that were locally appealing but trajectory-fragile.

expected_outcomes: Improved handoff between design, evaluation, governance, and operational monitoring.

prose_essence:
Policy Evaluation Before Deployment is the pattern of testing a repeated decision rule before it is allowed to control real outcomes. The central question is not only "does this policy sound reasonable?" but "what will this policy do when it acts across many states, cases, contexts, and future trajectories?"

The archetype turns a policy from a plausible rule into an evaluated deployment candidate. A candidate policy is specified, exercised against scenarios or historical traces, judged by outcome and guardrail metrics, compared with a baseline, and routed through a deployment gate.

prose_when_to_use:
Use this archetype when a policy, rule, or protocol will act repeatedly across cases or states and bad behavior may only become visible over sequences of decisions. It is especially useful when the policy affects safety, access, capacity, fairness, workload, cost, compliance, or irreversible outcomes.

It is less useful for one-off decisions, vague discretionary guidance, or low-stakes reversible changes where lightweight trial-and-monitoring is sufficient.

prose_structural_problem:
The structural problem is premature deployment of a rule whose trajectory behavior has not been inspected. A policy can pass local plausibility checks: it seems logical, aligns with an objective, and handles common examples. Yet repeated use may create delayed costs, edge-case failures, subgroup harms, feedback loops, or operational overload.

This is different from simply needing a better policy. The policy may already be designed. The unresolved risk is that deployment will expose behavior the design process did not see.

prose_intervention_logic:
The intervention creates a pre-deployment evidence gate. First, the candidate policy is made explicit. Next, the deployment context is bounded: where it applies, who it affects, which states matter, and what horizon is relevant. Then reviewers assemble scenarios, historical traces, replay cases, simulated trajectories, or shadow-mode evidence. They define outcome and guardrail metrics before interpreting results, compare against a baseline, and decide whether to deploy, revise, restrict, pilot, monitor, or withhold the policy.

The gate matters. Without a gate, simulation or replay becomes a report. With a gate, evaluation changes the release decision.

prose_key_components:
### Policy Rule

The policy rule is the candidate state-to-action rule, eligibility rule, triage rule, prioritization rule, or operating protocol being evaluated. It must be clear enough to apply consistently across simulated or replayed cases.

### Deployment Context Boundary

The deployment context boundary specifies where the evidence is valid: populations, states, sites, systems, time horizon, assumptions, and operating conditions. It prevents a policy tested in one environment from being treated as safe everywhere.

### Scenario or Trace Set

The scenario or trace set supplies the cases through which the policy is exercised. It should include ordinary cases, stress cases, edge states, and relevant context slices rather than only examples that are easy to handle.

### Trajectory Evaluation Model

The trajectory evaluation model connects the policy to sequences of states. It may be a formal simulator, historical replay, expert scenario walkthrough, or shadow-mode evaluation. Its role is to reveal repeated behavior over time.

### Outcome Metric

Outcome metrics define what counts as acceptable performance. They should include intended benefits and guardrails such as safety, delay, error, workload, equity, reversibility, or compliance.

### Comparison Baseline

The comparison baseline anchors interpretation. The candidate policy may be compared with current practice, a simpler rule, a prior version, a no-action alternative, or expert judgment.

### Deployment Gate

The deployment gate converts evaluation into a decision. It defines whether the policy can be deployed, revised, limited, piloted, monitored, or withheld. This is the component that keeps the archetype from collapsing into a generic simulation mechanism.

Optional supporting components include an edge-state catalog, subgroup or context slices, an evaluation evidence log, and a rollback or monitoring handoff.

prose_common_mechanisms:
### Policy Simulation

Policy simulation runs the candidate rule through modeled states or trajectories. It implements the archetype when the simulation results feed a release decision rather than merely illustrating a model.

### Historical Replay

Historical replay applies the policy to past cases or traces. It can show what the candidate policy would have done under known conditions, but it must be interpreted carefully because past traces may not represent future deployment.

### Off-Policy Evaluation

Off-policy evaluation estimates how a policy would perform from logged behavior or counterfactual evidence. It is a mechanism under this archetype, not the archetype itself.

### Scenario Testing

Scenario testing constructs plausible, extreme, and boundary cases. It is especially useful where historical data is sparse or future conditions may differ from past conditions.

### Digital Twin Trial

A digital twin trial uses a modeled replica of an operating environment. It can reveal system interactions before deployment, but the validity of the twin must be stated as part of the evidence boundary.

### Shadow-Mode Evaluation

Shadow-mode evaluation runs the candidate policy silently alongside live operations without letting it control outcomes. It can provide realistic input evidence while preserving a pre-release gate.

### Simulation-Based Validation Report

A validation report packages assumptions, scenarios, metrics, results, limitations, and a deployment recommendation. The report is an artifact; the archetype is the evaluation-and-gate structure around it.

prose_failure_modes:
Common failure modes include simulation mismatch, biased historical traces, metric overfitting, untested edge states, bypassed gates, policy drift during evaluation, false confidence from formal-looking reports, and lack of monitoring handoff after approval.

A particularly dangerous failure is aggregate success hiding localized harm. Another is treating pre-deployment evaluation as proof, rather than bounded evidence under stated assumptions.

prose_neighbor_distinctions:
Sequential Policy Optimization designs or optimizes a policy across states. Policy Evaluation Before Deployment evaluates a candidate policy before release.

Robust Solution Selection chooses among solutions based on cross-scenario acceptability. This archetype may compare policies, but the distinctive act is a pre-deployment gate for a repeated rule.

Sensitivity Analysis Protocol varies assumptions to diagnose fragile conclusions. This archetype exercises a policy across scenarios or traces and makes a deployment decision.

Monte Carlo uncertainty exploration, historical replay, off-policy evaluation, and digital twins are mechanisms that can support this archetype. They are not the archetype unless they are tied to a policy, metrics, context boundary, and release gate.

prose_cross_domain_examples:
In automated service triage, a routing rule can be replayed against historical demand and surge scenarios before it routes cases automatically.

In maintenance operations, a preventive maintenance policy can be tested over simulated asset histories to compare downtime, cost, deferred risk, and failure response.

In incident response, an escalation policy can be exercised against tabletop trajectories and historical incidents before becoming the default response rule.

In public program administration, an eligibility prioritization policy can be replayed against historical applications and subgroup slices before broad deployment.

In platform governance, a moderation escalation policy can run in shadow mode to compare false positives, missed harms, reviewer load, and appeal outcomes before it affects users.

prose_non_examples:
A policy memo arguing that a rule is sensible is not this archetype unless it evaluates trajectory behavior and gates deployment.

A dashboard of live results after launch is monitoring, not pre-deployment evaluation.

A simulation run with no release decision is a mechanism, not the full archetype.

An algorithm that learns a policy is not this archetype; learning or optimizing the policy is different from evaluating a candidate policy before deployment.

prose_tradeoffs: The archetype trades speed for assurance. It also trades simple aggregate evaluation for broader scenario coverage, which can be costly. Highly controlled simulations are easier to interpret but less realistic; shadow-mode evidence is more realistic but harder to isolate. Strict gates improve safety and accountability but may slow useful deployment.

prose_invariants_to_preserve:
Preserve the identity of the policy being evaluated. If the rule changes during evaluation, results become hard to interpret. Preserve the boundary between design and evaluation: the process may recommend revision, but it should not silently redesign the policy while claiming to validate it.

Also preserve the connection between evidence and deployment context, the inclusion of guardrail metrics, the authority of the deployment gate, and a record of residual uncertainty.

prose_target_outcomes: The desired outcomes are earlier discovery of brittle behavior, clearer release decisions, reduced live-system harm, better audit evidence, and stronger handoff from design to monitoring. The archetype should produce a decision disposition: deploy, revise, limit, pilot, monitor, or withhold.

prose_parameter_dimensions:
Key tuning dimensions include scenario coverage, replay depth, evaluation horizon, edge-state inclusion, subgroup or context slicing, metric thresholds, baseline choice, confidence requirements, gate authority, and post-deployment monitoring handoff.

A stricter version of the archetype uses broader scenario coverage, stronger guardrails, explicit affected-context review, and formal signoff. A lighter version may use a small trace set and a simple deploy/revise/withhold gate for lower-stakes policies.

prose_variants_and_near_names:
Recognized variants include historical replay evaluation, scenario-based policy gating, shadow-mode policy validation, high-stakes policy release gates, and offline policy evaluation gates. Near names include predeployment policy testing, policy simulation gate, offline policy validation, trajectory-based policy evaluation, and deployment readiness evaluation.

The draft intentionally collapses off-policy evaluation, historical replay, digital twins, and validation reports into mechanisms. It flags sandboxed exploration governance and high-stakes algorithmic release gates as possible future review items rather than silently promoting them.

Shadow-Mode Policy Validation

source_primes: observability feedback

near_names:
Predeployment Policy Testing
Policy Simulation Gate
Offline Policy Validation
Trajectory-Based Policy Evaluation
Deployment Readiness Evaluation


Polyphonic Coherence Design

batch: Batch 12

canonical_family: Shared Awareness & Identity Alignment

aliases:
Polyphony Design
Polyphonic Coordination Design
Independent-Line Coherence Design
Many-Voiced Coherence Design
Contrapuntal Coordination Design
Multi-Voice Substrate Design
Counterpoint Governance Design

source_primes: polyphony emergence formal_system improvisation multiplexing polysemy pragmatics coordination unity_variety diversity modularity synchronization turn_taking network representation common_ground context coupling boundary interface layering ensemble self_organization composition compositionality

slug: polyphony

slug: emergence

slug: improvisation

slug: multiplexing

slug: polysemy

slug: pragmatics

slug: coordination

slug: diversity

slug: modularity

slug: synchronization

slug: network

slug: representation

slug: context

slug: coupling

slug: interface

slug: layering

slug: ensemble

slug: compositionality

slug: perspective

slug: role

slug: interoperability

slug: decomposition

slug: aggregation

slug: convergence

slug: framing

essence_one_line: Design a shared substrate where independent lines remain legible while their interaction produces a coherent whole.

compression_statement: Polyphonic Coherence Design applies when a system should not collapse many lines into one voice, one ranking, one consensus, or one layer. It defines independent lines, shared substrate, line identity boundaries, interaction grammar, timing rules, balance/mix rules, dissonance tolerance, coherence criteria, translation anchors, interaction traces, dominance guardrails, and rehearsal loops. The pattern turns “many voices” from unmanaged cacophony into structured coexistence: each line keeps identity, each can respond to others, and the whole becomes meaningful through their relation.

core_intuition: Some problems are ruined by premature unification. The answer is not to silence divergence or average it away, but to design the medium and rules so lines can be followed separately and heard together. Polyphony works because coherence can arise from relation among differentiated parts, not only from consensus or hierarchy.

canonical_formula: For line set L on substrate S, maintain identity boundary I_l for each line l, define interaction grammar G and timing T, then evaluate whole coherence H as a function of line legibility, interaction quality, balance, and emergent fit rather than single-line dominance.

structural_problem: Several voices, streams, modules, disciplines, perspectives, narratives, constraints, or roles need to operate together, but available structures either collapse them into one aggregate, separate them into silos, or let them interfere as noise. The challenge is to preserve independent identity while making interaction coherent.

trigger_conditions: Multiple perspectives or workstreams are all valid and must remain inspectable.

trigger_conditions: A single synthesis would erase minority, expert, local, temporal, or counterpoint information.

trigger_conditions: Parallel channels need shared timing, references, or substrate without becoming one undifferentiated channel.

trigger_conditions: A group needs more than inclusion: it needs interaction among lines that changes the whole.

trigger_conditions: Modules, agents, teams, voices, or narratives should combine while retaining source traceability.

trigger_conditions: Dissonance is informative but unmanaged conflict creates overload.

trigger_conditions: A system alternates between cacophony and forced consensus because it lacks a grammar for coexistence.

trigger_conditions: Audience, users, or operators need to follow several lines at once without losing orientation.

symptoms: Important voices are included but then flattened in the final summary.

symptoms: Parallel threads drift apart because there is no shared substrate or timing rule.

symptoms: One dominant line sets the frame, causing others to become token annotations.

symptoms: Participants cannot tell which claim, constraint, or decision came from which line.

symptoms: The whole feels noisy, fragmented, or incoherent despite valuable individual contributions.

symptoms: Conflict is either suppressed too early or allowed to consume the whole.

symptoms: A platform, document, score, or workflow has channels but no interaction grammar.

root_tension: Coherence often tempts designers toward unification, but the value comes from differentiated coexistence; line identity must be preserved while interaction is made intelligible.

anti_signatures: There is only one legitimate line or source of truth.

anti_signatures: The purpose is aggregate prediction accuracy rather than legible coexistence.

anti_signatures: Independent line identity is irrelevant after integration.

anti_signatures: The problem is simple turn-taking or access equity rather than simultaneous line interaction.

anti_signatures: The system cannot afford dissonance, ambiguity, or parallel interpretation.

structural_intervention: Create a shared substrate and interaction grammar that preserves line identity, controls timing and balance, makes dissonance reviewable, and evaluates coherence at the level of the whole without erasing the parts.

action_logic: inventory the independent lines and their non-negotiable identities

action_logic: define the common substrate, notation, timeline, workspace, or protocol

action_logic: specify allowed interactions among lines

action_logic: assign entry, exit, foreground, background, and handoff rules

action_logic: calibrate balance so each line can be followed and no line dominates by default

action_logic: mark productive dissonance and destructive interference separately

action_logic: provide translation anchors so observers can navigate the whole

action_logic: record interactions and revise through rehearsal or iteration

decision_rules: Use polyphony when independent line identity is valuable after integration.

decision_rules: Do not collapse lines into an average if source, role, perspective, or timing matters.

decision_rules: Foreground one line only with rules for return, response, and traceability.

decision_rules: Treat dissonance as a managed signal before treating it as a defect.

decision_rules: Prefer ensemble aggregation when the goal is a single robust estimate.

decision_rules: Prefer participation equity when the main problem is access and voice distribution.

decision_rules: Prefer layered abstraction when lines are stacked levels rather than simultaneous voices.

target_invariants: a shared substrate coordinates coexistence

expected_outcomes: more coherent multi-voice work without forced consensus

expected_outcomes: better preservation of minority, expert, local, or counterpoint lines

expected_outcomes: clearer interaction among parallel streams

expected_outcomes: reduced cacophony through timing and balance

expected_outcomes: more auditable synthesis and decision records

expected_outcomes: higher-quality emergent whole than any line could produce alone

Stakeholder Polyphony

short_definition: Keeps stakeholder lines independently legible while their interaction shapes a coherent decision or plan.

distinctive_feature: The independent lines are stakeholder positions, lived experiences, or constituencies.

distinct_from_parent: The parent covers any independent lines; this variant centers stakeholder legitimacy and power asymmetry.

use_when: Use in participatory governance, planning, consultation, and policy design.

Narrative Polyphony

short_definition: Maintains multiple narrative or interpretive voices in a coherent communication artifact.

distinctive_feature: The lines are narrative, interpretive, or rhetorical voices.

distinct_from_parent: The parent covers operational and modular lines too; this variant is discourse-centered.

source_primes: polyphony polysemy pragmatics framing

use_when: Use in editorial, storytelling, research synthesis, and public communication.

Modular System Polyphony

short_definition: Lets autonomous modules or services interact through a shared protocol while retaining responsibility boundaries.

distinctive_feature: The lines are technical modules or services.

distinct_from_parent: The parent is cross-domain; this variant emphasizes modular interface governance.

source_primes: polyphony modularity interface interoperability

use_when: Use in software, platforms, system-of-systems design, and interoperable workflows.

Ensemble Polyphony

short_definition: Coordinates performers, experts, models, or teams so differentiated contributions form a coherent ensemble.

distinctive_feature: The lines are explicitly ensemble members with timing and balance rules.

distinct_from_parent: The parent includes broader multi-line substrates; this variant emphasizes live or iterative ensemble coordination.

source_primes: polyphony ensemble synchronization coordination

use_when: Use when performance, research, or operations require coordinated differentiation rather than single-source control.

near_names:
Polyphony Design
Polyphonic Coordination Design
Many-Voiced Coherence Design
Contrapuntal Coordination Design


Polysemy Disambiguation

batch: First Iteration/Batch 48

Sense Disambiguation

notes: Plain-language near name; canonical slug preserves the ontology prime polysemy.

Active Sense Clarification

notes: Best treated as the local active-sense selection variant under this archetype.

Term Disambiguation

notes: Useful in terminology governance contexts, but somewhat broader than polysemy when ambiguity has other causes.

Contextual Sense Selection

notes: Highlights the role of context cues without using noncanonical context as a source prime.

Polysemy

slug: polysemy

role: Supplies the structural problem: one sign form can carry multiple related senses, so users may share the same word while activating different meanings.

Deixis

slug: deixis

role: Explains why active sense often depends on surrounding speaker, audience, time, place, role, task, or document context rather than on the word alone.

Signifier–Signified Duality

role: Keeps the draft focused on the gap between a shared sign form and the meaning people infer from it.

Semantic Shift

role: Distinguishes simultaneous multiple senses from meanings that change historically; drift can create new senses, but the intervention here is active-sense selection.

Semantic Narrowing / Widening

role: Helps diagnose whether one sense is specialized, generalized, or scoped differently from another.

Schema

slug: schema

role: Connects disambiguation to the interpretive structure people use when they classify a term under one conceptual frame rather than another.

Ontology

slug: ontology

role: Marks the boundary between choosing a sense of a term and redesigning the underlying concept system when meanings are genuinely incompatible.

Frame of Reference

role: Explains why the same term may be interpreted differently when the audience, task, discipline, or decision frame changes.

Arbitrariness of Symbols

role: Shows why a sign form does not naturally enforce one sense; communities must preserve or signal intended interpretation.

Feedback

slug: feedback

role: Supports the misunderstanding-monitor loop: user questions, disputes, support tickets, or implementation errors reveal whether disambiguation worked.

Iteration

slug: iteration

role: Supports repeated refinement of qualifiers, examples, labels, and definitions as users encounter new contexts.

Interoperability

role: Motivates disambiguation where teams, documents, systems, or jurisdictions must interpret the same term compatibly.

components:
Ambiguous Term or Sign Form
Meaning Cluster
Sense Inventory
Context Cue
Active Sense
Qualifier or Example
Scope Boundary
Misunderstanding Monitor
Sense Owner
Translation Crosswalk

mechanisms:
Controlled Vocabulary
Sense Labeling
Definition Note
Examples and Non-Examples
Context-Specific Glossary
Legal Definition Clause
Inline Clarifier
Terminology Review Workshop

essence_one_line: Clarify which meaning of a multi-meaning term is active in a specific context.

compression_statement: When a term, label, symbol, or sign form carries multiple related meanings, inventory the possible senses, identify context cues, select the active sense, add qualifiers or examples, define scope, and monitor whether people still misunderstand.

core_intuition: People can appear to agree because they are using the same word while actually acting from different meanings. Polysemy disambiguation turns the hidden choice of sense into an explicit design decision, so the shared sign form no longer masks divergent interpretation.

canonical_formula: ambiguous_term + meaning_cluster + context_cue + active_sense + qualifier_or_example + misunderstanding_monitor -> shared_interpretation_of_current_use

structural_problem: A shared sign form has several related meanings, and participants, readers, users, systems, or stakeholders activate different senses while assuming they are talking about the same thing.

trigger_conditions: A term appears in a policy, interface, contract, standard, lesson, taxonomy, or conversation where several plausible related meanings could apply.

trigger_conditions: Participants repeatedly ask “What do you mean by this?” or proceed confidently but later reveal incompatible interpretations.

trigger_conditions: A familiar everyday word is reused as a technical, legal, organizational, or product-specific term.

trigger_conditions: Different teams, audiences, systems, jurisdictions, disciplines, or communities use the same label with overlapping but non-identical senses.

trigger_conditions: A definition exists, but it does not specify which sense governs a particular local use.

symptoms: False agreement: everyone accepts the wording but later makes different decisions from it.

symptoms: Repeated clarification requests around one word, label, metric, category, or field name.

symptoms: Support tickets, implementation errors, search failures, or classification disputes caused by term interpretation.

symptoms: Definitions that contain examples from multiple senses without explaining their scope.

symptoms: Translation, localization, or cross-functional handoff failures where the same term seems familiar but behaves differently.

root_tension: The system wants economy by reusing a familiar sign form, but interpretation requires specificity about which related sense governs the current use.

anti_signatures: The problem is a sign form that simply fails to evoke the intended meaning at all; use Sign–Meaning Alignment first.

anti_signatures: The meaning is changing over time rather than multiple senses being simultaneously active; use Semantic Drift Monitoring first.

anti_signatures: The problem is speaker, time, place, role, or version reference such as “here,” “now,” “they,” or “current”; Context Anchor Design may be the better candidate after merge review.

anti_signatures: The term has unrelated homonyms with no shared interpretive cluster; ordinary naming replacement or local clarification may be sufficient.

anti_signatures: The disagreement is about underlying ontology or category structure, not which sense of a term is active; use Ontology Clarification or Schema Conflict Resolution.

structural_intervention: Make sense selection explicit: identify the ambiguous sign form, map its plausible related meanings, choose the active sense for the current use, add cues that make that choice visible, bound its scope, and use feedback to detect residual misunderstanding.

action_logic: Locate the ambiguous term or sign form in the concrete document, interface, decision, conversation, code, or symbolic system where misunderstanding matters.

action_logic: List the plausible related meanings users may activate, including official, informal, legacy, technical, legal, product, and audience-specific senses.

action_logic: Determine which sense should govern the current use, and whether other senses should be excluded, deprecated, redirected, or preserved elsewhere.

action_logic: Choose context cues, qualifiers, examples, non-examples, labels, or definitions that make the active sense visible at the point where people interpret or act.

action_logic: Define the scope boundary so the selected sense is not accidentally exported to contexts where another sense should apply.

action_logic: Monitor evidence of residual misunderstanding and revise cues, examples, labels, or definitions when users still activate the wrong sense.

decision_rules: If one sense must govern action, name or qualify the active sense near the point of use rather than relying on distant documentation.

decision_rules: If several senses legitimately coexist, preserve them in a sense inventory and attach scope rules instead of forcing one universal definition.

decision_rules: If the ambiguity affects rights, safety, eligibility, system behavior, or costly coordination, use formal definitions, owner review, and misunderstanding monitoring.

decision_rules: If disambiguation requires changing the term itself, treat renaming as a mechanism and still document the sense problem it solves.

decision_rules: If users from different communities activate different senses, validate the chosen sense with representatives of each affected community before publishing.

target_invariants: The same visible sign form should not silently license incompatible actions in the same operational context.

target_invariants: The active sense should be recoverable by the intended audience without expert guesswork.

target_invariants: Related senses should remain distinguishable without erasing useful legitimate variation.

target_invariants: Scope boundaries should travel with the definition or label when copied, reused, translated, or implemented.

target_invariants: Monitoring should remain focused on interpretation outcomes, not merely on whether a glossary entry exists.

expected_outcomes: Reduced false agreement around shared terms.

expected_outcomes: Fewer disputes, support requests, classification errors, and implementation defects caused by ambiguous sense activation.

expected_outcomes: Greater interoperability across teams, documents, systems, and communities that rely on the same term.

expected_outcomes: More teachable definitions because examples and non-examples reveal intended boundaries.

expected_outcomes: Clearer distinction between term disambiguation, semantic drift, and deeper ontology conflict.

prose_essence:
Polysemy Disambiguation is the intervention pattern for situations where the same visible term or sign form can reasonably mean several related things. The core move is not to invent a better word immediately. It is to make the active sense explicit enough that readers, users, systems, or stakeholders can coordinate around the same meaning in the current context.

This archetype is especially useful when the surface conversation sounds aligned because everyone uses the same word, while the actual decisions reveal different meanings. It turns hidden sense selection into a visible design choice.

prose_when_to_use:
Use this archetype when a term, label, metric, category, code, field name, policy word, or symbolic marker has more than one plausible related meaning and the difference matters for interpretation or action. It fits when the term is worth preserving, but its intended sense must be clarified.

Typical triggers include legal or policy words with everyday meanings, product metrics with multiple operational definitions, technical terms that cross disciplines, interface labels that imply several workflows, and educational terms that differ between ordinary and disciplinary usage. It is less useful when the term is simply vague, when the sign form is entirely misleading, or when the underlying category system itself must be redesigned.

prose_structural_problem:
The structural problem is false sameness. One sign form is shared, but multiple meanings are active. Participants may think they agree because the wording matches, while they actually act from different senses.

For example, “client” might mean software client, paying customer, legal client, or organizational account. “Active user” might mean currently online, active within seven days, licensed, or engaged above a threshold. “Positive” might mean favorable in everyday speech but detected in a clinical test. The term is not random; its senses are related enough that reuse feels natural, which is exactly why the disagreement can stay hidden.

prose_intervention_logic:
The intervention begins by locating the ambiguous term in the actual place where interpretation matters. Then the drafter, designer, facilitator, or governance owner inventories the plausible senses. Once the meaning cluster is visible, the intervention chooses the active sense for the current use, signals that choice through qualifiers or examples, bounds where the selected sense applies, and monitors whether misunderstanding remains.

The archetype works by separating three questions that are often collapsed: What are the possible related meanings? Which one governs this use? How will the intended audience know that without guessing?

prose_key_components:
### Ambiguous Term or Sign Form

The ambiguous term is the word, label, code, category name, field name, or symbol whose multiple senses are causing risk. It anchors the intervention. Without a concrete sign form, the work becomes general communication cleanup rather than polysemy disambiguation.

### Meaning Cluster

The meaning cluster lists the plausible related senses that different users may activate. This should include formal, informal, legacy, technical, legal, audience-specific, and domain-specific senses when relevant. The goal is not to prove that one sense is “correct” too early, but to reveal the interpretive menu.

### Sense Inventory

A sense inventory turns the cluster into an operational record. Each sense gets a short definition, scope, examples, non-examples, and known user groups or contexts. This prevents ad hoc explanation and gives downstream writers, designers, and reviewers something stable to reference.

### Context Cue

A context cue is the signal that helps users identify the intended sense: document section, speaker role, jurisdiction, product area, metric window, workflow stage, audience, version, discipline, or nearby wording. Cues are components of the intervention, not the whole intervention.

### Active Sense

The active sense is the intended meaning that governs the current use. It should be explicit enough for action. A reader should not need to infer that “context matters” in the abstract; they should be able to tell which sense applies here.

### Qualifier or Example

Qualifiers, examples, non-examples, parenthetical notes, and sense labels are the practical devices that steer interpretation. They should clarify without overloading. Good examples are often more effective than abstract definitions because they show the boundary between related meanings.

### Scope Boundary

The scope boundary defines where the selected sense applies and where it does not. This protects against context leakage: a term clarified for one policy, product area, jurisdiction, or technical layer should not silently travel into another setting where a different sense is intended.

### Misunderstanding Monitor

The misunderstanding monitor verifies whether disambiguation worked. Evidence can come from user questions, implementation defects, support tickets, appeals, disputes, search failures, classification errors, or stakeholder interpretation checks. Without this loop, the intervention may become glossary theater.

prose_common_mechanisms:
### Controlled Vocabulary

A controlled vocabulary restricts or labels terms so authorized senses are defined. It implements the archetype when many documents, systems, or metadata fields must coordinate around stable meanings. It is a mechanism, not the archetype itself.

### Sense Labeling

Sense labeling marks meanings with names such as “legal sense,” “technical sense,” “legacy sense,” “customer-facing sense,” or “internal metric sense.” This is useful when several senses must coexist and replacing the term would lose continuity.

### Definition Note

A definition note explains which sense applies and which related senses are excluded. It works best when attached to the point of interpretation. A note buried in a reference page may not help users acting in an interface, form, policy, or conversation.

### Examples and Non-Examples

Examples and non-examples make sense boundaries concrete. They are especially valuable when definitions are abstract, legalistic, technical, or culturally variable. They implement the archetype by showing included and excluded cases.

### Context-Specific Glossary

A context-specific glossary defines terms for one project, agreement, course, product area, discipline, or stakeholder group. It is a supporting artifact. The archetype is the broader process of selecting, scoping, signaling, and monitoring senses.

### Legal Definition Clause

A legal definition clause implements polysemy disambiguation where rights, obligations, eligibility, enforcement, consent, or liability depend on one selected meaning. It is high-stakes because later interpretation may become adversarial.

### Inline Clarifier

An inline clarifier places explanation at the point of use through parenthetical text, tooltip content, microcopy, hover definitions, or local labels. This is useful when users cannot be expected to consult separate documentation.

### Terminology Review Workshop

A terminology review workshop brings representatives of affected groups together to surface sense differences and agree on disambiguation rules. It is useful when teams, disciplines, communities, or legal roles activate different senses of the same word.

prose_failure_modes:
Glossary theater occurs when a glossary exists but users never consult it, or when it does not clarify the active sense where people act.

False precision occurs when a term is forced into one definition even though multiple bounded senses are legitimate.

Context leakage occurs when a definition created for one section, product, jurisdiction, or audience is reused elsewhere without its scope boundary.

Ontology smuggling occurs when a definition note hides a deeper disagreement about categories, values, or authority.

Audience-blind disambiguation occurs when experts define senses in ways that do not match how affected users actually distinguish meanings.

prose_neighbor_distinctions:
Polysemy Disambiguation is distinct from Sign–Meaning Alignment. Sign–Meaning Alignment asks whether a sign evokes the intended meaning at all; Polysemy Disambiguation asks which of several related meanings is intended.

It is distinct from Semantic Drift Monitoring. Drift monitoring is about meaning changing over time; polysemy disambiguation is about selecting among simultaneous related senses in a current use.

It is distinct from Symbolic Convention Governance. Convention governance maintains arbitrary symbolic systems; polysemy disambiguation may use conventions but is narrower: it handles multi-sense terms.

It is distinct from Context Anchor Design. Context Anchor Design resolves references to speaker, time, place, role, and situation. Polysemy Disambiguation resolves which sense of a multi-meaning term is active. The current reconciliation controls hold Context Anchor Design for merge review rather than drafting it now.

It is distinct from Ontology Clarification and Schema Conflict Resolution. If users disagree about the underlying categories rather than about the active sense of a term, the problem has moved beyond disambiguation.

prose_cross_domain_examples:
In law, a contract defines “affiliate” for the agreement rather than relying on everyday business usage.

In product analytics, a dashboard distinguishes daily active users from monthly active users and currently online users.

In education, a physics lesson distinguishes “work” as force over distance from everyday effort.

In healthcare communication, a portal explains whether “positive” refers to a detected marker rather than a favorable outcome.

In software documentation, an API guide distinguishes client software from paying customer and client organization.

In public policy, an eligibility form defines “household” for a benefits program and gives examples and non-examples.

prose_non_examples:
A confusing warning icon is not primarily polysemy; it is a sign-meaning or sign-type problem.

A term whose meaning changes over years is primarily semantic drift unless several senses must be selected in the present.

A phrase such as “send it there tomorrow” is primarily a context-anchor problem because the reference lacks time and place anchors.

A dispute about whether people should be classified as customers, citizens, patients, or members is likely an ontology or framing problem, not merely sense disambiguation.

prose_tradeoffs:
The main tradeoff is clarity versus readability. More qualifiers and definitions reduce ambiguity but can make text heavy.

Another tradeoff is continuity versus replacement. Keeping one term preserves familiarity, but creating distinct labels may be safer when wrong interpretation is costly.

A third tradeoff is standardization versus inclusion. A controlled sense can improve coordination, but it may suppress community meanings if governance is not transparent.

prose_invariants_to_preserve:
The main invariant is shared interpretation in the current use. A term should not silently license incompatible actions in the same operational context.

A second invariant is recoverability. The intended audience should be able to recover the active sense without expert guesswork.

A third invariant is legitimate variation. Related senses should remain distinguishable without erasing useful domain, legal, cultural, or community-specific meanings.

A fourth invariant is scope portability. When a definition travels, its boundary should travel with it.

prose_target_outcomes:
The target outcomes are reduced false agreement, fewer interpretation disputes, fewer implementation errors, more reliable documentation, clearer policy and legal language, improved system interoperability, and better teaching of specialized meanings.

A successful intervention does not always eliminate polysemy. Often it preserves useful multiple meanings while making each active sense visible when it matters.

prose_parameter_dimensions:
The first tuning dimension is disambiguation strength. Low-risk contexts may only need a contextual example; high-risk contexts may need formal definitions, legal clauses, review ownership, and monitoring.

The second is scope granularity. A broad definition is easier to remember, but bounded definitions are safer when the same term must mean different things in different contexts.

The third is point-of-use visibility. A central glossary may be enough for expert users, while public forms, safety-critical interfaces, and quick decisions need inline cues.

The fourth is sense preservation. Sometimes multiple senses should be preserved because each serves a valid community or function. Other times the safest move is to rename one sense or retire an ambiguous term.

The fifth is monitoring intensity. The more costly the misunderstanding, the more the system needs feedback from actual interpretation rather than relying on author confidence.

prose_variants_and_near_names:
Active Sense Selection is the local-use variant. It applies when one phrase, label, clause, or interface moment needs immediate clarification.

Context-Qualified Definition is the governance variant. It applies when a term legitimately needs different bounded definitions across contexts.

Sense Bridge Translation is a candidate variant. It applies when different communities use the same term with overlapping senses and need a translation bridge. It may later belong closer to Code / Register Adaptation or Sociolect Bridge Translation.

Near names include Sense Disambiguation, Term Disambiguation, Active Sense Clarification, Ambiguity Resolution, and Contextual Sense Selection. “Ambiguity Resolution” is too broad as a canonical name because ambiguity can come from many sources besides polysemy.

Active Sense Selection

short_definition: Choose and explicitly signal which sense of a multi-meaning term governs a particular local use.

distinctive_feature: The variant focuses on local selection at a specific point of use rather than maintaining a large vocabulary or documentation set.

distinct_from_parent: The parent includes inventorying senses, setting scope, and monitoring misunderstanding; this variant emphasizes the local act of selecting and marking one active sense.

still_same_parent_because: It still solves the same structural problem: one sign form can activate several related meanings unless interpretation is constrained.

use_when: A term has several accepted related senses, but only one should govern the current instruction, clause, interface label, or decision.

use_when: The user must act immediately and cannot pause to infer meaning from a large definition system.

domain: Product UI

example: A dashboard labels “active users” as “active in last 30 days” so readers do not confuse it with currently-online users.

domain: Policy

example: A rule defines “resident” for eligibility as legal residence, not current physical presence.

failure_modes: The selected sense is hidden in a note users never see.

failure_modes: A qualifier narrows the term so much that it conflicts with upstream definitions.

Context-Qualified Definition

short_definition: Define the same term differently across bounded contexts while making each scope explicit.

distinctive_feature: The decisive move is preserving multiple governed definitions rather than forcing one universal meaning.

distinct_from_parent: The parent can use many tactics; this variant specifically manages context-bounded definitions.

still_same_parent_because: The problem remains multi-meaning interpretation of a shared sign form.

use_when: A term legitimately has different meanings in legal, technical, customer-facing, operational, or disciplinary contexts.

use_when: Replacing the term would damage continuity, but unqualified reuse causes errors.

example_domains: law standards enterprise_documentation

domain: Technical Standards

example: A standard defines “node” differently for network topology and software deployment sections, with explicit scope labels.

domain: Law

example: A contract defines “affiliate” for one agreement rather than relying on everyday business usage.

failure_modes: Context boundaries become so complex that users cannot know which definition applies.

failure_modes: Definitions diverge without a governance owner, producing incompatible downstream systems.

Sense Bridge Translation

short_definition: Translate a polysemous term across communities so each group knows which local sense maps to the shared discussion.

distinctive_feature: The variant focuses on cross-community sense mapping rather than one-context clarification.

distinct_from_parent: The parent can operate within one community; this variant handles sense differences between communities.

still_same_parent_because: The ambiguity is still anchored in one sign form carrying multiple related meanings.

use_when: Different professional, social, disciplinary, or language communities attach partially different senses to the same term.

use_when: Coordination requires preserving local meanings while preventing false agreement.

domain: Healthcare

example: Clinicians and patients clarify whether “positive” means favorable news or positive test result.

domain: Engineering / Legal

example: Teams align whether “shall” is a requirement, recommendation, or future intent in a specification.

failure_modes: The bridge translation erases a community-specific sense that matters for legitimacy or safety.

failure_modes: Participants mistake translated terms for exact synonyms.

near_names:
Sense Disambiguation
Active Sense Clarification
Term Disambiguation
Ambiguity Resolution
Context-Specific Definition