Skip to content

Target Complete Mapping Design

Define the required target space and ensure every target has at least one valid, feasible, and verifiable source-side witness, with no silent gaps.

Overview

Target-Complete Mapping Design is the transferable solution pattern behind practical surjectivity: define the target space that must be covered and require every target to have at least one valid source-side witness. The witness may be an input that produces an output, a path that reaches a state, an implementation that fulfills a requirement, a capability that handles an incident class, a provider that serves a population, or an evidence chain that realizes a reporting obligation.

The pattern changes the direction of assurance. Source-side inventories ask what existing assets can do. Target-complete design asks, for each required target, “What valid source reaches this?” That reversal exposes omissions hidden by high aggregate activity, popular-case optimization, large source inventories, or many-to-one mappings. A system with hundreds of sources can still leave one important target untouched; a system with a small source set can be complete if every target has a valid preimage.

Mathematical surjectivity supplies the invariant, but operational use requires more than a bare edge. The source must be allowed, current, feasible, sufficiently capable, and usable under the conditions that define the target. The target set itself must be explicit and resistant to shrink-to-pass gaming. The mapping must survive source retirement, target drift, capacity changes, access barriers, and evidence decay. The result is not merely a coverage percentage; it is a maintained target-side assurance structure.

Structural problem

Many systems are organized around sources: teams, services, functions, routes, models, providers, controls, tools, implementations, or records. Their dashboards therefore report source activity—how many services exist, how many tests ran, how many playbooks were written, how many providers enrolled, or how many states appear in a diagram. None of those facts guarantees that every required target is reached.

The failure emerges whenever the image of the actual mapping is smaller than the promised target space. A requirement has no implementation. A district has no usable service route. A declared recovery state cannot be entered. An incident class has no exercised capability. A competency has no assessment path. A reporting field has no valid source derivation. Because common targets generate most activity, aggregate performance can remain strong while rare or inconvenient targets are systematically absent.

Nominal linking creates a second layer of false assurance. A target may have a recorded source that is unauthorized, inaccessible, capacity-deficient, stale, dependent on failed infrastructure, or valid only under conditions that do not apply. Formal surjectivity on paper then coexists with operational non-surjectivity. The pattern therefore treats every mapping edge as a claim requiring a witness-validity rule and current evidence.

A third failure lies in the target set. Organizations often derive the target taxonomy from what current sources already handle. Difficult cases disappear into “other,” excluded populations are absent from the denominator, and new obligations are not added to the coverage map. A perfect score against a truncated target space is not complete coverage. The target space must be governed independently enough to reveal rather than absorb source limitations.

Intervention grammar

The intervention begins by defining the required target space. Targets should come from obligations, affected cases, states, competencies, outputs, service promises, or design intent—not merely from what the current source inventory happens to produce. Every target receives a stable identity, definition, inclusion rationale, version, and owner or stakeholder. Unknown and emerging targets need a path into the taxonomy rather than being forced into the nearest convenient category.

Next, define the valid source space and mapping relation. Sources may be inputs, routes, providers, capabilities, implementations, tests, artifacts, or paths. Their membership criteria and operating envelope determine whether they can count. The relation may be a function, a many-to-many relation, a guarded path, a derivation chain, or a conditional service route. What matters is the target-side contract: for every included target, at least one valid source-side preimage exists.

The mapping is then populated with explicit preimage witnesses. A witness is not just an identifier or hyperlink. It states the source, exact target, conditions, scope, version, authority, dependencies, evidence, and owner. Witness validation asks whether the claimed relation actually holds. In formal systems this may be a proof or reachability trace. In software it may be an executable requirement test. In service systems it may be an end-to-end journey under realistic eligibility, capacity, time, language, geography, and modality constraints.

Targets with no valid witness remain visible in an uncovered-target register. Each gap receives consequence assessment, interim handling, accountable ownership, and a repair path. The repair may add a source, expand a capability, change a route, procure a provider, redesign a target, or explicitly exclude the target through authorized and time-bounded review. Exclusion changes the contract and must not be reported as ordinary remediation.

Finally, maintain the invariant. Target additions, target splits, new obligations, source retirement, source degradation, mapping edits, dependency changes, and evidence expiration all trigger coverage impact review. Counterexample search deliberately looks for a target without a valid witness. Revalidation checks not only binary reach but also capacity, accessibility, quality, independence, and current operation. When complete coverage temporarily fails, the system degrades honestly through deferral, manual handling, limited service, escalation, or explicit unavailability rather than pretending the witness still exists.

Core components

ComponentDescription
Required target space The required target space is the codomain that the mapping promises to fill. It may contain required outputs, service regions, population classes, states, requirements, competencies, risk cases, or reporting obligations. Its construction is a substantive governance act. Targets need precise definitions, stable identifiers, inclusion criteria, boundary cases, and change history. Target definitions should be challenged by affected stakeholders because the most consequential omissions often begin in the taxonomy rather than in the source map. The target set should not be silently inferred from observed demand. People who cannot access a service do not appear in service records; unsupported incident types may be miscoded; unreachable states may never enter logs; unimplemented requirements may be omitted from test reports. A target-space change monitor therefore combines formal obligations, scenario analysis, incidents, stakeholder input, boundary critique, and environmental change.
Valid source space The valid source space defines what can legitimately serve as a preimage. A source needs identity, scope, current status, authorization, ownership, dependencies, capacity, and operating conditions. A provider that is closed, a route that depends on unavailable transport, a test that no longer matches the requirement version, or a recovery procedure that requires the failed control plane should not count. Source inventories often contain duplicates and aliases. Stable source identity prevents one resource from being counted as several independent witnesses. Dependency mapping reveals when apparently distinct sources share the same infrastructure, supplier, authority, model, data, or team.
Mapping relation and target-coverage contract The mapping relation explains how sources reach targets. It can be direct or composite, deterministic or conditional, static or temporal. The contract states the minimum target-side condition. The base form requires at least one valid witness per target. Strengthened forms can require minimum capacity, response time, quality, accessibility, or several independent witnesses. The contract should distinguish these dimensions. Binary existence answers whether a target has any valid preimage. Capacity asks whether the witness can handle expected demand. Accessibility asks whether the target case can actually use the witness. Quality asks whether the outcome meets the target standard. Resilience asks whether coverage survives witness or dependency failure. Combining them into one percentage invites metric gaming and obscures why a target is weakly covered.
Preimage witnesses and validity rules A preimage witness is the target-facing proof of coverage. It can be an executable input, route trace, implementation-and-test chain, service journey, capability demonstration, derivation record, or formal proof. The witness-validity rule defines what must be true before the target is marked covered. Validity is domain-specific but structurally similar. The witness must correspond to the same target definition and version, be authorized, feasible under declared conditions, current, sufficiently capable, and supported by evidence. In human-facing systems it must also be usable by the target population. In high-consequence systems, evidence may require independent testing or repeated demonstration.
Coverage matrix and uncovered-target register A target-to-witness matrix reverses the usual source inventory. Every target occupies an explicit row, and each valid source-side witness is visible. Empty rows are immediate gaps. Rows with one weak source are fragile. Rows with several labels pointing to one dependency reveal illusory redundancy. Rows whose evidence has expired become provisional rather than silently remaining green. The uncovered-target register preserves gaps as first-class work. It records the target, reason, consequence, affected parties, interim control, owner, planned action, deadline, and status. The register should distinguish “no source exists,” “candidate source is invalid,” “source lacks capacity,” “access is blocked,” “evidence is stale,” and “target definition is disputed,” because each requires a different intervention.
Feasibility, capacity, access, and equity A mapping may be onto in an abstract model while failing in use. Feasibility checks whether the witness can operate under relevant constraints. Capacity checks whether the source can serve assigned targets at expected load. Access checks the path from the target side. Equity checks whether nominal coverage differs systematically across populations, modalities, locations, languages, or authority classes. These checks prevent a common deception: a single central provider is assigned to every target, producing a perfect binary matrix, while waiting time, travel, eligibility, cost, or modality make the service unusable. A target is covered only according to the contract actually promised.
Change control, evidence, and revalidation Coverage is a maintained property, not a one-time certification. Source retirement, new requirements, target splits, staffing changes, changed dependencies, capacity loss, and policy revisions can create gaps immediately. Mapping change control requires impact review before source or relation changes are approved. Target-space diff review treats every new target as uncovered until evidence exists. Evidence records bind the claim to a version and date. Revalidation cadence may be periodic, event-driven, or risk-based. Counterexample search tests the universal claim directly: find one target with no valid witness. Because universal coverage is falsified by a single counterexample, adversarial target-side sampling is more informative than average source performance alone.

Common mechanisms

Requirements traceability matrices, test-case linkers, and lineage systems are useful when targets are formal obligations. Bipartite coverage matrices and set-cover analysis help where many sources can serve many targets. Graph reachability and path synthesis fit transition systems. Service-area analysis and accessibility tests fit geographic and population coverage. Capability crosswalks fit incident and mission planning.

Dashboards support attention but are not evidence. They should expose the target denominator, uncovered rows, witness validity, evidence age, capacity, access, dependency concentration, exclusions, and remediation state. A single green percentage should never conceal which targets are absent or fragile.

Recertification and counterexample search provide ongoing assurance. N+1 tests strengthen high-consequence targets by removing one witness or dependency and retesting coverage. Source-capacity load tests reveal mappings that are formally complete but operationally overloaded. Scenario enumeration workshops expand the target space before reality does so through failure.

Parameter dimensions

  • Target-space granularity: broad classes versus fine-grained cases; too coarse hides gaps, while too fine can make governance intractable.
  • Coverage threshold: one valid witness, several witnesses, or weighted obligations by target consequence.
  • Witness validity depth: documentary attestation, inspection, simulation, executable test, end-to-end demonstration, or formal proof.
  • Operating envelope: conditions under which a witness must remain valid, including load, time, location, permissions, environment, and failure state.
  • Capacity margin: minimum headroom above expected demand.
  • Accessibility threshold: how eligibility, cost, travel, language, modality, disability access, and authority are incorporated.
  • Independence threshold: how much common dependency is acceptable among redundant witnesses.
  • Evidence lifetime: how quickly evidence expires under time, drift, source change, or target revision.
  • Gap tolerance: whether temporary uncovered targets trigger shutdown, limited service, escalation, or time-bounded exception.
  • Revalidation cadence: fixed, event-triggered, risk-based, or continuous.
  • Coverage reporting: binary, graded, weighted, target-by-target, or multidimensional.
  • Target governance: who can add, remove, split, merge, challenge, or exclude targets.

Invariants

  1. Every included target has at least one identifiable valid preimage witness.
  2. Target membership is versioned and cannot be silently reduced to improve reported coverage.
  3. Every witness uses the same target definition and version as the coverage claim.
  4. A nominal link without feasible operation and current evidence does not count.
  5. Uncovered targets remain visible and owned until repaired or explicitly excluded.
  6. Source and target changes trigger impact analysis before coverage claims persist.
  7. Binary reach remains separate from capacity, quality, accessibility, and resilience.
  8. Redundant witnesses are tested for common dependencies.
  9. Evidence and exclusions are reviewable and proportionate to consequence.
  10. Temporary invariant failure activates honest degradation rather than false assurance.

Recognized variants

The State-Reachability Coverage Variant uses complete paths as witnesses. It applies when every declared target state must be reachable under valid guards and resources. Diagram connectivity is insufficient if path conditions cannot co-occur or depend on failed infrastructure.

The Requirement-to-Implementation Coverage Variant treats requirements as targets and implementation-plus-verification chains as witnesses. It is stronger than ordinary traceability because empty target rows and invalid tests violate the contract.

The Service-and-Population Coverage Variant evaluates coverage from the affected target's perspective. A service counts only when it is reachable, eligible, sufficiently capable, and usable under the target's conditions.

The Redundant Target Coverage Variant requires multiple sufficiently independent witnesses for protected targets. It strengthens the cardinality of the preimage set and adds common-mode dependency analysis.

Neighbor distinctions

  • Completeness Audit diagnoses omissions across a space. Target-Complete Mapping Design constructs, owns, and maintains a valid witness for every target.
  • Domain–Codomain Delimitation defines admissible input and output sets. It does not require every valid target output to appear in the mapping image.
  • Traceability Linking records relationships and lineage. It does not necessarily prohibit empty target rows or validate the meaning of each link.
  • Response Repertoire Expansion adds options when existing responses are insufficient. It can repair a gap but does not govern the complete target map.
  • Mapping Reconciliation resolves conflicts between competing correspondences. This archetype may retain several witnesses and cares first about target coverage.
  • Closure-Preserving Operation ensures outputs do not escape the valid set. Target-complete mapping addresses the converse failure: valid targets that no source reaches.
  • Diverse Functional Redundancy protects one function through heterogeneous alternatives. Here, the base concern is every target; redundancy is a strengthened variant.
  • Coverage Probability Calibration concerns the frequency with which statistical intervals contain a quantity, not whether every target element has a preimage.
  • Structure-Preserving Embedding Design places source structure into a target without conflict. It emphasizes injective placement and preservation rather than target-side completeness.
  • Conjunctive Path Assurance tests latent paths activated only by joint conditions. A reachability witness may use it, but the parent target-complete pattern is broader.

Examples

Requirements and verification

A safety-critical program maintains an authoritative requirement set. Every requirement must have an implementation owner, implementation artifact, executable or reviewable verification method, current result, and release trace. The program treats a missing implementation, a test that no longer matches the requirement, or a stale result as an uncovered target. Requirement additions and changes automatically open coverage work.

Public service coverage

A public service mandate applies to every district, language group, disability access class, and time band. The source set contains fixed facilities, mobile teams, remote channels, transport support, and mutual-aid agreements. Each target needs an end-to-end usable route, not merely a nearby provider. Capacity, eligibility, opening hours, travel, modality, and language are part of witness validity.

Incident response

An incident taxonomy defines every class the organization promises to handle. Each class maps to an exercised playbook, competent team, tools, authority, communication path, and escalation route. Tabletop and live exercises validate witnesses. New incident classes remain uncovered until capability evidence exists.

Education and competency

A curriculum declares required competencies. Every competency has at least one instructional sequence, practice opportunity, assessment, accommodation path, and feedback route. A course catalog with many offerings is not enough; the target-side matrix shows whether any competency is orphaned or assessed only indirectly.

Formal state reachability

A control system declares operational, degraded, recovery, and safe states. For every required state, a path from an allowed initial state is generated and tested under actual guards, permissions, and resource constraints. States visible only in the model but not attainable in the deployed system are uncovered targets.

Data and reporting

A regulatory report contains mandatory target fields. Each field has a validated derivation from source data, lineage, transformation rule, freshness threshold, quality test, and fallback. A report field without a source derivation remains explicit rather than being populated with an ambiguous default.

Non-examples

A list of valid output types is not sufficient because it does not show that every output can be produced. A provider directory is not sufficient because it does not test whether every target population can use a provider. A traceability graph is not sufficient if target links are optional or stale. A confidence-interval coverage study uses a different meaning of coverage. A one-to-one assignment problem may require bijectivity, which adds source-side uniqueness beyond this target-side invariant.

Tradeoffs

The strongest pressure is between complete coverage and resource concentration. Rare targets can be expensive. The honest options are to fund a witness, redesign the obligation, or explicitly disclose the exclusion; silently dropping the target is not coverage design. A second pressure lies between breadth and quality. A minimal witness can make every row nonempty while producing poor outcomes. Multi-dimensional thresholds therefore matter.

Fine target granularity reveals inequity and edge cases but raises maintenance cost. Coarse targets simplify governance but can hide systematically unserved subgroups. Central mapping improves comparability and accountability but may miss local conditions. Distributed ownership improves fit but risks inconsistent validity standards.

Redundancy improves resilience but can create false confidence when alternatives share dependencies. Strong evidence improves trust but adds administrative burden and may expose sensitive information. These are design choices to govern, not reasons to replace target-side assurance with aggregate activity metrics.

Failure modes and safeguards

The most dangerous failure is the phantom witness: a recorded source that does not actually reach the target. Explicit validity rules, end-to-end tests, and evidence expiration address it. Nominal coverage without access is countered by testing from the target perspective. Codomain truncation is countered by versioned target definitions, authorized exclusions, historical comparisons, and independent review.

Stale coverage is countered by target-space diffs, source change control, recertification, and event triggers. Overloaded sources are exposed through capacity testing. Correlated witnesses require dependency maps and N+1 exercises. Double counting requires stable identity and provenance. Unowned gaps require target-side accountability. Binary metric capture requires separate dimensions for capacity, quality, access, and resilience.

Emergent target blindness requires scenario enumeration, incident learning, stakeholder challenge, and an explicit path for unknown targets. Mapping ambiguity requires typed relations and semantic contracts. Coverage without safe degradation requires fallback rules that make failure visible and limit harm.

Ethical and governance guidance

A target space encodes whose needs and obligations matter. It should be contestable, and affected groups should have a way to identify missing targets or reject nominal witnesses. Exclusions should identify who bears the residual risk and who authorized it. Equity review should examine both missing rows and weaker witness quality.

Evidence collection should be proportionate and privacy-aware. A detailed map of vulnerable populations, infrastructure gaps, or common dependencies may itself be sensitive. Transparency can therefore be role-appropriate without becoming secrecy that prevents accountability.

Complete coverage does not imply that every target should be acted upon identically or without consent. The pattern guarantees a valid path relative to a legitimate contract; it does not legitimate the contract itself. Infeasible coverage should be communicated honestly rather than converted into paperwork or false reassurance.

Use guidance

Use Target-Complete Mapping Design when a system makes an exhaustive target-side promise and missing even one included target matters. Start with the target set, not the source inventory. Define what counts as a witness before populating the map. Test the hardest and least visible targets first. Report gaps by identity and consequence, not only as a percentage. Separate existence from capacity, quality, access, and resilience. Revalidate after every material source or target change.

Use a neighboring pattern when the problem is only scope definition, gap diagnosis, lineage, response expansion, mapping conflict, closure, redundancy of one function, or statistical interval calibration. The decisive question is simple: must every required target have a valid source-side preimage, and will the system govern that invariant over time? If yes, this archetype applies.

Common Mechanisms

  • Accessibility Reachability Test — Checks that each required target can actually be reached and used in practice by the people it is meant to serve — not just that a route exists on paper — and flags targets reachable only inequitably.
  • Bipartite Coverage Matrix — Lays the required targets and the valid sources on two axes and marks every covering pair, so any target whose row is blank stands out as an uncovered gap.
  • Capability–Case Crosswalk — Reconciles a catalog of what the organization can do against the list of cases it must serve, exposing prioritized cases that no capable, adequately-resourced provider actually covers.
  • Coverage Counterexample Search — Actively hunts for a single required target that no valid source covers — a counterexample to the completeness claim — instead of tallying how much is covered.
  • Coverage Dashboard — A live surface that shows current coverage against the required targets, weighted by priority, and lights up the moment a newly-added target has no witness yet.
  • Graph Reachability Analysis — Models sources, intermediate steps, and targets as a directed graph and computes which targets are actually reachable, so any target hidden behind a broken dependency shows up as a provable gap.
  • Periodic Coverage Recertification — On a fixed cadence, re-proves from scratch that every required target still has a valid witness — with an independent sign-off — so coverage that quietly decayed since last time is caught before it is assumed.
  • Preimage Witness Generator — For a target that currently has no covering source, constructs at least one concrete witness — a route, capability, or artifact — that provably reaches it, turning a gap into a covered case.
  • Redundancy N+1 Check — Removes one witness — or one shared dependency — from a protected target's coverage and rechecks that the target is still reached, proving the redundancy is real rather than nominal.
  • Requirements Traceability Matrix — Threads every requirement through to the design, code, and verification that satisfy it, so any requirement with no downstream link — or no passing test — is a visible coverage hole.
  • Scenario Enumeration Workshop — A facilitated session that deliberately enumerates the full space of cases the system must serve — surfacing rare, edge, and unthought-of targets before reality forces them onto the list.
  • Service-Area Gap Analysis — Overlays required coverage on the actual usable reach of the available sources to expose the regions and groups no source can serve — and whether the gaps fall unequally.
  • Set-Cover Analysis — Selects the smallest or cheapest set of sources whose combined reach covers every required target — turning 'cover everything' into a solvable optimization and exposing targets no source can reach.
  • Source Capacity Load Test — Drives a source to the realistic peak demand of all its assigned targets to confirm it can actually serve at load — and that it degrades safely rather than silently dropping coverage when overwhelmed.
  • Target-Space Difference Review — Diffs the required target set and mapping against their last certified baseline and treats every newly added or changed target as uncovered until a fresh witness proves otherwise.
  • Test-Case-to-Requirement Linker — Binds each verification test to the specific requirement it exercises, creating a per-requirement witness record and exposing requirements with no test bound to them.
  • Uncovered-Target Triage — Works the register of uncovered targets one by one, assigning each an accountable owner and a disposition — fix, defer, or authorized exclusion — so no gap sits unowned or silently dropped.
  • Witness Validation Test — Executes a claimed witness under realistic conditions to confirm it actually reaches its target — turning a recorded link into dated evidence and unmasking phantom witnesses that exist only on paper.

Compression statement

When a system promises complete target-side coverage, define and version the required target set independently of current capability, enumerate valid source elements, specify the mapping relation, require a testable preimage witness for every target, distinguish binary reach from quality, capacity, access, and independence, register and own every uncovered target, govern source and target changes, search actively for counterexamples, and revalidate before claiming that the mapping is onto in practice.

Canonical formula: target_complete(f, X, Y_required) iff for every y in Y_required there exists x in X_valid such that f(x) = y and witness_valid(x, y); operational_coverage also requires feasible(x, y), sufficient_capacity(x, y), and usable_access(x, y)

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

Built directly on (5)

  • Completeness: No gaps in structure.
  • Coverage / Reachability: A completeness claim in the surjective direction: every required target in a target set is reachable from at least one of the system's inputs, pathways, or mechanisms.
  • Function (Mapping): Relates inputs to outputs.
  • Preimage: The set of all inputs that map to a given output under some mapping.
  • Surjectivity: A coverage-guaranteeing mapping in which every element of the target is hit by some input, leaving no gap in the codomain.

Also references 25 related abstractions

Variants

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

State-Reachability Coverage Variant · subtype · recognized

Require every declared target state to be reachable from at least one allowed initial state through a valid path.

  • Distinct from parent: This variant adds transition guards, path liveness, and state-space dynamics to the parent target-completeness invariant.
  • Use when: A transition system, workflow, protocol, or control architecture declares states that must all be attainable; Unreachable states would make advertised capabilities, recovery modes, or obligations fictitious.
  • Typical domains: workflow engineering, control systems, protocol design, recovery planning
  • Common mechanisms: graph reachability analysis, preimage witness generator, witness validation test, coverage counterexample search

Requirement-to-Implementation Coverage Variant · implementation variant · recognized

Ensure every accepted requirement has at least one implementing artifact and one credible verification witness.

  • Distinct from parent: This variant specializes the source and target types and usually requires lifecycle traceability through change, test, release, and retirement.
  • Use when: A program, policy, standard, or product has an authoritative requirement set that must not contain orphan obligations; Traceability links need to carry evidence of implementation and verification rather than merely indicate association.
  • Typical domains: software assurance, systems engineering, policy implementation, regulated compliance
  • Common mechanisms: requirements traceability matrix, test case to requirement linker, witness validation test, target space diff review, periodic coverage recertification

Service-and-Population Coverage Variant · domain variant · recognized

Ensure every obligated region, population, or case class has at least one usable and sufficiently capable route to service.

  • Distinct from parent: This variant makes equity, user journey, capacity, and geographic or institutional barriers central to the coverage test.
  • Use when: A service promise applies to a bounded population, geography, modality, eligibility class, or need category; Nominal availability may conceal access, capacity, language, cost, authority, or travel barriers.
  • Typical domains: public health, transportation, education, legal aid, emergency services
  • Common mechanisms: service area gap analysis, accessibility reachability test, source capacity load test, uncovered target triage, coverage dashboard

Redundant Target Coverage Variant · risk or failure variant · recognized

Require each protected target to have multiple sufficiently independent valid witnesses so one source failure does not create an uncovered target.

  • Distinct from parent: The base parent needs one valid preimage per target; this variant sets a higher cardinality and independence threshold.
  • Use when: Loss of a single source would make a consequential target unreachable or unsupported; Nominal alternatives may share common dependencies and therefore require independence testing.
  • Typical domains: critical infrastructure, supply networks, emergency response, data and compute services
  • Common mechanisms: bipartite coverage matrix, redundancy n plus one check, source capacity load test, periodic coverage recertification

Near names: Coverage-Complete Mapping Design, Target-Space Coverage Assurance, Onto Coverage Design, No-Gap Mapping Design, Preimage-Complete Coverage.