Published

Engineering Design / Product Definition

vr.wm-obj-018 · wm-obj-018-engineering-design-product-definition

Represent an authoritative intended product definition with controlled revisions, requirement realization, engineering meaning, assurance evidence and lifecycle context.

World Models Physical world and living systems PHY.OBJ.DES

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 · 12 findings · 36 questions

Design authority and baselines Establish exactly which intended definition and controlled package an agent is reading.

Controlled revision and design subject

Separate the informational design from physical item, commercial variant and representation file.

Controlled revision and design subject record

Separate the informational design from physical item, commercial variant and representation file.

Which authoritative design ID and revision denote the intended definition, independently of CAD filenames, exports and copies? identity
Which product family, intended configuration and design maturity are in scope? classification
Which representation is authoritative if a drawing and 3D model disagree, and who can resolve that disagreement? authority

Baseline and technical data package

Bind a maturity-appropriate package to an immutable baseline rather than an unqualified file collection.

Baseline and technical data package record

Bind a maturity-appropriate package to an immutable baseline rather than an unqualified file collection.

Which exact file revisions and digests constitute this baseline? composition
Which deliverables are required at this maturity and which are intentionally absent rather than accidentally missing? requirement
Can a recipient retrieve the released package without following a mutable latest pointer or losing controlled external references? access

Intent and justification Explain requirement realization and the selection of this solution over alternatives.

Requirement allocation

Keep requirement content in WM-REC-006 and own only qualified realization and evidence bindings.

Requirement allocation record

Keep requirement content in WM-REC-006 and own only qualified realization and evidence bindings.

Which WM-REC-006 requirement revision does each design element realize? relationship
Which requirements remain unallocated or have conflicting allocations? exception
Which evidence and responsible reviewer justify marking an allocation satisfied instead of merely linked? evidence

Alternatives and rationale

Record why this solution was selected while keeping decision authority external and identifiable.

Alternatives and rationale record

Record why this solution was selected while keeping decision authority external and identifiable.

Which alternative solutions were evaluated against which decision criteria? decision
Which assumptions or uncertain estimates could reverse the selected trade-off? quality
Which decision authority selected the solution and what triggers reconsideration? authority

Product definition and interfaces Describe engineering structure and machine-interpretable geometry and annotations.

Architecture and interface contract

Reference intended architecture and engineering composition without absorbing independent BOM masters.

Architecture and interface contract record

Reference intended architecture and engineering composition without absorbing independent BOM masters.

Which functional elements map to which physical components and BOM revisions? composition
Which interface endpoints, reference frames and mating conditions must agree? spatial
Which external interface dependency remains unresolved and blocks release? constraint

Geometry, material and semantic PMI

Represent intended geometric meaning, not merely visual resemblance or observed dimensions.

Geometry, material and semantic PMI record

Represent intended geometric meaning, not merely visual resemblance or observed dimensions.

Which geometric features carry the nominal dimensions, datums and tolerances? measurement
Is an annotation machine-interpretable PMI or only a graphical presentation? interoperability
Which units, material specification, surface conditions and measurement conventions qualify the intended values? definition

Intended behavior and assurance Qualify what the intended product should do and what supports that assertion.

Functional envelope and failure assumptions

Document intended behavior and limits as qualified design assertions, not physical actuation authority.

Functional envelope and failure assumptions record

Document intended behavior and limits as qualified design assertions, not physical actuation authority.

What functions and modes are intended under which loads and environments? definition
Which failure modes, prohibited uses and interface limits constrain the design? constraint
Which declared capability still lacks analysis or test evidence and must not be treated as certified safe operation? evidence

Design verification and validation

Separate design requirements satisfaction from stakeholder-fit assessment and from end-product testing.

Design verification and validation record

Separate design requirements satisfaction from stakeholder-fit assessment and from end-product testing.

What demonstrates that the definition satisfies its allocated requirements? validation
What separately demonstrates that the selected solution meets stakeholder intent in the intended use context? quality
Which design revision, analysis assumptions and unresolved findings limit each result, without claiming the manufactured item was verified? provenance

Change and realization Control approved revisions and preserve the boundary between design intent and built reality.

Review, release, change and effectivity

Preserve controlled release and change history; scoped deviations do not silently rewrite a baseline.

Review, release, change and effectivity record

Preserve controlled release and change history; scoped deviations do not silently rewrite a baseline.

Who may approve this release and which unresolved findings prevent approval? authority
What changed between revisions, why, and which dependent definitions need review? lifecycle
For which dates, variants, production contexts or serial ranges is the revision or approved deviation applicable? temporal

Manufacturing and inspection handoff

Deliver intended definition and reconcile realization evidence without overwriting intent.

Manufacturing and inspection handoff record

Deliver intended definition and reconcile realization evidence without overwriting intent.

Which build-to and inspect-to documents and tooling references accompany release? process
Which receiving organization acknowledged which exact package revision? event
Which as-built differences are approved deviations and which require an engineering change rather than silently rewriting the intended definition? exception

Controlled technical exchange Preserve authority, accessibility and engineering meaning across custodians and formats.

Technical stewardship, access and retention

Keep owner, custodian, author and consumer roles distinct across Dimensions and tool lifetimes.

Technical stewardship, access and retention record

Keep owner, custodian, author and consumer roles distinct across Dimensions and tool lifetimes.

Who owns the definition and who merely stores or consumes its representations? ownership
Which proprietary or restricted fields may cross a Dimension boundary for the declared purpose and recipient? security
What must remain readable after tool obsolescence or product retirement, and which retention holds prohibit deletion? retention

Transformation and engineering fidelity

A valid export file or matching rendering does not prove engineering-semantic equivalence.

Transformation and engineering fidelity record

A valid export file or matching rendering does not prove engineering-semantic equivalence.

Which native and neutral schema releases and translator versions produced this exchanged representation? provenance
Which geometry, feature associations, units or semantic PMI were lost or degraded even if the rendered model looks correct? interoperability
Which reference fixtures and comparison criteria justify acceptance, and when must the receiver reject the package instead of assuming equivalence? validation

Classifiers Filled

Family: World Models
Category: Physical world and living systems
Entry kind: aggregate
Navigation path: NAV.PHY.OBJ.DES
Domain: PHY.OBJ.DES
Industry: Cross-industry
Tags: engineeringdesignproductdefinitionphy.obj.des

What it is Filled

Owns informational design identity, intended definition assertions, technical-package bindings, requirement and interface traceability, qualified nominal properties, review/release and change context. Product family, selected variant, engineering BOM, physical items, requirements and execution/test masters retain their own lifecycles.

In scope

Design revision, representation authority and baseline package
Requirement allocation, rationale, architecture, geometry, semantic PMI and intended behavior
Scoped design assurance, controlled change, realization handoff, stewardship and loss-aware exchange

Out of scope

Actual item location, mass, wear or present operating state; automated manufacturing or physical actuation
Owning product family, variant configuration, BOM, requirement, workflow or test execution
Claiming certified safety or standards compliance from a valid information model

Why it exists Filled

Represent an authoritative intended product definition with controlled revisions, requirement realization, engineering meaning, assurance evidence and lifecycle context.

Distinguishing features Filled

Holds the intended definition of a product, not a built item or its measured state.
Owns a controlled technical package and its revision baseline, while CAD files and drawings remain external masters.
Traces requirements to design elements, unlike a requirement record that only states what is needed.
Feeds the engineering BOM and variant definitions but does not itself list component occurrences or selections.

What robots and AI may and may not do Filled

Must not

Treat a valid design record as proof of fitness, certification or export permission.
Modify a released revision instead of creating a controlled change.
Send technical data across a border or to third parties without export and contract checks.
Infer requirement satisfaction from the presence of a trace link.
Drive manufacturing or physical actuation directly from the design record.

Only with a human decision

Releasing a design revision.
Approving deviations, waivers and engineering changes.
Authorizing release of technical data outside the organization.

May

Resolve the released baseline and list its package members.
Trace which design elements realize a given requirement revision.
Inspect geometry, units and PMI through approved tooling and report findings.
Draft change requests and deviation reports for review.

Moral aspects Filled

Design errors propagate to every item built, so safety-relevant assumptions must stay visible and reviewed.
Technical packages can carry export-controlled or dual-use information.
Design rationale and authorship should be preserved so accountability is clear after incidents.

Who is affected

End users and the public exposed to the product
Design engineers and approvers
Manufacturers and maintainers who build from the definition

Owners Filled

Steward

Identify the Dimension owner and authoritative engineering-definition masters.

Roles

Dimension owner: Defines namespace, storage, delegation and federation.
Design authority: Owns intended definition and resolves representation conflicts.
Design author: Creates traceable changes and records assumptions without self-granting release.
Engineering reviewer: Checks requirement evidence, interfaces, geometry and unresolved findings.
Release approver: Authorizes an immutable baseline within delegated scope.
Technical data custodian: Maintains access, fixity and preservation without becoming design owner.
Exchange maintainer: Tests translations and exposes semantic loss.

Links to other meta-models Filled

references

WM-REC-006 - Preserve requirement-realization traceability from frozen relation ledger.
WM-OBJ-002 - Resolve family/master classification.
WM-OBJ-017 - Bind configured variants to intended engineering revision.
WM-OBJ-019 - Reference engineering composition masters.
WM-OBJ-001 - Resolve as-built instance context without importing observations as design truth.
Document, analysis, inspection, workflow and decision masters - Reference authoritative representations, evidence and execution rather than duplicating lifecycles.

aligned

ISO AP242 public scope and OMG ReqIF 1.2 - Candidate versioned engineering and requirement exchange profiles; exact mappings and normative conformance remain unverified.

neighbor

WM-REC-006 Requirement - Preserve the frozen REFERENCE realization relation. Requirement content stays mastered there; linked design satisfaction needs separate qualified evidence.
WM-OBJ-002 Product Type / Catalog Item and WM-OBJ-017 Product Configuration / Variant - Family and selected variant retain their identity; a variant can bind this design revision without becoming the design itself.
WM-OBJ-019 Component Type / Engineering BOM - Reference reusable composition and selected occurrences; do not replace the independent engineering BOM master.
WM-OBJ-001 Physical Object / Item - Design is informational intent. Nominal values and design assurance do not establish measured item condition or end-product certification.
CAD file, drawing, document, analysis and inspection masters - Files are versioned representations and evidence; independent tool, document and execution lifecycles remain referenced.

parent

WM-OBJ-002

What else AI and robots need to interact with it Filled

Sources Filled

Design Solution Definition - NASA
Technical Data Management - NASA
MBE PMI Validation and Conformance Testing Project - NIST
Managed model-based 3D engineering - ISO
Requirements Interchange Format 1.2 release - OMG
ReqIF XML schema - OMG
Configuration Management - NASA
PROV-DM - W3C
Date and Time on the Internet: Timestamps - IETF

Open questions

Executable field-level schema and failure fixtures for conflicting authority, stale baseline, unresolved requirement and concurrent change.
Sector-specific engineering geometry, metrology, material, interface and physical-assurance evidence.
Licensed standard inspection and version-specific CAD/PMI/ReqIF crosswalks with explicit unsupported constructs.
Native-versus-derivative real-product tests for geometry, units, tolerances, semantic annotations and requirement traceability.
Independent external research and adversarial review of the completed information contract.
Claude and Grok research each timed out once at 120 seconds; no independent external research result is admitted. Visible owner-authorized provider waiver remains.
ISO AP242 support is public scope only; ASME empty catalogue description was not admitted. Licensed clauses and sector-specific PMI/metrology semantics require specialist review.
NIST fixtures are historical and selected; their old references to current standards are not 2026 version assertions or proof of present tool capability.
NASA process guidance is domain-specific. Local lifecycle, disclosure and release policy must be declared; no universal four-baseline scheme is mandated.
Nested field groups are an information contract, not a complete executable instance schema. CAD/PMI interpretation, real-product examples, target crosswalks and round-trip acceptance fixtures are deferred.
Direct intended properties and capability assertions require product-specific evidence. Actual location, measured state, manufactured-item safety and legal certification remain outside this aggregate.

Machine files

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

Provenance

world-models research · reviewable-draft

Built from: models/wm-obj-018-engineering-design-product-definition/spec.yaml, ver-cy/world-models/card-supplements/wm-obj-018-engineering-design-product-definition.json