Published

Milestone / Deliverable

vr.wm-act-031 · wm-act-031-milestone-deliverable

Represent a planned achievement (milestone) and an accepted output (deliverable) as governed records inside a project or programme, so an agent can define, schedule, produce, verify, accept, report and retire them without owning project, schedule-network, contract, approval-engine or repository semantics.

World Models Activities and processes ACT.MIL

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 12 layers · 28 findings · 101 questions

Identity and definition What this record is, how it is uniquely designated, and whether it is a planned achievement, an accepted output, or both.

Identity and naming

Stable identification and human-facing designation of the record within and beyond its owning project.

Record identity and identifier scope

How a milestone or deliverable record is uniquely identified, at what scope that identifier is unique, and how locally scoped numbering relates to organisation-wide or global identifiers.

Which system holds the authoritative identifier for this milestone or deliverable record, and what is that identifier? identity
At what scope is the identifier guaranteed unique: within the work package, within the project, or across the whole organisation? constraint
What alternate or legacy identifiers refer to the same record, and which of them are safe to publish? interoperability
Under what circumstances may the identifier change, and what must happen to references if it does? lifecycle

Designation, numbering and titling

The human-readable designation of the record: title, structured number derived from work-package position, and free-text description that distinguishes it from neighbouring records.

What short title identifies this record to a reader who does not know its identifier? definition
How is the display number constructed from the work-package or stage position, and who controls that numbering convention? classification
What description states the content of this record beyond its title, and how detailed must it be to be unambiguous? definition

Typology and definitional scope

Whether the record is a control point, a submitted output or both, and what its declared content boundary is.

Milestone versus deliverable determination

Whether the record is a milestone (a control point charting progress, normally of zero duration, that may span several work packages), a deliverable (a discrete output submitted for acceptance), or a deliverable-linked milestone that carries both roles.

Is this record a control point, a submitted output, or a control point whose achievement is evidenced by a submitted output? classification
Does this record occupy elapsed time in the plan, or is it a zero-duration event marking completion of other work? temporal
Does this record belong to exactly one work package, or does it act as a convergence point across several? composition
Must something be submitted to an external party for this record to be complete, or is internal declaration of achievement sufficient? requirement

Type, category and purpose classification

Classification of the record by delivery purpose and by governance category, using controlled vocabularies that can be bound to external codelists.

What is the delivery purpose of this record, expressed against a controlled type vocabulary? classification
Which governance category does the record fall into: assurance gate, delivery point, or business-case decision? authority
When no vocabulary code fits, how may the adopting Dimension extend the vocabulary without breaking exchange? interoperability

Definitional scope and exclusions

The explicit statement of what the record includes and excludes, so that acceptance can be judged against a bounded content definition rather than an implied one.

What content or achievement is inside the declared boundary of this record? definition
What closely related content is explicitly excluded, and where does it belong instead? constraint
Who may change the declared scope after agreement, and what evidence of that change must the record carry? authority

Schedule commitment and plan position The date commitments carried by the record, its position against stages and gates, and how those commitments may be changed.

Date commitments

Baseline, forecast and actual date values and the time semantics that make them comparable.

Baseline planned date commitment

The initial committed completion date, the baseline it belongs to, and the rule that it does not change outside a controlled rebaselining.

What is the baseline planned completion date for this record, and which baseline version does it belong to? temporal
What rule prevents the baseline date from being edited in place, and how is an attempted edit rejected? constraint
Which approved plan or commitment document established this baseline date? provenance

Forecast, due and actual dates

The currently expected completion date, any externally binding due date, and the recorded actual achievement or delivery date, together with their update cadences.

What is the current forecast completion date, and when was it last revised? temporal
Is there a contractually or grant-binding due date distinct from the internal forecast, and may it be revised? constraint
What actual date is recorded for achievement or delivery, and what validation applies to it? event
Which distinct dates must be kept separate for this record: delivery, approval, and achievement? temporal

Time value semantics and precision

How date and timestamp values are expressed, whether a value is a calendar date or an instant, and how event time is distinguished from the time the fact was observed or ingested.

In what format and precision is each temporal value recorded, and what offset is attached? constraint
When did the achievement actually occur, and when was that fact recorded in the system? provenance
How is a timestamp recorded when the instant is known in UTC but the local offset is not? exception
How are date values frozen when a reporting snapshot is taken, so that later revisions do not rewrite reported history? temporal

Plan position, criticality and baseline change

Where the record sits relative to stages, gates and the critical path, and how its committed dates may lawfully move.

Stage and decision-gate association

The stage the record belongs to and the decision gate or life-cycle review whose readiness it supports, without taking ownership of the gate decision itself.

Which stage does this record belong to, and which gate or life-cycle review consumes it as evidence of readiness? relationship
Which entrance or success criteria of that gate does this record contribute to satisfying? requirement
Who is the decision authority for the associated gate, and where is their decision recorded? authority

Criticality and schedule linkage

The record's declared criticality and its link to the driving schedule activity, kept as a reference so that network logic and float remain in the schedule model.

Is this record on the critical path as most recently calculated, and when was that determination made? state
Which schedule activity or work package drives the completion of this record? relationship
What is the declared consequence if this record slips, expressed without recomputing the schedule here? constraint

Baseline change and rebaselining

How a committed baseline date or scope is lawfully changed: the change authority reference, the trigger threshold and the preservation of the superseded commitment.

What condition triggers a rebaseline of this record rather than a simple forecast revision? decision
Which authority may approve a change to the baselined commitment, and where is that authority defined? authority
How is the superseded baseline preserved so that historic variance remains reconstructible? provenance
Does the change affect the date only, or also the declared scope and acceptance criteria? composition

Production responsibility and material form Who is answerable for producing the record, what work produces it, how it decomposes, and what material or informational form it takes.

Responsibility and work linkage

The parties answerable for the record and the work structure that produces it.

Accountable and producing parties

The single accountable party for the record, any contributing producers, and the party permitted to submit it, all held as references to a party model.

Which single party is accountable for this record being achieved or delivered? ownership
Which other parties contribute to producing the record, and in what capacity? relationship
Which party is permitted to submit the record to the receiving authority, and is that permission exclusive? access
How is a change of accountable party recorded without losing the earlier attribution? provenance

Work package and activity linkage

How the record attaches to the work breakdown: its owning work package, contributing tasks, and any cross-package convergence.

Which work package owns this record, and which task within it produces the output? composition
Which additional work packages must converge for this record to be achieved? relationship
Where is the effort and resource assignment for the producing work recorded, given it is not held here? interoperability

Composition and material form

How a deliverable decomposes and what tangible or informational artifacts constitute it.

Composition, grouping and part-whole structure

Whether the record is atomic or composed of sub-deliverables, how grouped deliverables are represented, and the rule for whether a parent is complete when only some parts are.

What sub-deliverables or component achievements make up this record? composition
What rule determines whether the parent is complete, partially met, or not met given the state of its parts? constraint
When several planned deliverables are merged into one submission, how is that grouping recorded against the original plan entries? exception
What prevents circular or contradictory part-whole links between records? validation

Artifact manifest, media form and integrity

The manifest of concrete artifacts that constitute or evidence the deliverable, including media type, language, publication date, format constraints imposed by the receiving system, and integrity digests.

Which concrete artifacts constitute or evidence this deliverable, and what is each one's media type and language? composition
What format, count or packaging constraints does the receiving system impose on the submission? constraint
How can a consumer verify that a retrieved artifact is the exact one that was tendered? evidence
Where the deliverable is physical or an event rather than a file, what stands in for the artifact manifest? exception

Acceptance criteria, decision and evidence What must be true for the record to be accepted, who may accept, what outcome was recorded, and what evidence stands behind it.

Criteria and means of verification

The declared conditions for acceptance and the declared way in which satisfaction of those conditions will be shown.

Acceptance criteria definition

The set of conditions that must be met before the record is accepted, their source, their measurability, and whether they apply to the product, to the process that produced it, or to both.

What conditions must be satisfied before this record can be accepted? requirement
For each criterion, what makes satisfaction objectively determinable rather than a matter of opinion? measurement
From which requirement, specification, review criterion or contract clause is each criterion derived? provenance
When and by whom were the criteria agreed, and can they be changed after work has started? authority

Means of verification declaration

The declared method by which achievement will be demonstrated for a milestone, or conformance shown for a deliverable, distinguishing declaration of method from execution of the check.

By what declared means will achievement or conformance be demonstrated for this record? validation
Which party performs the verification, and is that party independent of the producing party? quality
At what point relative to delivery is verification performed: before, at, or after delivery? process
Under what conditions may a supplier attestation substitute for full verification before acceptance? exception

Acceptance decision and evidence

The recorded acceptance outcome, the authority and place attached to it, and the documentary evidence referenced.

Acceptance authority and place of acceptance

Who is entitled to accept, how delegation is reflected as a reference, and where acceptance takes place, since place determines which quality-assurance regime applies.

Which role is entitled to accept this record on behalf of the receiving party? authority
Has acceptance responsibility been assigned to another office or agency, and where is that assignment recorded? ownership
At what place is acceptance to occur, and does that follow source or destination quality assurance? spatial

Acceptance outcome, conditions and rejection

The recorded outcome of the acceptance act, including conditional acceptance, rejection with reasons, resubmission expectations, and the declared effect and limits of acceptance.

What acceptance outcome is recorded against this record, and at what date-time? decision
If acceptance was conditional, which conditions remain open and by when must they be closed? state
If the record was rejected, what reasons were given and what resubmission is expected? exception
What does acceptance acknowledge, and what defects does it not waive? constraint

Acceptance evidence reference

The documentary evidence that acceptance occurred: acceptance certificates, receiving reports, completion certificates or portal-generated decision exports, referenced with enough metadata to be retrieved and checked.

What document evidences that acceptance occurred, and under what document type is it classified? evidence
Where is the evidence held and how is it retrieved and integrity-checked by a consuming agent? interoperability
What is recorded when acceptance is asserted but no evidence document exists? quality

State, change and provenance The lifecycle states the record moves through, how progress and variance are reported, and how generation, attribution and revision are traced.

Lifecycle and status

The permitted states of the record and the reporting of progress and variance against commitment.

Lifecycle states and transitions

The distinct state vocabularies applying to a record (schedule status, submission status, achievement status), their permitted transitions, and the rules that prevent contradictory combinations.

Which state vocabularies apply to this record, and what is the current value in each? state
Which state transitions are permitted, and which are forbidden or require an authorised exception? lifecycle
What consistency rules bind the state vocabularies to each other and to the recorded dates? validation
Which states are terminal, and what may still be modified on a record in a terminal state? constraint

Progress, variance and delay explanation

How progress against commitment is expressed, how variance between baseline, forecast and actual is derived, and what narrative explanation is required for late, missing or cancelled records.

How is variance between baseline, forecast and actual dates expressed for this record? measurement
What explanation is required when the record is late, missing, cancelled or grouped? quality
When a milestone is not achieved, what estimated completion date must accompany the status? temporal
How does a periodic report freeze the status values reported at that point? process

Provenance and change history

Traceability of who generated and revised the record and its artifacts, and how supersession and cancellation are represented.

Generation and attribution provenance

Which activity generated the record or its artifacts, which agents were responsible, and on whose behalf they acted, expressed so it can be projected onto a standard provenance vocabulary.

Which activity generated this record or artifact, and when did that activity start and end? provenance
To which agent is the record or artifact attributed, and on whose behalf did that agent act? ownership
Which prior entities were used or consumed in producing this record? relationship

Revision, supersession and cancellation

How successive versions of the record and its artifacts relate, how a record is marked superseded or cancelled, and what must survive so historical reports stay reconstructible.

Which earlier record or artifact is this one a revision of, and what changed between them? provenance
When a record is superseded, what marks it and where does the successor reference point? lifecycle
On what grounds may a planned record be cancelled rather than completed, and who may cancel it? decision
Which historical values must remain immutable after supersession so that past reports still reconcile? retention

Classification, access and exchange How sensitivity and publication constraints are declared, how retention and disposition are deferred to their owners, and how the record is exchanged with external systems.

Sensitivity classification and publication

Per-record sensitivity markings and the publication constraints they imply.

Sensitivity and dissemination classification

The classification carried by each record and artifact, ranging from fully public through restricted-by-agreement to formally classified material that must not enter ordinary systems, and the handling rule attached to each level.

What dissemination or sensitivity level is assigned to this record and to each of its artifacts? privacy
What handling rule follows from the assigned level, including any prohibition on uploading the artifact at all? security
Is classification set per item rather than inherited wholesale from the parent project, and how are conflicts resolved? constraint
When is a classification reviewed or downgraded, and what triggers that review? lifecycle

Publication and open-availability binding

Whether and where a record or artifact is published to a public audience, under what condition, and how the public projection is kept consistent with the governed record.

Is this record or artifact eligible for public publication, and on what basis? access
Where is the published version located, and when was it first published? spatial
How is the published projection kept consistent with the governed record after later revisions? interoperability

Retention deferral and interoperability

Where deletion and retention authority sits, and how the record maps onto external identifiers and exchange schemas.

Retention and disposition reference

The retention obligation applying to the record and its artifacts, the instrument that sets it, and the explicit statement that disposition is executed by the repository and records-management owners rather than here.

Which instrument sets the retention obligation for this record and for how long after which trigger event? retention
Which model or policy executes disposition when the retention period expires? ownership
What legal hold, audit or dispute condition suspends disposition, and who may set or lift it? exception
What must remain discoverable after the record's content is disposed of? constraint

External identifier binding and exchange mapping

How the record is bound to identifiers and structures in external delivery-reporting systems, which fields map losslessly, and where mapping is lossy and must be flagged.

Which external schemas is this record required to be projected into, and at which version of each? interoperability
Which local fields map one-to-one onto the target schema, and which require transformation? interoperability
Where does projection lose meaning, and how is that loss declared to the consumer? quality
How are local status and type codes reconciled with closed external codelists that cannot be extended? classification

Classifiers Filled

Family: World Models
Category: Activities and processes
Entry kind: entity
Navigation path: NAV.ACT.MIL
Domain: ACT.MIL
Industry: Cross-industry
Tags: milestonedeliverableact.mil

What it is Filled

This model covers the record of a single milestone or deliverable: its identity and designation, its typology and definitional scope, its baseline/forecast/actual date commitments, its position against stages and gates, the parties accountable for producing it, its composition and artifact manifest, its declared acceptance criteria and means of verification, the recorded acceptance outcome and evidence reference, its status lifecycle, its provenance and revision lineage, its sensitivity/dissemination classification, and its mappings to external delivery-reporting standards. It deliberately stops at the record boundary: schedule calculation, approval execution, file storage, contractual remedy and audit-trail keeping belong to referenced models.

In scope

Milestone record: control point that charts progress, normally zero-duration, with baseline planned, forecast and actual dates and a met/not-met status
Deliverable record: unique and verifiable output submitted for acceptance, with type, dissemination level, due date, submission and acceptance dates
Declared acceptance criteria and means of verification attached to the record
Recorded acceptance outcome (accepted, rejected, conditionally accepted) and the reference to acceptance evidence produced by the accepting authority
Composition of a deliverable into sub-deliverables and its artifact manifest with media/form and integrity digests
Status lifecycle, delay/variance explanation, supersession, grouping and cancellation of the record
Sensitivity and dissemination classification of the record and its artifacts
Provenance of generation, attribution and revision lineage
External identifier bindings and alignment mappings to delivery-reporting standards

Out of scope

Project charter, business case, objectives, funding decisions and overall project lifecycle (owned by WM-ACT-005 Project)
Schedule network logic, activity durations, calendars, float and critical-path calculation (owned by the schedule/activity model; this model only references the driving activity and carries a criticality flag)
Execution of approval or gate decisions, delegation chains and the decision audit trail (owned by the approval/decision-authority model)
Inspection, test and quality-assurance execution and the resulting inspection records (owned by the quality/verification model)
Contract formation, payment triggers, warranty and remedy for latent defect or fraud (owned by the contract/agreement model)
Physical storage, versioning, replication and retention execution of files (owned by the document/artifact repository model)
Outcome and benefit realisation measurement after outputs are used (owned by the benefits/outcome model)
Party, organisation and role registries (owned by the party model)
Requirement catalogues and requirement traceability matrices (owned by the requirement/specification model)
Runtime access-control enforcement and access audit records

Why it exists Filled

Distinguishing features Filled

A milestone is a point of achievement in time, while a deliverable is an artifact or result handed over; both sit inside a project (WM-ACT-005).
Acceptance is a separate decision from submission and is made by a different party.
Baseline dates change only through a recorded rebaseline; forecasts change freely.
It references schedules, contracts and quality checks without owning them.

What robots and AI may and may not do Filled

Must not

Record acceptance of a submission the same party made.
Mark a milestone met or a deliverable accepted without a recorded date and evidence.
Change baseline dates without an authorising rebaseline.
Handle an artifact under a lower classification than the most restrictive one involved.

Only with a human decision

Accepting or rejecting a deliverable.
Approving a rebaseline.
Cancelling a milestone tied to payment or funding.

May

Register a milestone or deliverable with its acceptance criteria.
Revise forecast dates and report variance against the baseline.
Record a submission with its artifact manifest.
Project records to an external delivery or reporting schema.

Moral aspects Filled

Payments, penalties and reputations often depend on acceptance, so decisions must be fair and evidenced.
Publicly funded work owes funders and citizens accurate reporting of what was delivered.

Who is affected

Suppliers and project teams
Customers and acceptance authorities
Funders and sponsors

Owners Filled

Steward

The adopting Dimension names one owner for the Milestone / Deliverable model and one delegated data owner per portfolio or programme that instantiates it, and records both as references into the party model.

Roles

Model steward: Maintain the model definition, its bundles, layers, findings and functions, and keep every node's source references current.; Adjudicate boundary disputes with the project, schedule, approval, repository and contract models and move target-owned concepts out of this model.; Approve vocabulary and mapping version changes and classify them as compatible or breaking.
Delivery data owner (per portfolio or programme): Own the correctness of milestone and deliverable records for their scope, including baseline integrity and timely forecast revision.; Name the accountable party for each record and ensure explanations exist for late, missing, cancelled or grouped items.; Authorise rebaselines within delegated limits and escalate beyond them.
Acceptance liaison: Bind the acceptance authority reference and the decision record produced by the approval model onto the delivery record.; Ensure declared acceptance criteria and means of verification exist before submission and that evidence references are recorded after a decision.; Track open conditions from conditional acceptances to closure without asserting authority over the decision itself.
Classification and access custodian: Assign and review per-record and per-artifact classification and the restricted and protected flags.; Apply handling rules including prohibitions on ordinary transmission channels for classified material.; Approve publication eligibility and monitor divergence between the governed record and any public projection.
Interoperability maintainer: Maintain field mappings to external delivery-reporting schemas and their version bindings.; Declare and publish lossy mappings and unmappable local codes.; Validate projections before export and detect target-schema version drift.

Links to other meta-models Filled

child

WM-ACT-005 Project - The project contains milestones and deliverables; the project owns objectives, stages, gates, funding and controlled closure, while this model owns the individual delivery record.

references

Schedule and activity-network model (sibling; identifier assigned by the adopting Dimension) - Carry references to the driving activity or work package and a criticality flag only; sequencing, durations, float, critical-path and schedule-risk calculation remain in the schedule model.
Party and organisation role model (sibling) - Resolve accountable, contributing, submitting and accepting parties without duplicating party identity, contact or role registries.
Document and artifact repository model (sibling) - Store and serve the artifacts named in the manifest; this model carries locators, media types, languages and digests, not the bytes, the versioning engine or disposition execution.
Approval and decision-authority model (sibling) - Bind the acceptance authority and the decision record; evaluation, delegation resolution, execution and the decision audit trail remain owned there.
Quality, inspection and verification model (sibling) - Point at executed inspections, tests, demonstrations and review outcomes that evidence the declared means of verification; test execution and results are not owned here.
Contract and agreement model (sibling) - Cite the clause that makes a due date or acceptance binding and gives acceptance its legal effect; payment triggers, warranties and remedies remain in the contract model.
Requirement and specification model (sibling) - Derive acceptance criteria from requirement records by reference; requirement text, versioning and traceability matrices are not reproduced here.
Records-management and retention policy of the adopting Dimension - Supply the retention period, trigger and disposition method; this model records the obligation and any hold, and never performs deletion of referenced artifacts.

composes

W3C PROV-O (namespace http://www.w3.org/ns/prov#) - Project generation, attribution, association, derivation and revision assertions onto a standard provenance vocabulary rather than defining a private one.

aligned

Open Contracting Data Standard 1.1 Milestone and Document building blocks - Alignment target for milestone identity, dueDate, dateMet, dateModified, status and document metadata; treated as an alignment, with the closed milestoneStatus codelist recorded as a constraint rather than a claim of conformance.
UK Programme and project data standard — Milestone entity - Alignment target for the baseline/forecast/actual date triad, status and category vocabularies, criticality and restricted/protected flags; the source is under consultation, so alignment is provisional.
EU Funding & Tenders continuous reporting deliverable and milestone structures - Alignment target for the deliverable submission lifecycle, dissemination level, lead beneficiary, delivery and approval dates, and delay explanation obligations.
RFC 3339 date-time profile - Bind all instant-valued fields to a profile requiring seconds and an explicit offset, and adopt the unknown-local-offset convention.

neighbor

WM-ACT-005 Project (parent, CONTAINS) - The project owns objectives, stages, funding, assurance planning and controlled closure; this model owns one delivery record within that structure. GovS 002 requires that a project comprise stages preceded by gates and that deliverables and milestones be defined and agreed for all stages: the stage/gate structure is the project's, the individual milestone record is this model's.
Schedule / activity-network model - GAO best practice treats activities (with duration, logic, resources and float) and milestones (zero-duration events) as distinct schedule objects. Sequencing, duration estimation, critical-path and schedule-risk calculation stay in the schedule model; this model carries only the milestone's baseline/forecast/actual dates, a criticality flag and a reference to the driving activity or work package.
Approval / decision-authority model - FAR 46.502 makes acceptance the act of an authorised representative, and delegation of that responsibility binds the accepting party. This model records who the acceptance authority reference is and what outcome was recorded; it does not evaluate criteria, execute the decision, resolve delegation, or keep the decision audit trail.
Document / artifact repository model - The repository owns byte storage, format conversion, versioning and physical disposition. This model carries the artifact manifest: reference, media type, language, publication date and integrity digest, following the OCDS Document pattern and RFC 9530 digest semantics.
Contract / agreement model - FAR 46.501 gives acceptance a contractual effect (acknowledgment of conformance, subject to latent-defect and fraud exceptions). The legal consequence, payment trigger and remedy belong to the contract model; this model records the acceptance event reference and the clause citation only.
Quality / verification model - NASA life-cycle reviews use entrance and success criteria evaluated by review boards. This model declares the acceptance criteria and means of verification attached to a record and points at the verification evidence; it does not run reviews, tests or inspections nor own their results.
Benefits / outcome model - GovS 002 separates output (product created), outcome (state after outputs are used) and benefit (measurable value). This model stops at the output/achievement record; outcome and benefit measurement are modelled elsewhere and only referenced.

parent

WM-ACT-005

What else AI and robots need to interact with it Filled

Sources Filled

Federal Acquisition Regulation, Part 46 — Quality Assurance - U.S. General Services Administration / FAR Council (Acquisition.gov)
Continuous reporting on milestones & deliverables — EU Funding & Tenders Online Manual - European Commission
Completing the Deliverables — EU Funding & Tenders IT How To - European Commission
GAO Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G) - U.S. Government Accountability Office
Open Contracting Data Standard 1.1.5 — Schema reference (Milestone and Document building blocks) - Open Contracting Partnership
Open Contracting Data Standard 1.1.5 — Codelists (milestoneStatus, milestoneType, documentType) - Open Contracting Partnership
RFC 3339 — Date and Time on the Internet: Timestamps - Internet Engineering Task Force (IETF)
PROV-O: The PROV Ontology - World Wide Web Consortium (W3C)
Government Functional Standard GovS 002: Project delivery - UK Government Project Delivery Function (Cabinet Office / NISTA)
Programme and project data standard (HTML) - UK Government Project Delivery Function (NISTA)
NPR 7120.5F — NASA Space Flight Program and Project Management Requirements, Chapter 2 - National Aeronautics and Space Administration (NASA)
RFC 9530 — Digest Fields - Internet Engineering Task Force (IETF)

Open questions

Confirm the Horizon Europe deliverable type codelist and dissemination-level tokens against first-party portal documentation; the pack deliberately describes the axes generically because only secondary sources were reachable.
Complete the ISO 21500:2021 and ISO 21502:2020 alignment that could not be read in this session, and state explicitly whether either changes the milestone/deliverable typology or the acceptance vocabulary.
Register model IDs for the schedule/activity, approval/decision-authority, document/artifact repository, contract/agreement, quality/verification, benefits/outcome, party and requirement neighbours so the seven boundary notes can be validated against the relationship contract instead of against prose.
Decide the precedence rule between the immutable-history requirement (q-rev-history) and permitted content disposition under the retention obligation, and specify which retained values belong to the tombstone field set.
Specify the consistency boundary for the part-whole roll-up: whether a parent's derived completion state is transactional with its children, eventually consistent, or explicitly marked stale.
Declare the uniqueness scope of the serial identifiers for deliverable-artifact, submission-manifest and acceptance-certificate, mirroring the explicit record-level identifier scope.
Decide whether access policy (read scoping, break-glass, separation of duties) becomes a published structural node of this model or is fully delegated to the access-control model, and align the coverage checklist to whichever is chosen.
Resolve the deferred omissions the provider recorded: earned-value milestone credit semantics under ANSI/EIA-748, milestone-linked payment mechanics left to the contract model, agile increment semantics, multilingual titling beyond one language tag per artifact, and any quantitative data-quality scoring beyond severity flags.
Re-examine whether nav_path NAV.ACT.MIL and domain_tags ACT.MIL leave the deliverable facet of a two-facet model discoverable, as a registry-owned naming decision.
The exact Horizon Europe deliverable type codelist (report, dissemination, data, data management plan, other) and the exact dissemination-level tokens were seen only in secondary sources; the model therefore describes the axes generically and binds to the EU field names confirmed in first-party portal documentation rather than asserting the code tokens.
ISO 21500:2021 and ISO 21502:2020 could not be read in full because ISO catalogue and preview content was not machine-retrievable in this session; they are not cited as a source of specific field definitions, and their alignment is deferred.
Earned-value measurement techniques that attach credit to milestones (for example milestone weighting or 0/100 rules under ANSI/EIA-748) are not modelled; measurement is limited to date variance, and earned-value semantics are assumed to sit in a cost or performance-measurement model.
Milestone-linked payment and performance-based payment mechanics are deliberately left to the contract model even though OCDS provides a payment milestone type.
Agile increment semantics (definition of done, sprint goal, release increment) are not separately modelled; they are treated as an adopting-Dimension specialisation of acceptance criteria and record kind rather than as first-class structure.
Multilingual titling and description beyond a single language tag per artifact is not modelled.
No quantitative data-quality scoring scheme is specified beyond severity flags.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-act-031-milestone-deliverable/spec.yaml, ver-cy/world-models/card-supplements/wm-act-031-milestone-deliverable.json