Data Analysis Lifecycle

Parent: Data Analysis · Published reference · snapshot 2026-09-08 · skill da-2-data-analysis-lifecycle

Taxonomy context: Data Analysis > Data Analysis Lifecycle (Process)

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Data Analysis Lifecycle (Process)

Taxonomy context: Data Analysis > Data Analysis Lifecycle (Process) [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#data-analysis-lifecycle-process]
The Data Analysis Lifecycle is the structured, iterative process that carries a project from an initial business question through data acquisition, preparation, analysis, and interpretation, to communicated and operationalized insight. No single canonical standard exists; instead several well-adopted frameworks describe roughly the same phases with different emphasis and vocabulary. Understanding the lifecycle helps analysts know which phase they are in, what must be true before advancing, and when to loop back. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#data-analysis-lifecycle-process]

Sub-skill routing table

This hub consolidates 13 lifecycle sub-skills as on-demand reference files. When a task matches a row, Read the listed references/<name>.md before answering - do not rely on this table alone for deep answers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sub-skill-routing-table]

1. Why a lifecycle matters

Raw data does not automatically answer questions. Each phase in the lifecycle performs a distinct transformation: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]
- Reduces ambiguity - turning vague questions into measurable objectives. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]
- Ensures fitness of data - catching quality problems before they corrupt findings. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]
- Separates concerns - keeping exploratory work from confirmatory work, and analysis from deployment. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]
- Creates checkpoints - natural gates where the team can confirm alignment with stakeholders before investing further. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]
Without an explicit lifecycle, projects commonly suffer from scope creep, premature modeling on dirty data, and findings that cannot be reproduced or deployed [Source 1, Source 2]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#1-why-a-lifecycle-matters]

2.1 CRISP-DM (Cross-Industry Standard Process for Data Mining)

Developed in the late 1990s by Daimler-Chrysler, SPSS, and NCR. Still the most widely cited open standard for data mining and analytics projects [Source 3]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#21-crisp-dm-cross-industry-standard-process-for-data-mining]
Six phases arranged in a cycle (the outer ring can restart after deployment): [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#21-crisp-dm-cross-industry-standard-process-for-data-mining]
Arrows in the CRISP-DM diagram flow in both directions: unsatisfactory evaluation sends the team back to modeling or data preparation; business understanding may be revised when data understanding reveals the original question is unmeasurable [Source 3]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#21-crisp-dm-cross-industry-standard-process-for-data-mining]

2.2 EMC / Big Data Analytics Lifecycle

Popularized by EMC's Data Science and Big Data Analytics book and Wiley's companion edition. Six phases with a heavier emphasis on analytic sandboxes and operationalization [Source 4]: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#22-emc-big-data-analytics-lifecycle]
- Data Preparation (ELT/ETL into sandbox) [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#22-emc-big-data-analytics-lifecycle]
Distinct from CRISP-DM in that it explicitly names the sandbox as a prerequisite for phase 2, and distinguishes "Model Planning" (choosing techniques) from "Model Building" (executing them). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#22-emc-big-data-analytics-lifecycle]

2.3 OSEMN

A minimalist five-step mnemonic popular in academic data science courses: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#23-osemn]
Strengths: simple and memorable. Weaknesses: omits business framing (starts at "Obtain"), ignores deployment, and treats the process as linear [Source 5]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#23-osemn]

2.4 TDSP (Team Data Science Process)

Published by Microsoft in 2017. Closest to CRISP-DM but adds explicit team roles, deliverable templates, and agile sprint cadence. Five stages: Business Understanding → Data Acquisition and Understanding → Modeling → Deployment → Customer Acceptance [Source 5]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#24-tdsp-team-data-science-process]

3. Canonical phase descriptions

The following synthesizes the phases common across frameworks into a single reference. The references/ files listed in the Sub-skill routing table cover each phase and framework in detail. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#3-canonical-phase-descriptions]

Phase 1 — Problem Definition / Business Understanding

Input: stakeholder intent, existing domain knowledge, prior analyses. Output: a written problem statement, success criteria (KPIs or evaluation metrics), and an initial set of hypotheses. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-1-problem-definition-business-understanding]
The team works with business owners to translate a vague goal ("improve customer retention") into a concrete, measurable objective ("predict 30-day churn with precision ≥ 0.75 at recall ≥ 0.60"). Resources, timeline, and risks are assessed here. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-1-problem-definition-business-understanding]
Why it matters: an ill-defined question cannot be answered with data. Changing the question halfway through wastes preparation and modeling effort. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-1-problem-definition-business-understanding]
Pitfall: treating this phase as a formality. Teams that skip or rush it often discover midway through modeling that the available data cannot actually answer the question they care about [Source 1]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-1-problem-definition-business-understanding]

Phase 2 — Data Acquisition and Understanding

Input: problem statement, knowledge of available data sources. Output: a data inventory, quality assessment report, initial summary statistics, and a decision on whether the data is sufficient to proceed. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-2-data-acquisition-and-understanding]
The team collects initial data, examines its structure and provenance, documents quality issues (nulls, duplicates, encoding errors, date range gaps), and explores distributions and inter-variable relationships. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-2-data-acquisition-and-understanding]
Pitfall: trusting that data labeled "clean" actually is clean. Source systems commonly have undocumented conventions (e.g., sentinel values like -9999 for missing) that only domain knowledge or careful profiling reveals [Source 1, Source 2]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-2-data-acquisition-and-understanding]

Phase 3 — Data Preparation

Input: raw or semi-structured data, quality assessment. Output: an analysis-ready dataset (feature matrix + target variable, or cleaned tabular data for descriptive work). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
This phase typically consumes 60–80% of total project time. It includes: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
- Cleaning: removing or imputing nulls; correcting format inconsistencies; deduplication. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
- Transformation: normalization, encoding categorical variables, date parsing, log transforms. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
- Integration: joining tables across systems, resolving entity mismatches. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
- Feature engineering: constructing derived columns that encode domain knowledge. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
An analytic sandbox - a compute environment with sufficient CPU, RAM, and storage to hold working copies of the data - is often set up at the start of this phase [Source 4]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
Pitfall - data leakage: features that encode information from the future (relative to the prediction point) will inflate model performance metrics while producing a model that fails in production. Any transformation that aggregates across the full dataset (e.g., computing a z-score mean on both training and test rows) must be fit on training data only and applied to test data [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]
Pitfall - aggressive outlier removal: deleting extreme values simplifies modeling but can remove the most informative signals, especially in anomaly detection or fraud contexts [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-3-data-preparation]

Phase 4 — Analysis / Modeling

Input: analysis-ready dataset, modeling plan (technique selection, validation strategy). Output: trained model(s) or analytical findings with performance metrics. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-4-analysis-modeling]
For descriptive and exploratory analysis, this phase produces summary statistics, visualizations, and identified patterns. For predictive analysis, it produces one or more fitted models with cross-validated performance estimates. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-4-analysis-modeling]
Model planning (choosing the technique family and validation design) is logically distinct from model building (running training and tuning loops). Conflating them leads to technique choices driven by familiarity rather than problem fit [Source 4]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-4-analysis-modeling]
Pitfall - overfitting through hyperparameter tuning: testing many parameter combinations without a held-out test set causes the model to fit noise in the validation set, producing strong validation scores that do not transfer to new data [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-4-analysis-modeling]

Phase 5 — Evaluation

Input: model or analysis output, success criteria from Phase 1. Output: judgment of whether findings meet the original objective; recommendation to proceed or iterate. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-5-evaluation]
The team compares model performance against the thresholds established in Phase 1, assesses whether the findings have practical as well as statistical significance, and checks that the model's behavior makes sense to domain experts (a sanity check that catches leakage and labeling errors not surfaced by metrics alone). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-5-evaluation]
If evaluation fails, the team loops back - usually to Phase 3 (more features, different cleaning) or Phase 2 (additional data sources). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-5-evaluation]
Pitfall - confusing statistical and practical significance: a result can be statistically significant yet too small to matter operationally. A 0.1% improvement in click-through rate may not justify the cost of implementation [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-5-evaluation]

Phase 6 — Communication of Results

Input: evaluated findings, audience knowledge of domain. Output: narrative report, dashboard, or presentation that conveys key findings and recommended actions to decision-makers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-6-communication-of-results]
Effective communication requires translating technical outputs into business terms. The team quantifies business value (revenue impact, cost savings, risk reduction), documents key assumptions, acknowledges limitations, and prepares supporting materials (code, data dictionaries, reproducibility documentation). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-6-communication-of-results]
Pitfall - model explainability missteps: presenting SHAP plots or feature importances without business context confuses rather than informs stakeholders. Explanation tools are most useful when tied to a specific decision the audience must make [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-6-communication-of-results]

Phase 7 — Operationalization / Deployment

Input: approved findings or model, deployment environment specifications. Output: running system (scheduled report, API endpoint, embedded model), monitoring plan. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-7-operationalization-deployment]
The team deploys the model or analysis process so that stakeholders can regularly access results. Pilot deployments in a controlled environment precede full rollout. Monitoring tracks whether model performance degrades as data distributions shift over time. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-7-operationalization-deployment]
Pitfall - ignoring concept drift: a model trained on historical data may fail silently as real-world behavior changes. Without a monitoring plan and retraining schedule, model staleness goes undetected [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#phase-7-operationalization-deployment]

4. The iterative nature of the lifecycle

All frameworks represent the lifecycle as cyclic or iterative, not strictly linear. Common feedback loops: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]
- Evaluation → Data Preparation: model fails to meet threshold; team engineers additional features or acquires more data. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]
- Modeling → Business Understanding: the most predictive variables are ones the business cannot act on; problem definition must be revised. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]
- Communication → Problem Definition: stakeholders raise a follow-up question not covered by the original scope; a new project iteration begins. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]
- Operationalization → Data Understanding: production data differs from training data in distribution; team must re-examine source systems. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]
Treating the lifecycle as strictly sequential is a recognized anti-pattern. Teams that refuse to revisit earlier phases when evidence demands it produce analyses that are technically complete but practically useless [Source 1, Source 5]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#4-the-iterative-nature-of-the-lifecycle]

5. Cross-cutting concerns

These concerns apply across all phases rather than belonging to a single one: [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#5-cross-cutting-concerns]

Documentation and provenance

Every transformation applied to data should be recorded so that findings can be reproduced and audited. Missing metadata about data origins is one of the top causes of unreproducible analyses [Source 6]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#documentation-and-provenance]

Stakeholder alignment

Checkpoints between phases - presenting phase outputs to stakeholders before proceeding - catch misalignment early. The cost of rework grows with each phase completed before a mismatch is surfaced. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#stakeholder-alignment]

Team roles

In TDSP, roles are explicitly assigned: project lead, data scientist, data engineer, solution architect, and business analyst each own specific deliverables. In smaller teams one person covers multiple roles, but the responsibilities remain distinct [Source 5]. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#team-roles]

Governance and ethics

Data collection and use must comply with applicable regulations (GDPR, HIPAA, etc.) and internal data governance policies. These checks are easiest to apply at phase transitions, not after deployment. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#governance-and-ethics]

6. Practical worked example

Scenario: a retail company wants to reduce stockouts. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#6-practical-worked-example]
At evaluation, the team discovers that weather features add noise rather than signal; they loop back to Phase 3, drop those columns, and re-evaluate - a normal iteration, not a failure. [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#6-practical-worked-example]

Sources

"Understanding the data analytics lifecycle from end-to-end," Quadratic HQ. https://www.quadratichq.com/blog/understanding-the-data-analytics-lifecycle-from-end-to-end [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]
"Data Analytics Lifecycle: Phases And Importance," TechCanvass Business Analyst Blog. https://businessanalyst.techcanvass.com/data-analytics-lifecycle-phases/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]
"CRISP-DM Methodology: Industry Standard for Data Mining Processes," Medium / Learning Data. https://medium.com/learning-data/crisp-dm-methodology-industry-standard-for-data-mining-processes-f896b33dc5ce [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]
"6 Phases of Data Analytics Lifecycle Every Data Analyst Should Know," DEV Community / BPB Online. https://dev.to/bpb_online/6-phases-of-data-analytics-lifecycle-every-data-analyst-should-know-1k [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]
"Data Science Life Cycle: CRISP-DM and OSEMN frameworks," Data Rundown. https://datarundown.com/data-science-life-cycle/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]
"Common Pitfalls to Avoid When Analyzing and Modeling Data," freeCodeCamp. https://www.freecodecamp.org/news/common-pitfalls-to-avoid-when-analyzing-and-modeling-data/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]

[archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#sources]

Cross-hub map — where every data-analytics topic lives

This family is split across these hubs. If a task's deep material is not in this hub's Sub-skill routing table, it is a reference file under a sibling hub below - activate that hub or Read its references/<name>.md directly. Every former standalone skill in this family is now a reference under one of these hubs (nothing was deleted). [archived source: https://llms-explorer.com/sources/mdb-context-hub/da-2-data-analysis-lifecycle/#cross-hub-map-where-every-data-analytics-topic-lives]

Where this helps

Structuring a new analytics or data-science project from the outset so it has explicit phases, checkpoints, and stakeholder-alignment gates instead of running as one undifferentiated effort. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Diagnosing why a past project produced findings that couldn't be reproduced or deployed, by checking which lifecycle phase — documentation, evaluation, operationalization — was skipped or rushed. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Choosing among CRISP-DM, the EMC/Big Data Analytics Lifecycle, OSEMN, and TDSP based on whether your project needs an analytic sandbox, explicit team roles, or just a lightweight linear pass. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Planning for concept drift and model staleness after deployment, by building the operationalization phase's monitoring plan in from the start rather than as an afterthought. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

How to apply this

Write an explicit problem statement with measurable success criteria before any data acquisition starts, rather than letting the lifecycle begin from a vague goal. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Budget the majority of project time, cited here as 60-80%, for the data preparation phase rather than treating it as a quick step before the real work of modeling begins. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build feedback loops explicitly into the plan — evaluation back to data preparation, modeling insights back to business understanding — instead of assuming the lifecycle runs once, straight through. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Choose a lifecycle framework to match your project's shape: CRISP-DM for general iterative analytics, the EMC/Big Data lifecycle when an analytic sandbox matters, OSEMN for a lightweight academic pass, or TDSP when explicit team roles and agile cadence matter. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Antipatterns

Treating the lifecycle as strictly linear and refusing to revisit an earlier phase when evidence demands it, producing an analysis that's technically complete but practically useless. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Rushing or skipping the problem-definition phase as a formality, then discovering mid-modeling that the available data can't actually answer the question that mattered. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Trusting that data labeled clean by a source system actually is clean, missing undocumented conventions like sentinel values for missing data that only careful profiling would reveal. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Tuning hyperparameters against many combinations without a genuinely held-out test set, producing strong validation scores that don't reflect real generalization. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Data preparation's 60-80% time share means schedule estimates that don't front-load this phase are likely to be systematically wrong, and the lifecycle itself doesn't fix that estimation problem. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
A model can pass the statistical-significance bar in the evaluation phase while being too small to matter operationally, and confusing statistical with practical significance is a common evaluation-phase pitfall. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Concept drift after deployment, production data differing from training data, can degrade a model silently without a monitoring and retraining plan. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
The four canonical frameworks differ in real ways — OSEMN in particular omits business framing and deployment — so picking the wrong one for a project's actual needs leaves a real gap uncovered. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

← the whole tree · 3D view· how to read this page