Research synthesis · Architecture recommendation

Developmental Framework Meta-Model

North American research and recommended structure for domains, goals, milestones, skills, performance criteria, and observable capabilities

Decision document Prepared for product, content, clinical-advisory, data, and engineering teams. This document addresses only the developmental knowledge structure. Activity, environment, recommendation, evidence-collection, security, and operational architecture are intentionally out of scope except where needed to explain the taxonomy.

Document status	Research synthesis and architecture recommendation
Date	25 July 2026
Scope	Core developmental framework meta-model only
Important limitation	This is not a clinical instrument, diagnosis, or substitute for licensing a validated screener or assessment.

Research basis: CDC/AAP developmental surveillance, ASQ-3, AEPS-3, Head Start ELOF, Ontario ELECT, Rourke Baby Record, Looksee Checklist, U.S. IDEA Part C, and the team’s Developmental Atoms research draft.

How to read this document

Research finding: what the reviewed framework or source explicitly supports.
Interpretation: what the finding means for a reusable product model.
Recommendation: the proposed internal structure; this is an architecture decision, not an external standard.
Framework mapping: how the proposed internal model can represent a source framework without claiming equivalence of purpose or validity.

1. Executive recommendation

↑ Top

Recommended decision
Adopt a two-axis model. The first axis is a reusable developmental taxonomy: Domain -> optional Subdomain/Strand -> optional Goal -> Skill -> Observable Capability. The second axis is an age- and framework-specific expectation model: Age Band + Milestone Concept -> Milestone Expectation -> Performance Criterion -> Observable Capability. Do not make Milestone the permanent owner of Skill or Observable Capability.

The core research outcome is that North American frameworks agree on broad developmental domains and observable behaviours, but they do not share one universal hierarchy. Surveillance and checklist tools are often flat: age -> domain -> observable milestone or item. Curriculum-based and early-learning frameworks are more hierarchical: domain -> subdomain/strand -> goal/root skill -> objective/indicator. A product that must support several sources, longitudinal content changes, and fine-grained recommendations therefore needs a framework-neutral canonical model plus explicit crosswalks.

Use “Observable Capability” as the formal term for the smallest reusable, parent-observable unit. The engineering shorthand “atom” may remain, but “atom” is not a common North American framework term and can imply false indivisibility or binary certainty.
Keep “Skill” broader than an observable capability. A skill is a reusable developmental capacity that may be evidenced by multiple observable capabilities and may be elaborated over time.
Treat “Goal” as optional and framework-specific. Head Start ELOF and AEPS use goal-like layers; CDC and ASQ do not require one. The canonical model must not force every source into a Goal level.
Treat “Milestone” as age- and framework-contextual. Normalize wording with a Milestone Concept, then store each source- and age-specific Milestone Expectation separately.
Place Performance Criterion between Milestone Expectation and Observable Capability. It expresses how one or more capabilities must be demonstrated in that milestone context: independence, consistency, quality, frequency, assistance, and context.
Avoid strict prerequisite assumptions. Use typed relationships such as hard prerequisite, typical precursor, supporting, composition component, and related. Only rare expert-reviewed hard prerequisites should support automatic inference.
Do not store a child’s capability as a simple universal yes/no fact. A parent interface may be simple, but the system should distinguish unknown, not yet, emerging, demonstrated, inferred, stale, and conflicting evidence.

Recommended conceptual structure

Reusable taxonomy axis:
Domain -> Subdomain/Strand -> Goal -> Skill <-> Observable Capability

Age/framework expectation axis:
Age Band + Milestone Concept -> Milestone Expectation -> Performance Criterion <-> Observable Capability

Source preservation axis:
Framework Version -> Framework Node hierarchy -> Crosswalk Mapping -> Canonical concepts

Recommended two-axis developmental framework meta-model diagram

Figure 1. Recommended two-axis developmental meta-model.

2. Why the terminology is confusing

↑ Top

The same word is used at different levels in different disciplines. For example, CDC calls an observable behaviour such as taking a first step a “developmental milestone.” Head Start calls a broad expected outcome a “goal” and calls the specific observable behaviours “indicators.” Ontario ELECT calls the broader capacity a “root skill” and the observable markers “indicators.” AEPS uses areas, strands, goals, objectives, and item criteria. ASQ uses age-specific questionnaire items grouped into five areas. These terms cannot be merged by name alone.

Term	Common meanings found in practice	Risk if used without definition
Domain	A broad developmental area; sometimes physical is split into gross and fine motor, and sometimes adaptive/self-help is separate.	A fixed five-domain design may not map one-to-one to every framework.
Goal	A broad expected outcome, intervention target, curriculum outcome, or level in a proprietary assessment hierarchy.	Treating every milestone as a goal or every goal as a skill creates duplicate levels.
Milestone	An age-linked observable behaviour, a parent-facing expectation, or a general developmental achievement independent of exact age.	The same behaviour may appear at different ages or with different wording across frameworks.
Skill	A broad capacity, a specific task, a scored assessment item, or the smallest observable unit.	The team may think Skill is primitive while another source uses Skill as a composite.
Indicator	An observable marker, example behaviour, or age-endpoint expectation.	Indicators may be illustrative rather than exhaustive or diagnostic.
Objective	A smaller component of a goal, an intervention objective, or an assessment item.	Objectives can be confused with product goals or parent-selected goals.
Performance Criterion	The conditions under which performance qualifies: accuracy, independence, consistency, duration, context, assistance, or quality.	Without it, “has the skill” becomes vague and unrepeatable.
Atom	Internal shorthand for the smallest observable capability.	Not a common formal framework term; may overstate binary certainty and irreducibility.

Terminology policy Every term in the product ontology should have one formal definition, a stable code, a stated granularity, and a mapping to external framework terminology. External source wording should be preserved rather than silently translated into the internal vocabulary.

3. Research approach and boundaries

↑ Top

3.1 Frameworks reviewed

CDC Learn the Signs. Act Early developmental milestone checklists and the AAP-led 2022 milestone revision criteria.
American Academy of Pediatrics guidance on developmental surveillance and standardized screening.
ASQ-3, a parent-completed standardized developmental screener.
AEPS-3, a criterion-referenced curriculum-based assessment and intervention system.
Head Start Early Learning Outcomes Framework (ELOF).
Ontario Early Learning for Every Child Today (ELECT) Continuum of Development.
Rourke Baby Record, a Canadian evidence-based well-child surveillance guide.
Looksee Checklist, a Canadian parent-friendly developmental monitoring tool.
U.S. IDEA Part C developmental areas for early intervention.
The team’s uploaded “Developmental Atoms — Skill Decomposition Framework.”

3.2 Why these sources are not interchangeable

Purpose category	Typical question answered	Structural consequence
Developmental surveillance	What observable signs should prompt discussion or further action over time?	Age-linked, parent-friendly milestones; broad domains; intentionally not a diagnosis.
Standardized screening	Is the child at elevated risk and should further evaluation be considered?	Fixed age forms, standardized items, scoring rules, cutoffs, reliability and validity requirements.
Criterion-referenced assessment	What can the child currently do, what is emerging, and what should be taught next?	Goals, objectives, criteria, developmental sequences, richer states, and links to intervention.
Early-learning outcomes framework	What broad learning and developmental outcomes should programs support?	Domains, subdomains, goals, progressions, and observable indicators; not necessarily an assessment.
Clinical well-child record	Which developmental behaviours and concerns should be reviewed during age-specific visits?	Compact visit-age lists, domain order, parent concern, and follow-up guidance.
Product readiness ontology	What reusable capabilities can be tracked and combined safely by software?	Fine-grained canonical capabilities, mappings, typed dependencies, versioning, and explainability.

Boundary: This document compares meta-structures, not the clinical validity of individual milestone statements. Commercial tools such as ASQ-3 and AEPS-3 are proprietary. Structural comparison does not grant permission to reproduce their items, scoring, cutoffs, wording, or copyrighted hierarchy.

4. Findings from major North American frameworks

↑ Top

4.1 CDC/AAP developmental surveillance

Research finding. CDC presents milestones by age and groups them into broad areas describing how children play, learn, speak, act, and move. The AAP-led 2022 revision established criteria that milestones should be readily observable in natural settings and generally placed at ages by which at least 75% of children would be expected to demonstrate them. CDC checklists are developmental-surveillance resources rather than validated screening instruments. [1][2][3]

Age checkpoint
└── Domain
└── Observable milestone statement

Structural strength: simple, parent-readable, age-indexed, and suitable for surveillance conversations.
Structural limitation: there is no explicit reusable Skill or Goal hierarchy beneath a milestone.
Implication for the product: CDC-like milestone wording should map to canonical capabilities but should not define the whole internal taxonomy.

4.2 ASQ-3 developmental screening

Research finding. ASQ-3 is a standardized parent-completed screener for ages 1–66 months. It uses 21 age-interval questionnaires and five areas: communication, gross motor, fine motor, problem solving, and personal-social. Each form contains concrete observable items and produces domain-level screening results. [4]

Questionnaire interval
└── Screening area/domain
└── Observable item/question
└── Standardized response and domain score

Structural strength: age-specific item sets, parent usability, standardized scoring, and domain summaries.
Structural limitation: the public structure is an instrument structure, not a reusable capability ontology.
Implication for the product: a questionnaire item should be modelled as evidence for one or more performance criteria or capabilities, not as the permanent definition of a capability.
Licensing implication: do not reproduce ASQ content or scoring without appropriate rights.

4.3 AEPS-3 curriculum-based assessment

Research finding. AEPS-3 is a criterion-referenced, curriculum-based system spanning birth to six years. It organizes content as Areas, Strands, Goals, and Objectives, with criteria for goals and objectives. It links assessment to goal development, intervention, routines, activities, and progress monitoring. AEPS also describes developmental sequences and foundation steps, while recognizing that a child’s developmental level—not age alone—should determine where teaching begins. [5]

Area
└── Strand
└── Goal
└── Objective
└── Item criterion / performance evidence

Structural strength: closest precedent for a layered skill model connected to criteria and intervention.
Structural limitation: commercial and proprietary; its exact hierarchy and content cannot simply become the product ontology.
Implication for the product: supports distinguishing broader Skill/Goal from smaller observable capability and from performance criterion.
Important caution: developmental sequence is useful, but it does not mean every child follows one universal path.

4.4 Head Start Early Learning Outcomes Framework

Research finding. Head Start ELOF uses central Domains, Subdomains, Goals, Developmental Progressions, and Indicators. Goals are broad expectations. Developmental progressions describe skills, behaviours, and concepts that emerge as children move toward a goal. Indicators are specific observable skills, behaviours, and concepts at key ages, but are not exhaustive. ELOF explicitly states that it is not a curriculum, assessment, or checklist and should not be used to conclude that a child failed. [6]

Central Domain
└── Subdomain
└── Goal
└── Developmental Progression
└── Indicator

Structural strength: clear separation between broad goals, developmental trajectories, and observable indicators.
Structural limitation: indicators occur at selected endpoints and are illustrative rather than a complete item bank.
Implication for the product: Goal and Progression should be optional framework-specific constructs; Observable Capability can map to Indicator.

4.5 Ontario ELECT Continuum of Development

Research finding. ELECT organizes development into five interrelated domains and describes Root Skills and their Indicators. Root skills are capacities, processes, abilities, and competencies within a domain. Indicators are markers showing that a skill is emerging, being practised, or being elaborated. Interactions describe experiences that support development. ELECT explicitly says the continuum is not an assessment or screening tool and is not a locked universal timetable. [7]

Age range
└── Domain
└── Root Skill
└── Indicators
└── Supporting interactions

Structural strength: very close conceptual support for Domain -> Skill -> Observable Indicator.
Structural limitation: the continuum is pedagogical and observational, not a validated screener.
Implication for the product: supports keeping Skill broader than Atom/Observable Capability and modelling developmental states beyond a hard binary.

4.6 Rourke Baby Record

Research finding. The 2024 Rourke Baby Record lists age-specific milestone tasks in a consistent order: gross motor, fine motor, communication, cognitive, and social-emotional. Tasks are placed after typical milestone acquisition, and absence, loss of attained milestones, or parental concern warrants further assessment. It also notes that parent familiarity with particular milestones can be culturally dependent. [8]

Well-child visit age
└── Five-domain milestone list
└── Inquiry / observation / concern and follow-up

Structural strength: strong Canadian precedent for the team’s current five-domain grouping.
Structural limitation: compact clinical surveillance list; no explicit skill or atom hierarchy.
Implication for the product: current five domains are defensible, but adaptive/self-help still requires deliberate placement.

4.7 Looksee Checklist

Research finding. Looksee uses short age-specific yes/no questions, no scoring, and parent tips. It covers emotional, fine motor, gross motor, social, self-help, communication, learning and thinking, and vision and hearing. It is positioned as monitoring and conversation support rather than diagnosis. [9]

Age checklist
└── Observable yes/no question
├── Development area marker
└── Tip or activity

Structural strength: simple parent interaction, explicit self-help and sensory areas, and linkage to developmental support.
Structural limitation: a yes/no item is a collection format, not necessarily the complete internal state or ontology.
Implication for the product: simple parent-facing responses can sit on top of a richer capability state model.

4.8 U.S. IDEA Part C

Research finding. IDEA Part C identifies five broad developmental areas for infants and toddlers: physical, cognitive, communication, social or emotional, and adaptive development. Physical development includes vision and hearing in the implementing regulation. [10]

Structural strength: widely recognized U.S. early-intervention domain structure and clear recognition of adaptive development.
Structural limitation: a legal service-eligibility framework, not a content hierarchy or item model.
Implication for the product: the fixed five-domain design should account for adaptive/self-help and cross-domain sensory functions even if the user-facing domain labels remain different.

4.9 Team Developmental Atoms research draft

Source-derived finding. The team draft defines an atom as the smallest testable, observable skill unit; assigns a domain and typical emergence range; provides an observable indicator; and creates prerequisite-atom links. It proposes using a child’s atom inventory for activity eligibility and applies a split guardrail: split only when combining two capabilities could lead to unsafe or frustrating recommendations. [11]

Structural strength: operational precision, reusable capability codes, machine-readable readiness, and a disciplined guardrail against unnecessary granularity.
Structural weakness: the list mixes true atomic behaviours, composite outcomes, thresholds, and broad functional achievements.
State-model weakness: strict binary “has/does not have” status discards unknown, inconsistent, assisted, emerging, inferred, and conflicting evidence.
Dependency weakness: many “prerequisites” are common developmental sequences rather than logically necessary prerequisites.
Terminology implication: retain “atom” as an internal shorthand if useful, but make Observable Capability the formal concept and assign a granularity type.

5. Cross-framework comparison

↑ Top

Framework	Primary purpose	Typical hierarchy	Smallest visible unit	State / scoring approach
CDC/AAP milestones	Developmental surveillance	Age -> domain -> milestone	Observable milestone behaviour	Parent monitoring; not a standardized score
ASQ-3	Standardized screening	Age questionnaire -> area -> item	Observable item/question	Standardized responses and domain cutoffs
AEPS-3	Criterion-referenced assessment and intervention	Area -> strand -> goal -> objective -> criterion	Objective/item with criterion; foundation steps	Mastery, emerging variations, no performance
Head Start ELOF	Early-learning outcomes framework	Domain -> subdomain -> goal -> progression -> indicator	Observable indicator	Descriptive progression; not an assessment
Ontario ELECT	Observation and curriculum planning	Age range -> domain -> root skill -> indicator -> interaction	Observable indicator	Emerging, practising, elaborating; not screening
Rourke Baby Record	Clinical developmental surveillance	Visit age -> five-domain milestone list	Milestone task	Inquiry/observation and concern
Looksee	Parent monitoring and conversation	Age checklist -> item + area marker	Yes/no observable question	No score; yes/no and follow-up
IDEA Part C	Early-intervention legal/service framework	Developmental area	Not specified	Appropriate diagnostic instruments and procedures
Team atom draft	Product capability and readiness ontology	Domain -> atom + prerequisites	Atom	Proposed binary inventory

5.1 What is genuinely common

Broad developmental domains are universal, although naming and grouping differ.
Observable behaviours are the most common lowest-level representation.
Age is central to surveillance and screening, but less central to criterion-referenced teaching sequences.
Broader skills or goals appear in curriculum-oriented frameworks more often than in parent checklists.
Naturalistic observation and caregiver knowledge are widely used, but standardized screening requires controlled content and scoring.
Development is treated as variable and interrelated; credible frameworks avoid claiming one rigid path for every child.
No reviewed framework uses “atom” as a formal universal standard term.

6. Common structural patterns and research outcomes

↑ Top

6.1 The most defensible common meta-structure

Framework / Version
├── Age Period or Age Band
└── Domain
└── optional Subdomain / Strand
└── optional Goal / Root Skill / Outcome
└── observable Indicator / Objective / Item

Research outcome. This is the closest common denominator across the major frameworks, but it is a meta-structure rather than a standard mandated hierarchy. Some frameworks skip Goal or Subdomain. Others use a progression layer. Therefore, the internal model must support optional levels and many-to-many mappings rather than assuming a single rigid tree.

6.2 Two different questions must not be collapsed

Question	Best structural axis	Why it matters
What developmental capacity is this?	Domain -> Skill -> Observable Capability	Creates a reusable, age-independent knowledge graph.
What is expected at this age in this framework?	Age Band + Milestone Expectation -> Performance Criterion -> Capability	Preserves source-specific timing, wording, and interpretation.
How does this source organize content?	Framework Node hierarchy	Preserves the original framework without forcing its terms into the canonical model.

6.3 Milestone is not a permanent parent of skill

A reusable capability can contribute to many milestones. For example, intentional release may contribute to putting an object in a container, stacking, throwing, cleanup routines, and shape-sorting. If the capability is stored as a child of one milestone, it will be duplicated or incorrectly owned. Milestone-to-capability must therefore be many-to-many through criteria.

6.4 Goal is useful but optional

Use Goal when: a source framework explicitly defines a broad developmental outcome, a program needs goal-based reporting, or multiple skills jointly serve a meaningful outcome.
Do not require Goal when: the source is a flat surveillance checklist, an age-form screener, or a capability does not need an additional grouping level.
Recommended treatment: Goal is a framework-aware grouping/outcome entity, not a synonym for Milestone, Skill, or parent-selected objective.

6.5 Observable Capability is the safest formal replacement for Atom

Choice	Advantages	Disadvantages
Use Atom as the formal entity	Short, engineering-friendly, highlights decomposition.	Not standard terminology; implies indivisibility; may encourage binary state and over-splitting; awkward with clinicians and educators.
Use Skill for both broad and atomic levels	Simple schema and fewer entities.	Ambiguous granularity; difficult to map ELOF goals, ELECT root skills, AEPS objectives, and atom readiness cleanly.
Use Skill + Observable Capability (recommended)	Matches curriculum frameworks; supports reusable capability-level evidence; understandable to product and clinical stakeholders.	Requires explicit Skill–Capability mappings and governance of granularity.

7. Evaluation of the team’s current structure

↑ Top

7.1 Current proposal as understood

Five predefined Domains
└── age-group Milestones
└── Skills
└── Atoms / smallest capabilities

Milestone–Skill mappings carry Performance Criteria in milestone context.
Milestones and atoms may have dependency relationships.

What is already correct The current design correctly separates broad domains, age-specific milestone expectations, reusable capabilities, and context-specific performance criteria. It also correctly anticipates many-to-many mappings and versioning needs.

7.2 Where the current model aligns with frameworks

Current concept	Closest framework analogues	Assessment
Five Domains	ASQ-3 and Rourke five-area structures; IDEA five broad areas; ELOF and ELECT five central domains	Strongly defensible, but domain naming differs.
Milestones by age band	CDC, Rourke, Looksee, ASQ interval items	Common and understandable for surveillance/monitoring.
Skill layer	ELECT root skill; AEPS goal; ELOF goal or progression-level capacity	Useful if defined as broader reusable ability.
Atom layer	ELOF indicator; ELECT indicator; AEPS objective/foundation step; ASQ/CDC observable item	Useful if formalized as Observable Capability and not assumed universally binary.
Performance Criterion	AEPS item criteria; explicit operational definition beneath an assessment item	Important and should remain milestone-contextual.
Dependencies	AEPS developmental sequences/foundation steps; ELOF progressions; ELECT trajectories	Useful only when typed and governed; not all sequences are hard prerequisites.

7.3 Problems with a strict Milestone -> Skill -> Atom tree

Ownership error: a skill or atom belongs to many milestones and should not be owned by one milestone.
Age contamination: milestone age changes can force changes in otherwise stable skills and capabilities.
Framework conflict: the same capability can appear at different ages, domains, or wording in different sources.
Duplicate concepts: the same atom may be recreated under several milestone branches.
Transitive relationship clutter: direct Milestone->Atom links may duplicate Milestone->Skill->Atom unless the direct relationship carries distinct criteria.
Cross-domain difficulty: some capabilities support more than one domain or goal.
Circularity risk: if skills contain atoms while atoms depend on skills or milestones depend on one another, the graph can become semantically circular.
Granularity drift: some “atoms” are actually composites or thresholds, while some “skills” may be as narrow as an atom.

7.4 Acceptable version of Milestone -> Skill -> Atom

The hierarchy is acceptable only as a presentation or navigation view, not as the ownership model. It can be generated from mappings when Skill means a broader capability and Atom means an observable component. The underlying relationships should remain many-to-many.

Milestone Expectation
└── Performance Criteria
└── Observable Capabilities
└── roll up to one or more Skills

Presentation may show: Milestone -> Skill -> Atom
System of record stores: Milestone <-> Criterion <-> Capability <-> Skill

8. Recommended canonical meta-model

↑ Top

8.1 Three-layer architecture

Layer	Purpose	Core constructs
Canonical developmental ontology	Stable internal concepts used across sources and versions.	Domain, Subdomain, Skill, Observable Capability, Capability Composition, Capability Dependency
Framework-specific expectation model	Preserves age, wording, hierarchy, and intended use of each source.	Framework Version, Age Band, Goal, Milestone Concept, Milestone Expectation, Performance Criterion, Progression Step
Crosswalk and provenance	Maps external nodes to canonical concepts without pretending exact equivalence.	Framework Node, Node Type, Concept Mapping, relationship type, confidence, review status, source reference

8.2 Recommended core hierarchy

Canonical taxonomy
Domain 1:M Subdomain
Subdomain M:N Skill
Goal M:N Skill [Goal is optional/framework-aware]
Skill M:N Observable Capability
Observable Capability M:N Domain [primary/supporting cross-domain mappings]

Age/framework expectations
Milestone Concept 1:M Milestone Expectation
Age Band 1:M Milestone Expectation
Framework Version 1:M Milestone Expectation
Milestone Expectation 1:M Performance Criterion
Performance Criterion M:N Observable Capability

Key design principle A Skill is a reusable developmental capacity. An Observable Capability is a specific observable behaviour that provides evidence of one or more skills. A Milestone Expectation says that a framework expects a defined behaviour at an age or age band. A Performance Criterion says exactly what counts in that milestone context.

8.3 Why Milestone Concept and Milestone Expectation are separate

Milestone Concept: normalizes the underlying developmental behaviour independent of wording, age, or source.
Milestone Expectation: stores a framework-specific statement, age band, domain placement, prevalence or threshold interpretation, source wording, and version.
Benefit: two frameworks can refer to the same concept at different ages or with different wording without duplicating the child-development concept.
Benefit: source wording can be retired or revised while historical evaluations remain traceable.

8.4 Why Performance Criterion is an association entity

A capability’s required performance depends on the milestone context. For example, “produces recognizable words” may support naming an object, requesting help, combining two words, or participating in a short exchange. The independence, spontaneity, frequency, communicative intent, context, and required number of examples can differ. Therefore, criterion data belongs between Milestone Expectation and Capability rather than solely on Skill or Capability.

9. Detailed definitions of the recommended concepts

↑ Top

Concept	Definition	System use	Relationship summary
Framework	Named external or internal developmental system.	Identifies ownership, purpose, licensing, jurisdiction, and source lineage.	One framework has many immutable versions.
Framework Version	A published snapshot of framework content and hierarchy.	Prevents later revisions from rewriting historical mappings or interpretations.	Owns age bands, framework nodes, goals, milestone expectations, and mappings.
Domain	Broad developmental area used for organization and reporting.	Supports the team’s five-domain experience while allowing external crosswalks.	May have subdomains; capabilities can map to multiple domains with one primary role.
Subdomain / Strand	Optional component or category within a domain.	Maps structures such as Head Start subdomains and AEPS strands without forcing them into Skill.	Usually belongs to one domain within a framework; may map to canonical skill families.
Developmental Goal	Broad framework-specific statement of an expected outcome or direction of growth.	Represents ELOF goals and AEPS goals; supports reporting and program planning.	Optional; can map to multiple skills and capabilities.
Skill	Reusable developmental capacity, process, ability, or competency that can become more sophisticated over time.	Provides a stable level above specific behaviours and supports understandable summaries.	Many-to-many with capabilities, goals, and domains.
Observable Capability	Specific parent- or practitioner-observable behaviour used as evidence. Formal replacement for “atom.”	Supports precise evidence mapping, readiness checks, and cross-framework crosswalks.	Can support multiple skills, milestones, and domains; may be atomic, composite, threshold, or observable outcome.
Milestone Concept	Normalized developmental achievement independent of source wording and exact age placement.	Deduplicates equivalent milestones and supports comparison across frameworks.	One concept can have many framework-specific expectations.
Milestone Expectation	A framework- and age-specific statement about a milestone concept.	Stores source wording, age band, domain, intended purpose, version, and provenance.	Has one or more performance criteria; maps to one concept and age band.
Performance Criterion	Operational conditions for judging whether a milestone-related behaviour is demonstrated.	Defines assistance, independence, quality, accuracy, frequency, duration, consistency, and context.	Belongs to one milestone expectation and maps to one or more capabilities.
Developmental Progression	Framework-specific description of how skills, behaviours, or concepts become more advanced toward a goal.	Represents ELOF progression and similar structures without making every step a milestone.	Contains ordered progression steps; may map to skills and capabilities.
Progression Step	An ordered stage within a developmental progression.	Preserves source trajectories and supports interpretation without asserting universal prerequisites.	Maps to one or more capabilities; order is framework-specific.
Capability Composition	Part-whole relationship in which a composite capability consists of component capabilities.	Separates “is made of” from “usually comes before.”	Many-to-many self-association with component role and required/optional flag.
Capability Dependency	Typed developmental relationship between capabilities.	Supports hard prerequisites, typical precursors, supporting relationships, and common sequences.	Many-to-many directed self-association; hard-prerequisite subset must be acyclic.
Framework Node	Generic source-preservation node such as domain, subdomain, goal, objective, item, indicator, or progression.	Allows import of frameworks whose levels do not match the canonical model.	Forms a source hierarchy and maps to canonical concepts.
Concept Mapping	Crosswalk from a framework node to a canonical concept.	Records exact, broader, narrower, partial, or related mappings with confidence and review status.	Many-to-many; never silently overwrites source content.

9.1 Domain

Domain is the highest stable developmental grouping. It should be reference data rather than a hard-coded application enumeration, even when the product currently exposes exactly five domains. This enables localization, source crosswalks, display changes, and future reporting without changing child evidence.

Advantages	Risks / disadvantages
• Widely understood across clinical, screening, and education frameworks. • Useful navigation and reporting level. • Supports team’s fixed five-domain decision.	• Domain boundaries vary substantially. • Cross-domain capabilities can be misclassified if only one domain is allowed. • Adaptive/self-help may be lost in a gross/fine/language/cognitive/social-emotional model.

9.2 Developmental Goal

Goal is a broad direction or expected outcome. It should usually be scoped to a framework version because the meaning and level of a goal differ across AEPS, ELOF, intervention plans, and product objectives. Goal should not be required for flat checklists.

Advantages	Risks / disadvantages
• Maps hierarchical educational and criterion-referenced frameworks. • Provides understandable broad outcomes for teams and reports. • Can organize multiple related skills.	• Can duplicate Skill if not governed. • Can be confused with parent-selected goals or treatment goals. • Not present in all frameworks.

9.3 Skill

Skill is a reusable developmental capacity that is broader than one observable behaviour. It may persist across ages and become more complex. A skill is not inherently tied to one milestone, age band, or questionnaire item.

Advantages	Risks / disadvantages
• Stable reusable taxonomy. • Supports parent-friendly and professional summaries. • Maps well to ELECT root skills and broader AEPS/ELOF constructs.	• Requires governance to prevent it from becoming too broad or too atomic. • May overlap domains. • Cannot by itself define exactly what counted as performance.

9.4 Observable Capability / Atom

Observable Capability is a specific behaviour that can be recognized in context. It is the recommended formal name for the team’s atom concept. Add granularity_type or is_atomic because some submitted atoms are composites, thresholds, or broad functional outcomes.

Advantages	Risks / disadvantages
• Excellent for evidence mapping and machine reasoning. • Reusable across milestones and skills. • Supports precise decomposition and duplicate detection.	• Over-decomposition increases maintenance and parent-question burden. • Strict binary interpretation ignores context and uncertainty. • “Atom” may be misleading for composites and thresholds.

9.5 Milestone Concept

Milestone Concept represents the normalized achievement, such as combining words meaningfully, without assigning a particular age, source wording, or domain placement.

Advantages	Risks / disadvantages
• Deduplicates source variants. • Supports cross-framework comparison. • Keeps age changes out of the stable concept.	• Requires expert crosswalk decisions. • Some source statements overlap only partially rather than exactly.

9.6 Milestone Expectation

Milestone Expectation is the operational source statement: a milestone concept as expressed by a framework at an age or age band, with source wording and intended use.

Advantages	Risks / disadvantages
• Preserves provenance and age context. • Supports multiple frameworks and versions. • Avoids rewriting history.	• More entities than a simple milestone table. • Requires careful distinction between surveillance, screening, and curriculum expectations.

9.7 Performance Criterion

Performance Criterion defines the conditions under which evidence supports a milestone expectation. It can specify independence, assistance, context, frequency, duration, accuracy, consistency, quality, and evidence window.

Advantages	Risks / disadvantages
• Makes evaluation explainable and repeatable. • Allows the same capability to be used differently in different milestones. • Maps naturally to criterion-referenced approaches.	• Content-authoring burden is significant. • Criteria can create false precision without evidence or expert review. • Not every parent-facing framework publishes explicit criteria.

10. Relationship and cardinality recommendations

↑ Top

Relationship	Cardinality	Required?	Reason / rule
Framework -> Framework Version	1:M	Yes	Framework content changes over time; published versions should be immutable.
Framework Version -> Framework Node	1:M	Yes for imported sources	Preserves source hierarchy exactly.
Framework Node -> Framework Node	1:M parent-child	Optional	Represents arbitrary source levels without forcing them into canonical tables.
Domain -> Subdomain	1:M within a framework	Optional	Some frameworks have subdomains or strands; others do not.
Subdomain -> Goal	1:M or M:N	Optional	Framework-specific; use association if goals cross subdomains.
Goal <-> Skill	M:N	Optional	A goal may require several skills, and a skill may serve several goals.
Skill <-> Observable Capability	M:N	Yes when both levels are used	A skill has multiple indicators; a capability can evidence multiple skills.
Capability <-> Domain	M:N	Yes	Cross-domain capabilities require primary/supporting role rather than a single forced domain.
Milestone Concept -> Milestone Expectation	1:M	Yes	Same concept can have source- and age-specific expectations.
Age Band -> Milestone Expectation	1:M	Yes	Expectation is anchored to an age period within a framework.
Milestone Expectation -> Performance Criterion	1:M	Recommended	A milestone may require several distinct criteria.
Performance Criterion <-> Observable Capability	M:N	Yes	A criterion may require several capabilities; a capability can serve many criteria.
Goal -> Developmental Progression	1:M	Optional	Needed for ELOF-like source preservation.
Progression -> Progression Step	1:M ordered	Optional	Represents source-described developmental trajectory.
Progression Step <-> Capability	M:N	Optional	A step may be evidenced by multiple behaviours.
Capability <-> Capability through Composition	M:N directed	Optional	Represents part-whole decomposition.
Capability <-> Capability through Dependency	M:N directed	Optional	Represents developmental relation, not ownership.
Framework Node <-> Canonical Concept	M:N	Yes for crosswalk	A source node may partially overlap several canonical concepts and vice versa.

10.1 Avoiding duplicate transitive relationships

No redundant edge rule Do not add a direct relationship merely because a transitive path exists. Add a direct edge only when it carries different business semantics, provenance, criteria, role, weighting, or source-specific meaning.

Candidate direct relationship	Default decision	Exception that justifies it
Milestone Expectation <-> Skill	Usually derive through Criterion -> Capability -> Skill.	Keep a direct editorial/reporting classification only if it carries a distinct role such as primary reported skill.
Milestone Expectation <-> Capability	Usually derive through Performance Criterion.	Direct mapping is acceptable only for a framework that publishes a flat item with no separate criterion; treat the item itself as the criterion.
Goal <-> Capability	Usually derive through Goal <-> Skill <-> Capability.	Keep if the source explicitly maps an indicator directly to a goal and the mapping has source provenance.
Domain <-> Milestone Expectation	Useful as source placement.	Do not treat it as proof that every underlying capability belongs exclusively to that domain.
Skill <-> Skill dependency and Capability <-> Capability dependency	Use one level per relationship meaning.	Both can exist only when one relates broad skill development and the other relates specific observable prerequisites.

11. Dependency, composition, and progression rules

↑ Top

11.1 Do not call every earlier behaviour a prerequisite

Research outcome. ELECT explicitly states that developmental trajectories are not locked universal timetables. Head Start notes individual differences and that indicators are not exhaustive. AEPS uses developmental sequences and foundation steps but also emphasizes starting from the child’s developmental level and recognizes that sequences are appropriate for most, not all, children. Therefore, dependency type must be explicit. [5][6][7]

Relationship type	Meaning	Inference policy
HARD_PREREQUISITE	The successor cannot reasonably be demonstrated without the predecessor capability.	Forward inference may be allowed only after expert review. Must be acyclic.
TYPICAL_PRECURSOR	Commonly emerges earlier and may support the successor.	Do not infer achievement automatically; use for follow-up and ranking.
SUPPORTING	Contributes to performance but is not mandatory.	No automatic state inference.
COMMON_SEQUENCE	Source describes an ordered developmental progression.	Preserve source order; do not claim universal necessity.
COMPOSITION_COMPONENT	The parent capability is made up of component capabilities.	Can derive composite status using explicit rules, not developmental timing.
RELATED	Semantically connected without causal or ordering claim.	No inference.
CONTRAINDICATING / CONFLICTING	Evidence for one interpretation conflicts with another.	Flag for review; no automatic negative conclusion.

11.2 Composition is not dependency

Composition example:
DRESS_FULLY_INDEPENDENT
├── PUT_ON_LOOSE_CLOTHING
├── BUTTON_DO_UP
├── ZIPPER_USE
└── SNAP_USE

Dependency example:
REACH_AND_GRASP --typical precursor--> TRANSFER_HAND_TO_HAND

The first relationship defines what a composite consists of. The second describes a developmental relationship. Combining them into one generic “depends on” link would create incorrect inference and circularity.

11.3 Circularity rules

Hard-prerequisite edges must form a directed acyclic graph.
Composition edges must not allow an entity to contain itself directly or indirectly.
Typical precursor, supporting, and related edges may form cycles, but must never be used as strict evaluation blockers.
Milestone dependencies and capability dependencies must be separate because they operate at different semantic levels.
External framework progressions may contain source order that conflicts with another framework; preserve both rather than merging them into one universal order.
Cross-domain mappings are not cycles and should not be forced into a single-domain tree.

12. State and scoring implications

↑ Top

12.1 Binary parent input versus internal state

The team atom draft proposes binary status. Binary parent prompts can be useful, but binary storage is not adequate for a robust developmental model. North American tools use several patterns: CDC and Looksee support simple monitoring responses; ASQ uses standardized response categories; AEPS distinguishes mastered, emerging, assisted/incomplete, and no performance; ELECT describes emerging, practising, and elaborating. [4][5][7][9][11]

Layer	Recommended representation	Reason
Parent prompt	Yes / Not yet / Not sure, with optional context	Low burden and understandable.
Evidence record	Observed behaviour, assistance, consistency, context, date, source, confidence	Preserves what actually happened.
Capability state	UNKNOWN, REPORTED_NOT_YET, EMERGING, DEMONSTRATED_WITH_SUPPORT, DEMONSTRATED_INDEPENDENTLY, CONSISTENT, INFERRED, CONFLICTING, STALE	Supports uncertainty, variability, inference, and longitudinal change.
Milestone state	Derived from criterion evidence and framework rules	A milestone is a conclusion, not the raw evidence.

12.2 “Not observed” is not “not achieved”

No evidence may mean the parent has not seen the behaviour, the question was not asked, the context was unavailable, or the child did not attempt it.
A negative response must not identify which prerequisite is missing.
An advanced capability may support inference of a truly necessary predecessor, but inferred status must remain distinguishable from parent-reported or directly observed status.
Loss of an attained capability is materially different from “not yet” and should not be hidden by a current boolean flag.

12.3 Performance Criteria should not create false clinical precision

Criteria are necessary for consistent system interpretation, but their thresholds must be source-backed or expert-governed. A criterion such as “three times in two settings without prompting” sounds precise but may be arbitrary unless supported by the intended framework. The data model should support precision; content governance must decide when precision is warranted.

13. Mapping the recommended model to each framework

↑ Top

Recommended concept	CDC/AAP	ASQ-3	AEPS-3	Head Start ELOF	Ontario ELECT
Domain	Milestone category/domain	Area/subscale	Area	Central domain	Domain
Subdomain / Strand	Usually absent	Usually absent publicly	Strand	Subdomain	May be implicit in skill grouping
Goal	Usually absent	Absent as public hierarchy	Goal	Goal	Closest to broad root-skill grouping, but not exact
Skill	Derived grouping, not explicit	Derived grouping, not explicit	Goal or broader objective grouping depending granularity	Goal/progression-level capacity	Root skill
Observable Capability	Milestone behaviour	Questionnaire item behaviour	Objective, foundation step, or observable item	Indicator or progression behaviour	Indicator
Milestone Concept	Normalized CDC behaviour	Normalized item behaviour if used	Optional normalized achievement	Optional normalized indicator/goal outcome	Optional normalized indicator
Milestone Expectation	Age-specific milestone statement	Age-interval item expectation	Framework item/criterion at developmental sequence position	Age-period progression or indicator expectation	Age-range skill/indicator placement
Performance Criterion	Usually implicit in wording/video	Embedded in standardized item instructions and scoring	Explicit item criterion	Usually descriptive, not formal scoring criterion	Observable indicator description; not formal assessment criterion
Progression Step	Age sequence across checklists	Item difficulty/age sequence implicit	Developmental sequence/foundation steps	Explicit developmental progression	Continuum trajectory
State	Monitoring response	Standardized response and score	Mastered/emerging/no performance variants	Descriptive, not assessment	Emerging/practising/elaborating

Recommended concept	Rourke	Looksee	IDEA Part C	Team current model / atom draft
Domain	Gross motor, fine motor, communication, cognitive, social-emotional	Eight areas including self-help and vision/hearing	Physical, cognitive, communication, social/emotional, adaptive	Five predefined domains
Subdomain / Strand	Absent	Absent	Absent	Not currently firm; recommended optional
Goal	Absent	Absent	IFSP goal is a different operational concept	Not yet clear; recommended optional/framework-specific
Skill	Implicit	Implicit	Developmental need/functional capacity	Proposed primitive entity; should become broader reusable capacity
Observable Capability	Milestone task	Yes/no question behaviour	Evidence from appropriate procedures	Atom
Milestone Expectation	Visit-age milestone task	Age checklist item	Not defined as content structure	Milestone by month range
Performance Criterion	Mostly embedded in wording	Clarifications/examples	Defined by assessment instruments, not statute	Explicit milestone-context skill performance criteria
State	Achieved/missing/lost/concern	Yes/no; no score	Determined through appropriate instruments/procedures	Proposed binary atom inventory plus calculated milestone/skill state

13.1 Mapping does not imply equivalence

A crosswalk means “this source node is related to this canonical concept,” not “the two frameworks are interchangeable.” Mappings should record exact, broader, narrower, partial-overlap, related, or no-match status. A standardized screening item must not inherit validity merely because it maps to the same observable capability as a public milestone or internal atom.

14. Options, pros, cons, and final decision

↑ Top

Option	Structure	Advantages	Disadvantages	Recommendation
A. Milestone owns Skill owns Atom	Milestone -> Skill -> Atom tree	Easy to explain and browse; resembles a curriculum outline.	Duplicates reusable concepts; age/source ownership problem; poor cross-framework mapping; circularity and transitive-edge risk.	Do not use as system of record. May be a generated presentation view.
B. Skill equals Atom	Milestone <-> Skill/Capability	Simplest schema; matches flat surveillance/checklist tools.	Loses broader skill layer; weak mapping to AEPS/ELOF/ELECT; reporting becomes overly granular.	Acceptable for a narrow MVP, but limits future framework mapping.
C. Separate Skill and Observable Capability	Domain -> Skill <-> Capability; Milestone -> Criterion <-> Capability	Best cross-framework fit; reusable concepts; precise criteria; supports goal/progression layers.	More mappings and governance; needs clear definitions.	Recommended canonical model.
D. Generic framework-node graph only	Node(parent, type) + mappings	Maximum flexibility for arbitrary sources.	Weak semantic integrity; harder application logic; ontology becomes opaque.	Use only for source preservation, not as the complete canonical core.
E. Hybrid typed core + generic external nodes	Typed canonical model plus source hierarchy and crosswalks	Preserves source exactly while giving product code stable semantics.	Most sophisticated; requires mapping workflow.	Recommended overall architecture.

Final decision Use Option E: a hybrid architecture. The typed canonical core uses Domain, optional Subdomain, optional Goal, Skill, Observable Capability, Milestone Concept, Milestone Expectation, Performance Criterion, and typed capability relationships. A generic Framework Node hierarchy preserves each external source and maps it to the canonical core.

14.1 Decision on the five domains

The team’s five domains are acceptable and have strong Canadian precedent through Rourke and close alignment with ASQ-3. The unresolved issue is adaptive/self-help. IDEA treats adaptive development as one of five primary areas, while Looksee explicitly includes self-help. If the five user-facing domains remain Gross Motor, Fine Motor, Language/Communication, Cognitive, and Social-Emotional, the canonical model should permit adaptive/self-help skills and capabilities to be cross-domain or placed in an explicit subdomain/skill family. Do not force self-help into one domain merely to satisfy the fixed display taxonomy.

Five-domain strategy	Pros	Cons	Recommendation
Keep Gross Motor + Fine Motor separate; represent Adaptive/Self-Help as cross-cutting	Closest to Rourke/ASQ; minimal team change.	Adaptive reporting is less visible; mappings require cross-domain support.	Practical near-term choice if five domains are fixed.
Combine motor into Physical/Motor; add Adaptive/Self-Help	Closest to IDEA and whole-child functional models.	Changes established team taxonomy; loses immediate gross/fine top-level separation.	Strong alternative for future reconsideration.
Use six domains	Clear and semantically complete.	Violates current five-domain decision and may complicate parent experience.	Not recommended unless the team reopens scope.

15. Implementation and governance rules for the core taxonomy

↑ Top

1. Publish formal definitions and examples for Domain, Goal, Skill, Observable Capability, Milestone Concept, Milestone Expectation, and Performance Criterion.

2. Assign stable codes to canonical concepts; wording and translations may change without changing identity.

3. Version external framework content and internal taxonomy releases. Published versions should be immutable.

4. Preserve source wording, source hierarchy, age placement, intended purpose, and licensing metadata.

5. Use crosswalk mappings with relationship type, confidence, rationale, model version, and human-review status.

6. Do not allow AI-generated mappings to become authoritative without validation and review rules proportionate to impact.

7. Apply an atom-split guardrail: split only when separate tracking changes safety, interpretation, evidence quality, or meaningful recommendation behaviour.

8. Classify capability granularity as ATOMIC, COMPOSITE, THRESHOLD, OBSERVABLE_OUTCOME, or READINESS_INDICATOR.

9. Separate composition, developmental dependency, source progression, and semantic relatedness.

10. Keep hard-prerequisite and composition graphs acyclic; permit cycles only in non-blocking related/supporting networks.

11. Do not create direct transitive relationships unless they carry distinct business meaning or provenance.

12. Allow capabilities and skills to map to multiple domains with primary and supporting roles.

13. Do not equate absence of evidence with absence of the capability.

14. Do not present internal confidence or probability as clinical precision unless the underlying instrument supports it.

15. Do not reproduce proprietary framework content or scoring without rights and implementation guidance.

15.1 Minimum core entity set

Entity	Keep for MVP?	Reason
DevelopmentFramework	Yes	Source ownership and purpose.
FrameworkVersion	Yes	Immutable versioning and provenance.
FrameworkNode + FrameworkNodeType	Yes	Preserves arbitrary source hierarchy.
AgeBand	Yes	Source-specific age placement.
Domain	Yes	Five-domain organization and crosswalk.
Subdomain/Strand	Optional but recommended	Needed for ELOF/AEPS mapping; can be represented initially as framework nodes.
DevelopmentalGoal	Optional but recommended	Needed for goal-based frameworks; not required for every source.
Skill	Yes	Stable broader capacity layer.
ObservableCapability	Yes	Smallest reusable observable unit.
SkillCapability	Yes	Many-to-many mapping and role.
MilestoneConcept	Yes	Normalizes source variants.
MilestoneExpectation	Yes	Age/source-specific statement.
PerformanceCriterion	Yes	Operational meaning in milestone context.
CriterionCapability	Yes	Many-to-many evidence relationship.
CapabilityDependency	Yes	Typed developmental relationships.
CapabilityComposition	Recommended	Separates composite capabilities from prerequisites.
DevelopmentalProgression/Step	Later or framework-node representation	Needed only when the source explicitly publishes progression.
ConceptMapping	Yes	Cross-framework mapping and AI-assisted governance.

Appendix A. Terminology crosswalk

↑ Top

Canonical term	Plain-language meaning	Common source terms that may map here	Terms not automatically equivalent
Domain	Broad area of development	Area, central domain, developmental area	Subscale may be instrument-specific
Subdomain / Strand	Component within a domain	Subdomain, strand, category	Skill family may be broader or narrower
Developmental Goal	Broad expected outcome	Goal, outcome, broad objective	Parent goal, IFSP goal, recommendation goal
Skill	Reusable capacity or ability	Root skill, competency, broader goal/objective	Every questionnaire item; every milestone statement
Observable Capability	Specific behaviour that can be observed	Indicator, objective, item behaviour, foundation step, atom	A score, diagnosis, domain
Milestone Concept	Normalized developmental achievement	Canonical milestone, normalized item concept	Source wording or age expectation
Milestone Expectation	Source- and age-specific milestone statement	CDC milestone, Rourke task, age checklist item	Universal developmental law
Performance Criterion	How performance counts in context	Item criterion, scoring criterion, observable conditions	Raw observation or final score
Developmental Progression	Framework-specific trajectory toward a goal	Progression, sequence, continuum	Hard prerequisite chain
Capability Dependency	Typed relationship among capabilities	Prerequisite, precursor, supporting skill, sequence	Composition unless explicitly typed
Capability Composition	Part-whole decomposition	Component skills, foundation components	Typical developmental order

Appendix B. Example end-to-end decomposition

↑ Top

Illustrative example only. The wording below is created to demonstrate the model and is not copied from a proprietary instrument.

Level	Illustrative record	Why it is separate
Domain	Communication and Language	Broad reporting and navigation area.
Subdomain	Expressive Communication	Groups related capacities within the domain.
Goal	The child increasingly uses language to communicate needs, ideas, and experiences.	Broad framework/program outcome; optional.
Skill	Phrase Construction	Reusable capacity that develops across several milestones and ages.
Observable Capability A	Produces several recognizable words consistently.	Specific observable evidence; reusable.
Observable Capability B	Combines two different words into one meaningful utterance.	Specific observable evidence; reusable.
Observable Capability C	Directs the utterance to another person for a communicative purpose.	Separates communicative intent from word production.
Milestone Concept	Combines words meaningfully.	Normalized achievement independent of age/source.
Milestone Expectation	Framework X, Age Band Y: uses a short word combination to request, label, or comment.	Source- and age-specific expectation.
Performance Criterion 1	At least two recognizable words occur in the same utterance.	Defines the required word-combination performance.
Performance Criterion 2	The words express a meaningful relation rather than simple repetition.	Defines quality/meaning.
Performance Criterion 3	The utterance is spontaneous or not merely an immediate exact imitation.	Defines prompting/independence.
Criterion–Capability mapping	Criteria map to capabilities A, B, and C with required/supporting roles.	Creates many-to-many evidence logic without making the milestone own the capabilities.

Domain: Communication and Language
└── Skill: Phrase Construction
├── Capability A: recognizable words
├── Capability B: combines words
└── Capability C: communicative intent

Age Band + Milestone Concept
└── Milestone Expectation
├── Criterion 1 <-> Capabilities A + B
├── Criterion 2 <-> Capability B
└── Criterion 3 <-> Capability C

What this example prevents The same capability can support later conversation, narrative, requesting, pretend play, and other milestones without being duplicated. A different framework can express the same milestone concept at another age or with different criteria while retaining its own provenance.

References

↑ Top

1. Centers for Disease Control and Prevention. “CDC’s Developmental Milestones.” Updated 16 February 2026. https://www.cdc.gov/act-early/milestones/index.html

2. Zubler JM, Wiggins LD, Macias MM, et al. “Evidence-Informed Milestones for Developmental Surveillance Tools.” Pediatrics. 2022;149(3):e2021052138. https://publications.aap.org/pediatrics/article/149/3/e2021052138/184748/Evidence-Informed-Milestones-for-Developmental

3. Lipkin PH, Macias MM, Council on Children With Disabilities, Section on Developmental and Behavioral Pediatrics. “Promoting Optimal Development: Identifying Infants and Young Children With Developmental Disorders Through Developmental Surveillance and Screening.” Pediatrics. 2020;145(1):e20193449. https://publications.aap.org/pediatrics/article/145/1/e20193449/36971/Promoting-Optimal-Development-Identifying-Infants

4. Ages & Stages. “ASQ-3.” Product and technical overview. https://agesandstages.com/products-pricing/asq3/

5. Brookes Publishing. “AEPS-3 Assessment” and AEPS-3 product overview. https://products.brookespublishing.com/AEPS-3-Assessment-Volume-2-P1297.aspx

6. U.S. Office of Head Start. “Interactive Head Start Early Learning Outcomes Framework: Ages Birth to Five.” https://headstart.gov/interactive-head-start-early-learning-outcomes-framework-ages-birth-five

7. Ontario Best Start Expert Panel on Early Learning. “Early Learning for Every Child Today: A Framework for Ontario Early Childhood Settings — Continuum of Development.” https://betterbeginningssudbury.ca/wp-content/uploads/2015/09/continuum.pdf

8. Rourke Baby Record. “Rourke Baby Record: 2024 — National Guide.” https://www.rourkebabyrecord.ca/pdf/2024/RBR%202024%20NAT-EN-1vpp-May%2018-BLACK-Feb%209.pdf

9. Looksee Checklist. “Learn More,” “FAQs,” and Areas of Development materials. https://www.lookseechecklist.com/en/learn-more

10. U.S. Department of Education. Individuals with Disabilities Education Act, Section 1432 and 34 CFR §303.21. https://sites.ed.gov/idea/statute-chapter-33/subchapter-iii/1432

11. Internal research draft supplied by the team: “Developmental Atoms — Skill Decomposition Framework.” Used as a research input and gap-analysis source; not treated as an external standard.

Accessed 25 July 2026. External frameworks have different intended uses and licensing conditions. References are included for structural research and should be reviewed by legal/content owners before importing or reproducing source content.