Four-Portfolio Archetype and AI Workforce Operating Standard

Identifier: DPF-FPAW Version: Candidate 0.1.0 Status: DPF normative candidate; not an adopted Open Group, ISO, OMG, NIST, or ServiceNow standard Normative owner: DPF Standards Steward, a human role designated by the platform maintainer Design sponsor and bounded direct-source contributor attestor: Mark Bodman Owned concerns: enterprise value, portfolio placement, operating-flow, work-allocation, and cross-standard traceability semantics Companion: Archetype Profile Catalog

IT4IT™ is a trademark of The Open Group. This document uses the mark only for accurate editorial reference to the IT4IT Reference Architecture; no affiliation, endorsement, certification, or trademark license is claimed.

Abstract

This standard defines an enterprise operating-model bridge between:

• the operator-contributed four portfolio roles and Mark Bodman’s direct design direction, with independently expressed lineage to The Open Group IT4IT™ Reference Architecture Version 3.0.1, The Shift to Digital Product (W205), and Digital Product Portfolio Management (G252), under the source-use controls in Section 13.1.1
• DPF’s DigitalProduct lifecycle architecture, with a source-validated IT4IT 3.0.1 map covering seven value streams/28 stages, four functional groups/33 primary functional components, six supporting functions, two backbones/nine key data objects, cardinalities, and system-of-record boundaries
• the goods, services, experiences, access products, and public services/benefits an organization actually provides
• the industry operational value streams that create those outcomes
• human employees, contractors, partners, AI coworkers, automated systems, and robots that perform work
• the digital and physical resources, controls, and evidence required to perform that work safely and accountably

The IT4IT Reference Architecture is intentionally centered on managing the business of IT and the lifecycle of Digital Products whose offered outcome essentially depends on software. Its source concept may describe a service, physical item, or digital item, so it is broader than FPAW’s DigitalProduct software/capability identity and narrower than all FPAW BusinessProducts. This standard adds the missing business-operating context around it. A veterinary clinic, bank, municipality, warehouse, builder, restaurant, or salon does not sell only IT4IT-qualified Digital Products, even when its work is deeply digitally enabled. BusinessProducts and industry value streams therefore remain first-class and join IT4IT only through explicit composite digital touchpoints.

An AI coworker is a particularly important bridge. It is simultaneously:

1. a managed DigitalProduct with a strategy, design, build/acquire, release, deployment, operation, assurance, improvement, and retirement lifecycle; and
2. an identity-bearing performer that contributes capacity and work under a job qualification, delegated authority, oversight, and evidence contract.

Those aspects are linked, not duplicated. The digital-product record does not become an employee, and the agent identity does not replace product lifecycle management.

1. Status, scope, and normative language

1.1 Status

DPF-FPAW is an independently expressed DPF candidate intended to become suitable contribution material for a profile or extension of the IT4IT Reference Architecture. It is not an assertion that The Open Group or any other cited body has reviewed, adopted, endorsed, or certified it.

Contributor provenance is material design evidence, but it does not turn DPF expression into Open Group Material or make acknowledgement credit a license to a collective publication. Section 13.1.1 keeps contributor-supplied source material, published standards, attribution, trademark use, and external conformance as separate decisions.

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY indicate requirement strength in the sense of BCP 14 when, and only when, they appear in bold capitals.

1.2 In scope

This standard specifies:

• an original enterprise operating-model metamodel
• four-portfolio placement and dependency rules
• business Product, Offering, DigitalProduct, and service boundaries
• operational value-stream and stage contracts across industries
• activity, job, role, skill, performer, allocation, capacity, and physical-work semantics
• human-AI-robot-partner augmentation and substitution patterns
• the dual DigitalProduct/performer treatment of an AI coworker
• composition of shared, category, leaf-archetype, organization, and jurisdiction profiles
• mapping to the IT4IT Reference Architecture, CSDM, architecture/workflow, AI-governance, workforce, physical-operation, and industry standards
• conformance claims, evidence, and minute-detail gap analysis

1.3 Out of scope

This standard does not:

• redefine the seven IT4IT Reference Architecture v3 value streams, functional components, data objects, or licensed conformance criteria
• define a universal ontology of every occupation; TAK-JSI and referenced occupation sources own job-qualification inputs
• define live agent authorization, global agent identity, or job qualification; TAK, GAID, and TAK-JSI own those subjects
• replace BPMN, CMMN, DMN, ArchiMate, BACM, VDML, ISA-95, GS1, or industry transaction standards
• require every business product, task, facility, asset, or person to be represented as a DigitalProduct
• prescribe one database schema, product platform, model provider, process engine, or CMDB
• imply that a mapped or derived result is an external certification

2. Design goals and invariants

The standard exists to make the following questions answerable from one traceable model:

1. What value does the organization promise, to whom, and through which business Product or Offer?
2. Which portfolio owns each governed aspect and which other portfolios does it depend on?
3. Through which industry-recognizable value stream and stages is the outcome created?
4. Which capabilities and work units realize each stage?
5. Which human, AI, robot, automated, or partner performers may do that work, under which job, skill, authority, supervision, and evidence conditions?
6. Which DigitalProducts and physical resources enable the work, and where do their separate lifecycles connect?
7. What actually happened, did it achieve the intended outcome, and what gaps remain?

The following invariants apply throughout:

• Portfolio role is not item type. A portfolio says why an aspect is funded and governed; it does not turn every member into a DigitalProduct.
• Business Product is not DigitalProduct. A business Product may be physical, digital, service, experience, access, entitlement, public benefit, or hybrid.
• Value stream is not process. A value stream describes value-state transitions; processes, cases, decisions, and physical tasks realize those transitions.
• Capability is not skill. A capability belongs to an organization; a skill or competence is demonstrated by a performer in a context.
• Job is not incumbent. A job bundles outcomes and accountabilities; a person or AI coworker is one possible performer.
• Role is not performer. A role is contextual responsibility; a performer is an identity-bearing subject eligible for an assignment.
• Digital command is not physical completion. Appropriate physical, human, sensor, custody, or transaction evidence is required.
• Capability is not authority. A model, human, partner, or robot may be able to act without being permitted or qualified to do so.
• Evidence is not certification. A local mapping or assessment states only what its declared method and verifier support.
• One concern, one authority. The standard links existing canonical records; it does not create a second home for commerce, the IT4IT Reference Architecture, agent identity, runtime policy, job qualification, or archetypes.

3. Standards position and ownership

3.1 The bridge in one view

flowchart LR
    A["Business outcome and business Product"] --> B["Industry operational value stream"]
    B --> C["Stage, capability, and work system"]
    C --> D["Human / AI / robot / partner allocation"]
    C --> E["Digital and physical realization"]
    E --> F["DigitalProduct lifecycle under the IT4IT Reference Architecture"]
    D --> G["GAID identity + TAK-JSI qualification + TAK authority"]
    C --> H["Controls, measures, and evidence"]
    F --> H
    G --> H
    H --> I["Conformance gaps and portfolio backlog"]

The diagram is a textual summary, not a new record hierarchy. It shows that the IT4IT Reference Architecture and the agent standards family join the business operating model at different, explicit seams.

3.2 Canonical ownership map

3.3 Relationship vocabulary

Cross-standard mappings MUST use one of these relationships:

Concept mappings SHOULD additionally use the SKOS-style relations exact, close, broad, narrow, or related, with rationale, source and target versions, confidence, reviewer, and date. The relation is always read from the external source concept to the FPAW target: broad means the target is broader than the source, while narrow means the target is narrower than the source. A polyhierarchical or composite projection whose direction cannot be stated without qualification uses related plus explicit component edges; it MUST NOT use broad or narrow as shorthand for “the source covers more/fewer things.” An exact mapping MUST NOT be used merely because two labels look alike.

4. Resolution model and trace spine

DPF-FPAW uses six cumulative resolution depths. They provide IT4IT-caliber specificity without copying that architecture’s metamodel. They are orthogonal to IT4IT Levels 1–5 and MUST NOT be reported as numeric equivalents; Section 13.3 records only a qualified view-to-view relationship.

Every refinement MUST trace upward. An R3–R5 object without an R0–R2 purpose is orphaned; an R0–R2 promise without an R3–R5 realization is unsubstantiated.

The complete trace spine is:

Organization
  → objective / outcome
  → business Product / Offering
  → operational value stream
  → stage
  → capability
  → operating flow / work unit
  → allocation
  → performer + job/role + skill/qualification
  → digital/physical/information resource
  → authority/control
  → evidence/measure/incident
  → conformance finding/gap
  → primary portfolio and canonical backlog work

An implementation MAY materialize this as relations, projections, resolvable references, or an exchange graph. It MUST NOT infer a missing semantic link solely from a matching name.

4.1 Applicability and consequence predicates

Terms that gate requirements are governed data, not discretionary prose:

material means a change or work item crosses a profile-declared threshold for stakeholder outcome, law/rights, safety, financial exposure, privacy/security, service commitment, identity/authority, capacity, or reversibility. consequential means it can commit funds or obligations, determine rights or eligibility, affect health/safety, alter an authoritative record, disclose protected data, control physical equipment, or cause a difficult-to-reverse state change. A profile MUST publish its thresholds and source authority. When classification is disputed or evidence is missing, the record remains undetermined or unknown, the related requirement is not-assessed, and a Gap is opened.

5. Original conceptual metamodel

The concepts below are logical contracts. They do not imply one new database table per row.

principalKind uses exactly organization, person, team, agent-subject, deterministic-automation, or authorized-robot in the core vocabulary. A versioned Profile may add a namespaced kind only when it preserves the identity and authority invariants below. A partner is an organization relationship, not a second identity kind.

Current DPF persistence still carries contextual values in Principal.kind. Until that substrate is converged, its lossless FPAW adapter MUST emit both the source value and the canonical kind/role:

An additional runtime value MUST have an explicit lossless mapping or a namespaced Profile extension. Changing customer/partner context MUST NOT re-identify the Principal.

5.1 Relationship invariants

• An in-scope governed aspect MUST have exactly one active primary portfolio placement for an effective period or a missing GDM-PORTFOLIO Gap whose observed placement is unclassified, and MUST NOT have more than one. One real-world thing may expose several explicitly related aspects.
• A GovernedAspect MUST resolve to one canonical target, declare its owning concern, lifecycle, accountability, and non-overlap boundary, relate itself to sibling aspects, and retain merge/supersession history. An arbitrary label MUST NOT create a new aspect or evade the exact-one-placement invariant.
• An active GovernedAspect MUST resolve its kind through one effective AspectKindDefinition. For overlapping effective periods, (organizationScope, canonicalTargetRef, aspectKind, owningConcern) is unique, and owningConcern MUST equal the resolved definition. Two sibling kinds on the same target are permitted only when both definitions prove their boundary predicates disjoint; otherwise they are duplicate/overlap Gaps.
• Every active Objective MUST relate to one or more intended Outcomes. An Outcome may have zero or more OutcomeObservations; an observation MUST NOT replace the target or imply satisfaction without the Outcome’s declared measure, acceptance rule, and verifier.
• A BusinessProduct MUST bind to at least one ValueStream and intended Outcome.
• A ValueStream MUST begin with a stakeholder trigger and end with an accepted stakeholder outcome.
• A Stage MUST require one or more Capabilities and identify its work realization or a justified gap.
• Every Organization MUST resolve to an organization Principal when it owns accountability, authority, or governed records. Its affiliated people, teams, and AgentSubjects remain separate Principals; affiliation never merges their identities.
• Every Performer MUST resolve to exactly one Principal for its scoped effective period. One Principal MAY have multiple contextual Performer projections over time; a new role, job, assignment, deployment, or runtime instance MUST NOT create a second enduring identity.
• A Team Principal exists only when the team has a stable identity, governed membership, owner or sponsor, accountable human or Organization Principal, authority boundary, lifecycle, and effective period. An ad hoc human/AI grouping remains Collaboration over its member Principals.
• An agent-subject Principal MUST bind through AgentSubjectReference to exactly one authoritative GAID AgentSubject for the FPAW identity scope and effective period. GAID owns that subject identity; FPAW MUST NOT mint a competing AgentSubject or treat a deployment/runtime instance as one.
• Principal identity alone MUST NOT grant work eligibility, qualification, accountability, or action authority. Those rights arise only from effective assignments, qualifications, policy, and control evidence. AccountabilityAssignment remains human or organizational; a Team Principal can receive it only when its accountable human or Organization Principal is explicit.
• A consequential WorkOccurrence MUST have an accountable Principal even when the executor is AI, robotic, automated, or external.
• A WorkAssignment MUST bind exactly one WorkOccurrence, one ActivityDefinition-or-Role responsibility, one Performer, and one AllocationDecision, plus authority, qualification/eligibility, supervision, fallback, evidence expectations, and an effective period; an assignee ID alone is insufficient. Joint work MUST use the AllocationDecision’s one Collaboration containing 2..* atomic WorkAssignments.
• A qualification or assignment that names an activity MUST resolve that name to an ActivityDefinition and state whether any external activity mapping is exact, close, broad, narrow, or merely related.
• A SkillRequirement MUST reference a SkillConcept; claimed performer proficiency MUST be a separate CompetenceAssertion with provenance, verifier, scope, confidence, and freshness.
• A DigitalProduct relation to a BusinessProduct, Stage, or WorkUnitDefinition MUST be explicit and typed.
• A Gap MUST carry its own verification lifecycle and MUST NOT duplicate remediation-work status. Planned remediation links canonical work; detection/triage may instead carry an explicit disposition rationale until remediation is authorized.
• A profile or mapping MUST retain source version and effective date; silent inheritance from a newer source version is prohibited.
• A SourceUseDecision MUST bind one source artifact or separately supplied contribution to one intended use. Permission for a contributor-origin source MUST NOT be inherited by the compiled publication, another contributor’s expression, or another use.

5.2 Core aspect-kind registry

The base aspectKind set is the registry FPAW-ASPECT-KINDS@0.1.0. Every row below expands to a complete AspectKindDefinition record with registryVersion = 0.1.0, owner = DPF Standards Steward, effectiveFrom = 2026-08-01, and effectiveTo = null. These common values are data, not defaults that an implementation may omit. A Profile may add only a versioned, namespaced record with the same fields and predicate grammar.

The predicate grammar is deliberately small and deterministic: eq(field,value), in(field,{values}), and(predicate,...), and cardinality(field,min,max). Operands use the exact field keys shown below. A predicate engine MUST reject an unknown operator, field, target kind, or concern key rather than treating it as free text.

Active uniqueness is a collision predicate, not string equality over a serialized tuple. Two aspects collide when organization scope, kind key, target ID/version, and every scalar discriminator are equal; their half-open effective periods overlap; and every set-valued discriminator has a non-empty intersection. An open interval end is positive infinity. The set-valued keys are assignmentAuthorityScope, dedicatedProductOrStageScope, and consumerScope; their members are canonical IDs, not labels. Thus {A,B} and {B,C} collide through B. Pairwise-disjoint scope sets do not collide. The row predicate, discriminator, incompatibility set, and merge-policy key are normative data.

For two different kinds, an incompatibility-set match is evaluated when their organization, target, effective period, and applicable set-valued scopes overlap under the same rules. Boundary predicates are evaluated over overlapping effective periods; partially overlapping scopes MUST NOT evade a duplicate/overlap finding by using different serialized set values.

The merge policies have exact outcomes: identity-preserving-only forbids merging distinct source identities; source-lineage-compatible and custody-lineage-compatible require a common declared successor plus compatible target kind, owner/custodian, and scope; scope-disjoint-only, dedicated-scope-disjoint, and shared-scope-disjoint require pairwise-disjoint scopes before a successor is formed; authority-objective-compatible additionally requires equal authority source and control objective. An incompatible pair or failed predicate creates a duplicate/overlap Gap. Split creates versioned siblings with disjoint scopes and a common predecessor; merge creates one successor and supersedes every predecessor. Neither operation may rewrite historical placements or evidence.

6. Four-portfolio enterprise model

The four roots remain stable. They are grounded in Mark Bodman’s contributor-attested design direction and DPF’s canonical portfolio registry. G252 is recorded only as bibliographic design lineage; the published guide and the contributor-origin concepts are distinct sources under Section 13.1.1. DPF-FPAW calls the roots portfolio roles because membership describes governance purpose, not intrinsic object type. Exact published-wording or conformance equivalence remains unasserted.

The snake_case keys above are the target exchange vocabulary of this standard. Current DPF runtime types and persisted PortfolioDecomposition values still use camelCase keys. Until the adapter convergence in Section 18 lands, an implementation MUST publish an explicit, lossless mapping between those current keys and this target vocabulary; neither spelling may be silently presented as already authoritative for the other surface.

The current DPF adapter mapping is:

This table defines serialization equivalence only. It does not rename the current source enum, and it does not make a runtime object conformant without the governed-aspect placement, ownership, relationship, and evidence assertions required by this section.

6.1 Placement algorithm

For each governed aspect, evaluate in this order:

1. If it is part of the external value promise, place it in Goods and Services for Sale.
2. Otherwise, if it is contributor capacity, workforce structure, or contributor-consumed value, place it in Workforce.
3. Otherwise, if it is dedicated to producing or fulfilling one or more external products, place it in Manufacturing and Delivery.
4. Otherwise, if it is reusable enterprise foundation, place it in Foundational.
5. If no rule applies, record a missing GDM-PORTFOLIO Gap with observed placement unclassified; do not choose the nearest label.

Placement follows investment accountability and lifecycle ownership, not implementation technology. A cloud service can be Foundational, Manufacturing and Delivery, Workforce, or part of a sold BusinessProduct, depending on the governed aspect and consumer.

6.2 Multi-aspect decomposition

A thing MUST NOT be double-counted by assigning one aspect to several primary portfolios. It MAY have several aspects, each with one placement and typed relations among them.

Examples:

• An AI coworker’s identity, skills, capacity, and authority are a Workforce performer aspect. Its software, prompts, models, tool adapters, and operational service form a DigitalProduct aspect.
• A passive industrial robot is a Manufacturing and Delivery asset. If it is independently identity-bearing, schedulable, and authorized to perform work, it also has a linked Workforce performer aspect.
• A SaaS platform sold to customers has a commercial BusinessProduct/BusinessProductOffering aspect in Goods and Services for Sale, a DigitalProduct lifecycle, dedicated delivery tooling in Manufacturing and Delivery, and shared infrastructure dependencies in Foundational.
• Client-owned inventory in a warehouse is not the warehouse operator’s sold good. Custody and handling are the sold service; racks, scanners, and dock operations are delivery resources.

6.3 Portfolio dependency contract

Dependencies MUST be directional. The canonical serialization below always reads subject --relation--> object; passive UI labels are aliases, not reversed exchange edges.

Every edge MUST carry subject/object identifiers and versions, relation key, owner, effective period, and evidence. A namespaced extension MUST publish the same subject/object, inverse, transitivity, temporal, and cardinality semantics.

Every active BusinessProduct MUST trace to its necessary Workforce, Manufacturing and Delivery, and Foundational aspects or carry a justified not-applicable decision. Externally supplied products remain dependencies of the consuming portfolio; they MUST NOT be represented as the organization’s own Goods and Services for Sale.

6.4 Two Workforce lenses

The Workforce portfolio contains two linked but distinguishable lenses:

• contribution lens: performers, jobs, roles, skills, capacity, authority, supervision, and workforce outcomes
• internal-consumption lens: products and services supplied primarily to those contributors

An implementation MUST state which lens applies. An internal HR portal is not a performer; an AI coworker is not merely an internal application.

6.5 IT4IT Digital Product portfolio perspective crosswalk

IT4IT 3.0.1 describes market-facing, internal-facing, and foundational Digital Product portfolio perspectives. They classify IT4IT-qualified Digital Products, not every FPAW governed aspect, and do not replace FPAW’s exactly-one primary placement decision.

IT4IT has no portfolio equivalent for FPAW’s Workforce contribution lens or for non-digital Manufacturing and Delivery. Human, AI, robot, contractor, and partner performers plus jobs, skills, allocation, physical production, custody, and delivery work are normative FPAW augmentation.

7. Product, offer, service, and realization boundary

7.1 Business Product forms

A BusinessProduct form MUST use a controlled vocabulary that can represent at least:

• good
• service
• experience
• access
• entitlement
• public-service
• public-benefit
• digital-product
• hybrid

The form is independent of delivery mode. A service may be delivered physically, digitally, or hybrid; a physical good may contain software; a DigitalProduct may be sold, used internally, or embedded in another BusinessProduct.

Business Products SHOULD also declare:

• target consumers and beneficiaries
• commercial or public-value model
• channels
• provisioning or entitlement model
• ownership/custody transfer
• promised outcomes and commitments
• returns, cancellation, renewal, retirement, or end-of-life treatment

offerKind uses exactly business-product, operational-service, or coworker-service in the core. Each Offering version MUST have exactly one provider Organization Principal, one effective period, and exactly one primary target compatible with its kind:

Bundling or cross-selling uses explicit relations among separate Offering versions; it does not add a second primary target. An accepted engagement, entitlement, ProductSold, subscription, or runtime instance is downstream evidence and MUST NOT replace the Offering. A BusinessProduct whose form = digital-product MUST have at least one effective DigitalProduct --constitutes--> BusinessProduct edge; otherwise the form claim is unsatisfied, not a naming shortcut.

7.2 DPF authority boundary

For DPF implementations:

• ProductLine → Product → ProductOffering → CatalogItem → ProductSold owns commercial and sale truth.
• DigitalProduct → ServiceOffering owns digital architecture and operational-service commitments.
• CoworkerService → CoworkerOffer → CoworkerEngagement owns coworker-service terms and accepted engagement context; those records do not replace ProductOffering or ServiceOffering truth.
• Relationships among the commercial, operational-service, and coworker-service chains are explicit and evidence-bearing; they are never inferred from a name, URL, catalog presence, or common owner.

DPF may display the following familiar passive labels, but its exchange edge MUST retain the Section 6.3 canonical direction:

The removed premature DPF ProductDigitalProduct join is not evidence that no semantic relationship exists; it is evidence that persistence must wait for a real consumer workflow and endpoint contract.

7.3 Bill of realization

Every material BusinessProduct SHOULD have a bill of realization linking its promised outcomes to:

• operational value streams and stages
• required capabilities
• human, AI, robot, automated, and partner work
• DigitalProducts and services
• facilities, equipment, materials, inventory, data, and suppliers
• authority, safety, privacy, and commercial controls
• outcome, flow, quality, economics, capacity, and risk evidence

This is broader than a bill of materials and MUST NOT be collapsed into a DigitalProduct-only dependency graph.

8. Operational value streams

8.1 Business value is independent from the IT4IT Reference Architecture

An operational ValueStream describes how a business or public organization creates stakeholder value. It is not an IT4IT Reference Architecture stream and is not automatically part of that architecture’s Consume stream. A relevant stage may map to one or more candidate lifecycle touchpoints when a DigitalProduct is involved, but the business stream retains its own identity and outcome.

DPF’s default macro-backbone reuses the canonical runtime keys from operational-value-stream.ts; display wording is not a second identifier:

trust-compliance and operate-improve are cross-cutting. Profiles MAY insert, split, repeat, rename, or omit stages where the value-state logic requires it. Common insertions include return-inspect, receive-store, field-dispatch states, case review, statutory eligibility, donation acknowledgment, and seasonal production cycles.

A display label may use industry language, but the stable semantic key and mapping rationale MUST remain inspectable.

8.2 Stage contract

Every material Stage MUST declare the following groups:

8.3 Handoffs and flow truth

A material handoff MUST identify sender, receiver, value/evidence transferred, acceptance condition, timing expectation, rejection path, and escalation. A stage marked complete while its transferred work is rejected is rework or exception flow, not successful value movement.

Load-bearing stages MUST be identified from operational evidence or profile rationale. Measures SHOULD cover value, flow, quality, economics, capacity, and risk separately; a single throughput metric cannot stand in for all six.

9. Work system

9.1 OperatingFlow types

An OperatingFlow MUST declare one or more behavior kinds:

• process for predictable ordered work
• case for evidence-driven, non-linear work
• decision for rule, judgment, or policy determination
• task-network for coordinated discrete work
• physical-operation for transformation, movement, treatment, inspection, custody, or onsite work
• event-response for reactive or incident-driven work

BPMN, CMMN, and DMN SHOULD be used where their semantics apply. A physical-operation profile may map to ISA-95, GS1, asset, safety, or industry models. DPF-FPAW adds cross-model traceability; it does not redefine their execution semantics.

9.2 Work-unit definition

Every allocatable WorkUnitDefinition MUST identify:

1. stable identifier, version, and owning Stage
2. intended outcome and acceptance evidence
3. inputs, outputs, and value-state change
4. required skills, proficiency, credentials, and qualifications
5. data classification, permitted use, residency, retention, and steward
6. tools, connectors, facilities, equipment, materials, and inventory
7. physical presence, location, environment, safety, and custody requirements
8. authority, approval, reversibility, consequence, segregation, and escalation class
9. expected time, capacity, quality, cost, continuity, and service constraints
10. exception, fallback, retry, cancellation, and handoff conditions

It also MUST declare a non-empty executionMedia set drawn from:

• software-executed — software, AI, or deterministic automation performs an authoritative action or state transition
• human-cognitive — a human/partner performs judgment, communication, approval, or administrative work, even when a digital tool records it
• physical-actuation — transformation, movement, treatment, inspection, custody, or onsite action is essential

hybrid is a derived label only when the set contains more than one value; it is not a fourth value that hides which media apply.

connectivityMode is orthogonal and uses exactly online | intermittently-connected | offline | not-applicable. Paper, verbal, or offline work is therefore representable without misclassifying it as physical. If materially different media have different authority, evidence, or acceptance rules, they are separate WorkUnitDefinitions rather than one coarse multi-value declaration.

Work units SHOULD be split when authority, tools, data sensitivity, consequence, required knowledge, evaluation method, physical reach, or autonomy ceiling differ materially.

9.3 Physical and non-digital work

A WorkUnitDefinition whose executionMedia contains physical-actuation MUST evaluate every stable field group below. Each group has either a value/evidence record or a Section 4.1 not-applicable decision with source, rationale, reviewer, and review date; undetermined cannot satisfy the field contract:

Authoritative observation method, acceptance evidence, and accountable supervision are mandatory for physical completion; the remaining groups are conditional only through the recorded field-applicability decision above. A WorkUnitDefinition whose media include human-cognitive MUST likewise identify its authoritative record or observation method—for example a signed form, approved case record, transaction, inspection, or witnessed handoff—rather than inferring completion from task UI state.

canPerformPhysicalWork: true is never sufficient. A digital twin or EA projection MUST NOT replace the authoritative asset, transaction, clinical, custody, or domain record.

A digital command, checklist completion, or AI statement MUST NOT be treated as proof of physical completion. Evidence may come from an authorized human, partner, machine/sensor, transaction, inspection, custody transfer, or another profile-approved source.

9.4 Capacity

Capacity MUST be typed. Supported units may include employee-hours, crew-hours, AI concurrency, model/provider budget, appointment slots, facility beds/chairs/bays/rooms, vehicle/equipment time, inventory, storage volume, route stops, decision-review capacity, or regulated credentials.

Capacity projections MUST expose the limiting resource and freshness of observation. Substituting AI for one activity does not remove residual human exception, approval, supervision, or recovery capacity.

9.5 DPF Workroom definition and instance projection

DPF may present the formal work model through the qualified business phrases Workroom definition and Workroom instance. These are projections, not additional standard entities:

• a Workroom definition projects one or more versioned WorkUnitDefinitions with their owning OperatingFlow, Stage, applicable archetype/Profile, and convening policy; and
• a Workroom instance projects one root WorkOccurrence through its domain or coordination WorkCase. A composite instance may contain child WorkOccurrences, each of which remains independently identifiable and governed.

The canonical DPF vocabulary and persistence boundary is defined in workroom-vocabulary-boundary.md. A DPF implementation MUST refactor the existing Work Case source registry and Workroom projections toward this mapping; it MUST NOT create a parallel room-template store, occurrence ledger, agent task bus, or portfolio ledger.

Every Workroom instance MUST reference the exact definition version used and preserve approved instance tailoring. A standing instance uses bounded cycles for a stream of repeated activity. A finite instance seals after acceptance. A schedule, domain event, exception, or prior occurrence may spawn an instance. Temporary workspaces or execution resources may be torn down, but retained definition identity, occurrence identity, actions, receipts, outcome evidence, and required measures MUST NOT be deleted as a side effect.

A sub-room is a contained Workroom instance with an independently meaningful objective or control boundary. A cycle is not a sub-room unless it needs its own accountability, authority, lifecycle, or outcome evidence. Work coordination distinguishes structural containment, spawn provenance, dependency, blocking, and outcome contribution. These coordination relations do not replace Section 6.3 portfolio dependencies or the authoritative relations of a domain system.

Portfolio placement remains aspect-based. A Workroom definition may declare a default primary coordinated portfolio role and directional dependencies; an instance records their effective values and exceptions. The room references canonical Products, Performers, Resources, work, and evidence—it does not own copies of them. Definition estimates, targets, and evidence policy remain distinguishable from instance actuals such as elapsed time, cost, capacity, token/tool use, exceptions, and accepted outcomes.

10. Performer and work-allocation model

10.1 Performer kinds

An implementation MUST distinguish at least:

• human
• ai-coworker
• deterministic-automation
• authorized-robot
• partner-organization

Passive machinery is a Resource, not a Performer. An authorized robot has both a performer identity and a separately managed physical asset/controller/safety configuration. A mixed team is a Collaboration and allocation over canonical Performers, unless the team itself resolves to an independently governed Team Principal; it is not a primitive Performer kind.

10.2 Allocation is a governed decision

Allocation occurs in two ordered steps:

1. Eligibility gates: authority, license/credential, safety, physical reach/location, data clearance, tool/resource availability, current skill or job qualification, contractual and legal constraints.
2. Suitability selection: expected quality, latency, cost, capacity, oversight burden, resilience, learning value, stakeholder preference, and concentration risk.

An ineligible performer MUST NOT become eligible merely because it is faster, cheaper, available, or preferred by a model.

10.3 Allocation patterns

The following controlled vocabulary is normative:

10.4 Accountability and collaboration

Every consequential WorkOccurrence MUST identify:

• executor(s)
• accountable human or organizational Principal
• reviewer/approver when required
• consulted roles when their input is mandatory
• escalation receiver
• override authority
• prohibited actions
• fallback and continuity owner

This applies to a zero-employee organization. Human employment is not mandatory; legal and organizational accountability cannot be delegated away to an AI coworker.

Each AllocationDecision references exactly one WorkOccurrence, exactly one pattern, and 1..* WorkAssignments. Each WorkAssignment references that same WorkOccurrence and exactly one ActivityDefinition/Role responsibility, one Performer, and one AllocationDecision. executor(s) above is therefore the set of atomic assignments, not a plural assignee field. When the pattern table requires joint work, the AllocationDecision references exactly one Collaboration over 2..* of its assignments; that Collaboration records sequencing/parallelism, handoffs, reconciliation, shared acceptance, and escalation. One WorkAssignment MUST NOT belong to several AllocationDecisions. Within an AllocationDecision, (WorkAssignment, responsibility) membership is unique. A Collaboration cannot contain an assignment owned by another AllocationDecision, and every assignment required by the selected pattern appears exactly once in the decision’s complete assignment set.

10.5 Augmentation and substitution

Augmentation or replacement MUST be assessed at WorkUnitDefinition granularity, not by deleting a job title. The assessment MUST be a versioned WorkforceTransitionAssessment and record:

• immutable baseline and target allocation snapshots, controlled decision state, effective period, and scope
• a total activity partition: baseline activities are exactly one of retained, transferred, or retired; every retained/transferred baseline activity maps to 1..* target activities, and every target activity maps to exactly one retained/transferred predecessor or is new
• affected Jobs, SkillRequirements, human Principals or populations, and AI/automation/partner Performers
• reskilling, redeployment, displacement, consultation, or no-change treatment for affected people
• residual human demand and exception load
• supervision, approval, and recovery cost
• safety, legal, professional, and affected-party constraints
• data/tool/provider dependencies and concentration risk
• quality, time, cost, capacity, and resilience evidence
• transition, rollback, fallback, and workforce-impact plan
• accountable owner and review date

WorkforceTransitionAssessment.decisionState uses exactly:

draft | assessed | approved | effective | verification-pending | closed | withdrawn | superseded.

Legal forward transitions are draft → assessed | superseded, assessed → approved | withdrawn | superseded, approved → effective | withdrawn | superseded, effective → verification-pending | superseded, and verification-pending → closed | effective | superseded. withdrawn, closed, and superseded are terminal; every superseded transition links its successor. Once assessed, baseline and target snapshots are immutable; a change creates a new version. Two approved, effective, or verification-pending versions for the same scope MUST NOT have overlapping effective periods.

Every retired baseline activity MUST state how its intended Outcome, obligation, exception, evidence, and residual demand are eliminated, transferred, or otherwise satisfied. Deleting a Job or position MUST NOT silently delete work or its accountability. closed requires target-outcome and workforce-impact verification; completing a rollout task is insufficient.

Observed performance may update suitability or proficiency confidence. It MUST NOT silently widen authority, job scope, or autonomy.

10.6 Shared versus industry-specific AI coworkers

A shared AI-coworker DigitalProduct/profile family SHOULD be reused when intended outcome, activity semantics, authority envelope, evidence contract, tool pattern, data sensitivity, legal/safety burden, and evaluation requirements remain materially equivalent. A family is a reusable design and qualification template; it is not a GAID AgentSubject or proof that a deployed coworker exists.

Specialization SHOULD occur through versioned profession, archetype, jurisdiction, vocabulary, control, tool, and evidence facets. A distinct industry-specific DigitalProduct/profile family SHOULD require at least one material difference in:

• occupational or professional decision scope
• regulated or delegated authority
• safety boundary or physical interface
• data/custody boundary
• non-transferable evidence or evaluation contract
• accountability or external relying-party contract

GAID alone governs when an AgentSubject identity is minted, resolved, or retired for an issuer, organization/deployment, and accountability lifecycle. Industry novelty is neither necessary nor sufficient for identity creation.

This produces reusable horizontal coworkers for demand, customer care, scheduling/dispatch, finance, compliance, supply, workforce, records, and operations, with narrower specializations for clinical, financial-regulatory, public-safety, cold-chain/custody, licensed craft, or similarly bounded work.

11. AI coworker as DigitalProduct and performer

11.1 Dual-aspect rule

An AI coworker MUST be modeled through two linked aspects:

The aspects MUST have a resolvable, versioned relationship. They MUST NOT be two independent copies of the same identity or lifecycle truth.

The following implications are normative:

• An AI coworker in Workforce is still subject to DigitalProduct lifecycle management.
• A DigitalProduct release does not automatically authorize an Agent to act.
• A GAID identity does not prove that its current operating profile is qualified for a job.
• A TAK-JSI qualification does not grant live permission; TAK computes the execution-time ceiling.
• A service offer for coworker work does not become evidence that the work happened.
• A new model, prompt, tool, corpus, memory policy, provider route, or authority envelope may be a material change requiring product, qualification, and runtime re-evaluation.

11.2 Qualification boundary: Agent, AI coworker, and DigitalProduct

Agent is the broad technical and organizational actor class. AI coworker is the narrower term for an Agent deliberately managed as both a DigitalProduct and a Performer. A prompt, model, tool, skill, script, experimental agent, or subordinate worker MUST NOT be promoted to an AI coworker or standalone DigitalProduct merely because it can execute agentic behavior. It normally remains a versioned asset or component of the DigitalProduct that owns the consumer outcome.

An implementation claiming the FPAW-Managed-AI-Coworker-DigitalProduct qualification MUST evidence:

1. an agreed consumer and outcome
2. software that is essential to realizing that outcome
3. active product ownership and lifecycle management
4. at least one formal internal or external offer
5. explicit price, chargeback, showback, or documented zero-price treatment
6. accepted consumption or assignment terms
7. instance-readiness evidence and, for an operated claim, one or more managed runtime or service instances

DPF MAY project an Agent into a candidate DigitalProduct record to establish lifecycle work, but the projection itself is not conformance evidence. Until the criteria above are verified, the record MUST report candidate or an equivalent non-conformant qualification state rather than claim the FPAW qualification. This qualification is an original DPF product-management profile, not an assertion of IT4IT Reference Architecture conformance. An external conformance claim requires an authorized edition, applicable SourceUseDecision, and qualified human assessment. Within this standard, the unqualified phrase AI coworker always denotes the managed dual-aspect concept; broader technical agents are named explicitly as Agents or components.

This boundary preserves the operator’s key insight—an AI coworker is itself a type of DigitalProduct—without treating every reusable agentic artifact as an independently offered product.

11.3 Product-to-runtime chain

A conforming AI-coworker implementation SHOULD expose this chain, using local equivalents:

strategy / portfolio decision
  → DigitalProduct definition
  → DigitalProductDesign and controlled requirements
  → DigitalProductRelease definition
  → versioned DigitalProductAssets (model, prompt, data/corpus, skill packages, tools, policies)
  → immutable DeploymentPackage
  → approved DeploymentIntent
  → attributable Deployment
  → actual DigitalProductInstance and exposed ServiceInstances/endpoints
  → deployment-scoped operating-profile fingerprint referencing the DigitalProductRelease and actual configuration
  → enduring GAID/Principal performer identity
  → Offering, ConsumptionAgreement, Entitlement, UsageOccurrence, coworker service, and eligible job/activity assignments
  → TAK-governed actions and attributable evidence

This chain separates planning, Product definition, design, release, versioned assets, deployable packages, desired deployment, actual operational instances/services, and consumption. Sections 13.3 and 13.4 supply the source-validated IT4IT 3.0.1 and CSDM 5 mappings; implementations remain free to use another conformant system of record.

One DigitalProduct version MAY support several deployed instances. One enduring AI-coworker identity MAY move across approved versions over time. A conformance claim MUST identify which operating-profile fingerprint and deployed configuration produced the evidence.

The release or DigitalProductInstance realizes the DigitalProduct; an AgentSubject does not. An AIProductOperatingBinding states that one enduring subject performs under one release/profile combination for a declared role and period. Each binding references exactly one DigitalProductRelease, one operating-profile fingerprint, and one AgentSubjectReference, plus zero or one DigitalProductInstance: zero is permitted for approved pre-deployment qualification and exactly one is required for an active/operated claim.

bindingState uses exactly candidate | approved | active | suspended | retired. Legal transitions are candidate → approved | retired, approved → active | suspended | retired, active → suspended | retired, and suspended → approved | active | retired; retired is terminal. approved requires a current TAK-JSI qualification reference and approved release/profile combination; active additionally requires exactly one deployed instance and current runtime policy evidence.

The active uniqueness key is (organizationScope, DigitalProductRelease, operatingProfileFingerprint, AgentSubjectReference, role) over overlapping effective periods. AIProductBindingCompatibility.disposition uses exactly compatible | segregated | incompatible | undetermined. It is a pairwise relation, not one scalar field on a binding. For every pair of bindings with the same subject/role whose effective periods overlap in active, exactly one current compatibility relation exists, keyed by the lexically ordered pair of binding IDs plus the evaluated overlap period. Only compatible, or segregated with provably disjoint assignment, authority, data, tool, and memory scopes, may overlap in active; incompatible/undetermined overlap is prohibited. One binding can therefore have different evidenced dispositions against different peers. Every AI-Performer WorkAssignment references exactly one active AIProductOperatingBinding and its current TAK-JSI qualification; a non-AI assignment references none. One binding may support many temporal WorkAssignments. Every Evidence record that supports an AI WorkAssignment or an operated implementation-state claim references exactly one binding that was active at observedAt, its one deployed instance, and the qualification/policy versions effective at that time. Later suspension or retirement does not rewrite that historical evidence.

The following cardinalities are the vendor-neutral default. A profile MAY narrow them but MUST NOT collapse the identities or lifecycles:

• an active AI-coworker DigitalProduct has 1..* DigitalProductDesigns; each design belongs to exactly one DigitalProduct
• one DigitalProductDesign may govern 0..* DigitalProductReleases; each release references exactly one design and one DigitalProduct
• a release composes 1..* versioned DigitalProductAssets and may produce 1..* DeploymentPackages; an asset may be reused by several releases and a package belongs to exactly one release composition
• one DigitalProductRelease may have 0..* DeploymentIntents; each intent references exactly one release, consumer/environment scope, desired topology, and approval
• one DeploymentIntent has 0..* Deployment attempts and 0..1 current DigitalProductInstance until successful fulfillment, then exactly one; each instance realizes exactly one effective intent, while a changed desired state creates a new intent version rather than rewriting deployment history
• one DigitalProductInstance may realize 0..* ServiceInstances and one ServiceInstance may depend on 1..* DigitalProductInstances/resources; each ServiceInstance references exactly one ServiceDefinition
• one DigitalProductRelease may support many operating profiles; each operating profile references exactly one primary DigitalProductRelease plus 0..* dependency releases and fingerprints the deployed model, prompt, skill package, tool, data, memory, policy, provider, and oversight configuration that TAK-JSI evaluates
• a DigitalProduct has 0..* Offering versions and 0..* DigitalProductInstances; one Offering may produce 0..* ConsumptionAgreements, and each agreement accepts exactly one Offering version for one provider/consumer pair and may establish 0..* Entitlements, 0..* DeploymentIntents, and 0..* UsageOccurrences
• the FPAW managed-product qualification requires a formal offer, while an operated implementation-state claim also requires a managed instance in the assessed scope
• a DigitalProduct has 0..* AIProductOperatingBindings before managed-coworker qualification; the FPAW-Managed-AI-Coworker-DigitalProduct qualification requires at least one current approved or active binding, and an operated claim requires an active binding
• the Performer aspect resolves through the binding to a GAID-owned enduring subject plus the applicable release and operating-profile context; GAID remains authoritative for subject identity while FPAW owns this Product/work relationship
• a referenced agent subject may participate in many runtime deployments and temporal WorkAssignments
• CoworkerService-to-DigitalProduct is conceptually many-to-many: one product can provide several services, and a composite service can depend on several products

The Offering → ConsumptionAgreement → Entitlement/request → DeploymentIntent/UsageOccurrence chain and the DigitalProduct → Design → Release → Asset → Package → DeploymentIntent → Deployment → DigitalProductInstance → ServiceInstance chain are related but distinct. Neither chain substitutes for the GAID subject identity, qualification, assignment, or action-evidence chain.

11.4 AI-coworker operating reference view using TAK

Mark Bodman attests that he originated CSDM as a ServiceNow internal standard, created several public CSDM pattern videos, and regards the opening implementation-agnostic view in AI Control Tower with CSDM 5 as relevant to TAK. The exact videos and any separable rights in ServiceNow publications have not been enumerated. The canonical DPF four-plane reference architecture lives in the TAK standard. The bridge view below is independently expressed from DPF’s own TAK, GAID, DigitalProduct, and work-allocation semantics. It does not reproduce, transform, or claim permission to use the ServiceNow source figure. TAK’s companion lifecycle and architecture view expresses the requested end-to-end lifecycle pattern in DPF vocabulary.

flowchart LR
    DP["AI-coworker DigitalProduct"]
    DES["DigitalProductDesign"]
    REL["DigitalProductRelease"]
    AST["DigitalProductAsset"]
    PKG["DeploymentPackage"]
    INT["DeploymentIntent"]
    DEP["Deployment occurrence"]
    INS["DigitalProductInstance"]
    SVC["ServiceInstance"]
    PROF["Deployment operating-profile fingerprint"]
    SUBJ["GAID AgentSubject reference"]
    BND["AIProductOperatingBinding"]
    PERF["AI Performer aspect"]
    JOB["Job, ActivityDefinition, and WorkAssignment"]
    GATE["TAK authority decision and execution receipt"]
    EVID["Outcome, control, and performance evidence"]

    DP --> DES --> REL --> AST --> PKG --> INT --> DEP --> INS --> SVC
    REL -. "release" .-> BND
    DEP -. "deployment occurrence" .-> BND
    INS -. "deployment" .-> BND
    REL -. "release context" .-> PROF
    INS -. "actual configuration" .-> PROF
    PROF -. "operating profile" .-> BND
    SUBJ -. "subject" .-> BND
    SUBJ --> PERF --> JOB --> GATE --> EVID
    BND -. "qualified Product context" .-> PERF
    EVID -. "assurance and lifecycle feedback" .-> DP

TAK owns the runtime authority, delegation, gating, and evidence semantics. FPAW owns only the typed bridge from the separate product, design, release, asset, package, desired-state, deployment-occurrence, product-instance, and service-instance identities to the identity-bearing Performer and its work. CA-MB-2026-08-01-CSDM-PROVENANCE records that origin/video provenance and direct design direction; it does not assert personal ownership of the ServiceNow publications. The local CSDM/AICT publication was used to challenge the technical level boundaries in Section 13.4, but the figure’s entities, relationships, and geometry are DPF-owned TAK/FPAW expression. Public ServiceNow pages are reference-only citations; no external conformance or exact class equivalence is asserted.

11.5 Source-validated IT4IT 3.0.1 lifecycle bridge

The IT4IT Reference Architecture Version 3.0.1 defines seven value streams containing 28 stages. They are a connected value network, not a mandatory linear delivery process. The four current functional groups—Strategy to Portfolio, Requirement to Deploy, Request to Fulfill, and Detect to Correct—group functional components and were the four value streams in Version 2; they are not aliases for, parents of, or replacements for individual Version 3 value streams.

The precise structural mapping is in Section 13.3. In particular, FPAW keeps DigitalProductRelease as the result of Integrate, DeploymentIntent/DigitalProductInstance as the Desired/Actual instance projection of Deploy, and Offering/ConsumptionAgreement as the Release/Consume seam. An industry ValueStream may intersect several of these touchpoints but MUST NOT be renamed to an IT4IT stream.

11.6 Source-validated CSDM 5 deployment patterns

The following vendor-neutral profiles are grounded in the CSDM 5 separation among Product Model, Business Application/design context, SDLC component or AI Digital Asset, deployed CI/service instance, service/Service Offering, catalog representation, and consumption. Section 13.4 records the qualified semantic mappings and the constructs that CSDM does not supply. The same DigitalProduct can therefore have different product, asset, deployment, service, dependency, and physical-operation shapes.

An implementation MUST state whether a mapping describes product definition, design record, release, versioned asset, deployment package, desired deployment, actual deployment, runtime CI, service instance, service definition, Offering, agreement/entitlement, usage, GAID AgentSubject, work, or evidence. Treating any of these as one “AI agent” record creates ambiguous ownership, cardinality, authority, and lifecycle gaps. A CSDM Product Model is not a CI; an AI Application/AI Function is a runtime projection, never an enduring AgentSubject identity; and a Product Model lifecycle state is not Product Release approval.

12. Archetype profile composition

The core is stable; industry meaning is composed through profiles. The hierarchy is:

DPF-FPAW core
  → reusable facet profiles
  → category baseline
  → leaf-archetype delta
  → organization composition and overrides
  → jurisdiction / contract / deployment overlays

12.1 Required facets

An ArchetypeProfile MUST compose or explicitly mark not applicable:

12.2 Composition rules

• A profile MUST declare ID, version, purpose, applicability, inherited facets, requirements, vocabulary, mappings, owner, and effective period.
• Core MUST requirements cannot be weakened.
• Applicable requirements compose by union. Applicable controls compose only through the deterministic meet rule for their declared constraint axis; “most restrictive” is not a free-text judgment.
• Vocabulary may relabel a concept but MUST NOT silently change its meaning.
• Conflicts become explicit ConformanceClaims/Gaps; they are never silently resolved.
• Local extensions MUST be namespaced and MUST NOT mutate the built-in archetype definition.
• not-applicable MUST carry a scope-specific rationale and reviewer.
• Multi-archetype organizations MUST compose every active primary/secondary BusinessProduct, DigitalProduct, and value-flow facet, reconcile shared resources/coworkers, and surface conflicts.

Each composable control MUST declare one merge axis and normalized unit. Candidate 0.1.0 defines:

Composition first decomposes a control that spans several axes into atomic constraints that retain the source control ID, authority, scope, and evidence. It then resolves any declared lossless categorical mappings to one canonical value, normalizes units, and applies each axis meet. A lossless mapping MUST be a total one-to-one mapping for the values in scope; otherwise the values are incomparable.

For any member-set axis, let Required = union(requiredMembers), Allowed = intersection(allowedMembers) with an undeclared allowed set treated as the axis universe, and Prohibited = union(prohibitedMembers). The effective set is Allowed - Prohibited. A member in both Required and Prohibited, or any Required member absent from the effective set, is a composition conflict. Prohibition therefore prevents execution while the claim remains unsatisfied; it does not silently erase the requirement. Controls with different authorities or scopes are not combined until Appendix B proves they apply to the same subject, period, and decision.

An empty intersection, inverted interval, incompatible unit, incomparable authority source, or simultaneous minimum/maximum that cannot both hold is a composition conflict. It produces an unsatisfied requirement and Gap; precedence in Appendix B may identify the governing authority but MUST NOT fabricate a meet. A Profile extension that adds a merge axis MUST publish its partial order, normalization, meet operation, conflict predicate, and evidence.

12.3 Coverage manifest

A generated or mechanically checked manifest MUST assert for every current unique leaf:

• exactly one category baseline
• BusinessProduct classification and at least one value proposition
• all four portfolio roots with placement or justified non-applicability
• one or more operating patterns and complete Stage contracts to the claimed resolution
• performer allocation and activity/job/skill references
• physicality, location, resource, material, and custody declarations
• controls, evidence expectations, and outcome measures
• explicit provenance explicit | derived
• evidence maturity template-ready | ops-ready | connector-ready | regulated-ready | sole-platform-ready
• zero unknown/unmapped facets; exceptions include rationale and owner

The source registry remains authoritative. A new leaf without complete facets MUST fail profile coverage rather than inherit an unreported generic fallback.

13. External standards mappings

13.1 Mapping rules

Every external mapping MUST identify:

• standards owner, title, edition/version, canonical URI, and access date
• source concept or requirement identifier without reproducing restricted text
• local concept or requirement identifier
• relationship (adopts | profiles | augments | maps-to | adjacent | out-of-scope)
• semantic relation (exact | close | broad | narrow | related)
• rationale, confidence, known loss or mismatch, reviewer, and review cadence
• SourceUseDecision ID, use status, permitted-use scope, and ContributorAttestation ID when applicable

Unknown license terms default to undetermined and no content processing. An AI system MUST NOT open a restricted or unknown-rights artifact merely to decide whether it may open that artifact. Rights evidence must instead come from a separately accessible public license/rights page, signed permission, the operative agreement, or a qualified human-supplied rights record. An express prohibition for the declared use makes the source excluded. A public abstract, product page, or download link is not permission to process or reproduce the publication. A mapping MUST NOT imply endorsement, certification, or standards-body status.

13.1.1 Source-use decisions and contributor-origin material

Every source/use pair MUST have a complete SourceUseDecision before any of these actions:

• AI or automated access to non-public, restricted, unknown-rights, or contributor-origin content
• use of external content to substantiate normative text, an exact or close mapping, a conformance claim, copied/transformed content, or generated artifacts
• storage, reproduction, repository distribution, sublicensing, or external submission of a source asset or protected expression

A public page used only to identify a title, owner, version, canonical URI or reproducible owner-approved resolver, or research target MAY instead have a SourceCitation. A SourceCitation MUST identify those fields plus access date and orientation scope, MUST be reference-only, MUST NOT represent a license determination, and MUST NOT support normative text, a claimed correspondence, or conformance evidence. Public availability alone never qualifies a source as permitted-public.

Each SourceUseDecision binds one exact artifact or one explicitly enumerated immutable source set to one declared use and has exactly one status:

• permitted-public — the declared use is authorized by a public license or public-domain basis
• permitted-contributor — the declared use is authorized for a bounded contributor-origin source
• permitted-operator — the authenticated operator/source custodian authorized bounded private technical analysis and independently expressed mapping; this does not authorize quotation, reproduction, redistribution, sublicensing, external submission, or an external conformance claim
• reference-only — bibliographic or identifier reference is allowed, but protected expression is not an input
• excluded — an applicable term expressly prohibits the declared access or use
• undetermined — the rights basis is unresolved; treatment defaults to reference-only and the material MUST NOT be processed or incorporated

A SourceUseDecision MUST record:

• source artifact, title, owner, edition/version, locator, access date, intended use, and use status
• claimed rightsholder, contributor, member organization, and employer/assignment context when relevant
• governing public license, contract, permission, retained-use clause, or other asserted rights basis
• exact contribution scope and locator, contribution kind, and whether it is sole, separable joint, collective-work, work-for-hire, assigned, or undetermined
• separate permissions for AI processing, quotation, paraphrase, transformation, storage, reproduction, repository distribution, sublicensing under the repository license, and external submission
• excluded coauthor, editor, publisher, employer, standards-body, confidential, and third-party material
• attribution/trademark conditions, evidence, reviewer, decision/effective dates, expiry, and revocation terms

Grouping is permitted only when every enumerated source has the same owner, rights basis, intended use, status, permission matrix, exclusions, reviewer, and dates. Otherwise each source requires a separate decision. A summary row or a decision ID without these resolved fields is not a complete SourceUseDecision.

A natural-person contributor MAY supply a clean-room statement, excerpt, source asset, or concept description as a new permitted-contributor source when a ContributorAttestation establishes every applicable field above and grants the intended use. Acceptance covers only the specifically identified, separable contribution and permissions. It MUST NOT extend to:

• collective-work wording, clause structure, numbering, editorial synthesis, or definitions not demonstrated to be the attestor’s authorized contribution
• a coauthor’s, editor’s, employer’s, publisher’s, standards body’s, or third party’s material
• a published figure, table, logo, or trade dress unless rights to that exact artifact are evidenced
• trademark use beyond accurate nominative reference
• confidential material, external conformance/certification, or an adoption, endorsement, or ownership claim

The member-rights distinction is explicit. The Open Group’s current Membership Terms define the Member as the member company or organization, treat contributed Information and resulting Material as The Open Group intellectual property, and reserve to the Member the continuing right to use the Information it contributed. A named individual’s acknowledgement therefore proves participation, not by itself personal ownership, the member organization’s authorization, contribution boundaries, or a license to the compiled Material. The agreement actually governing the contribution controls.

When the attestor is also the DPF Standards Steward, or joint authorship, employment, assignment, work-for-hire, or collective-work rights are implicated, an independent human rights reviewer MUST accept the SourceUseDecision before contributor-origin expression is incorporated into an adopted normative version, the source asset itself is redistributed or sublicensed, or an external submission relies on the claimed rights. An authenticated clean-room design statement may support a candidate’s independently expressed semantics under a bounded decision; adoption remains gated. Contributor provenance cannot be represented as a current external requirement or authoritative interpretation without an authorized edition and the applicable standards process.

13.2 Orientation references, not mapping records

The following table is research orientation only. Its rows are deliberately non-conformant as external mapping records because they do not carry the complete fields required by Section 13.1. No row may be used as evidence for FPAW-MAP-001; a production mapping registry must create a separate complete record for each claimed correspondence.

APQC’s Process Classification Framework is useful prior art for cross-industry and industry-specific taxonomies, but APQC artifacts carry version- and artifact-specific license and attribution terms. This standard does not import the taxonomy. Implementers MUST obtain and review the applicable license before mapping APQC content. The same reference-only rule applies to ISO/IEC full text and artifact-specific material from CSDM, SCOR, TM Forum, BIAN, ISA, GS1, or other licensors.

13.3 Source-validated IT4IT Reference Architecture 3.0.1 bridge

These records are independently expressed, source-reviewed mappings under SUD-C24A-COMPILED-2026-08-01; they are not reproduced functional criteria or an IT4IT conformance claim. The following common envelope applies to every value-stream, functional-group, functional- component, supporting-function, key-data-object, and cardinality row in Section 13.3; each row supplies its source identifier, FPAW target, semantic relation or the related default, and known loss.

StandardMapState records whether the source-to-FPAW semantic correspondence has been source reviewed; present-verified here means that this envelope and the cited comparison were reviewed. It does not mean that any DPF Product, ServiceNow record, or customer implementation conforms. A concrete implementation BindingState remains present-unverified until its objects, versions, relations, system-of-record controls, and evidence are inspected.

13.3.1 Value streams and functional groups

The 33 primary functional components remain grouped as follows; this is orthogonal to the seven rows above. A value stream uses components across groups, and a component may participate in several streams. The two Financial Management components are supporting components, not a fifth primary group.

The controlled registry below expands all 33 primary functional components plus the two Financial Management components. The key-data-object names and single logical controlling component are source facts; the final column states the FPAW system-of-record boundary and does not transfer operational ownership to this standard or to EaReferenceModelElement.

These six supporting functions and their chapter-level component descriptions are advisory/non-normative in IT4IT 3.0.1. Their FPAW projections are extension points, not imported IT4IT conformance obligations.

13.3.2 Digital Product and Service Offer backbones

IT4IT Digital Product is not an exact synonym for FPAW DigitalProduct. The source concept may be a service, physical item, or digital item when software is essential to the offered outcome, an offer or contract and price/showback exist, and software/resources have an active lifecycle. FPAW therefore maps it to a composite graph with exactly one BusinessProduct projection, 1..* essential DigitalProduct/system realizations, 1..* Offerings, and economics. 0..* ConsumptionAgreements and 0..* Desired/Actual instance projections are contingent: they arise only when an offer is accepted and fulfillment/runtime exists, so they are not prerequisites for defining the Digital Product. Only when the value sold is itself software or a digitally delivered capability is the local DigitalProduct a close primary component projection. Human-labor-led and non-digital products remain FPAW BusinessProducts outside IT4IT’s Digital Product definition.

The Service Contract mapping is conditional, not a union object. The logical-service record is the template from which terms can be offered; the physical-service record is the instance created for consumption. An adapter MUST retain template/instance subtype, status, originating Offering, and instantiation trace and MUST NOT materialize the template as an accepted ConsumptionAgreement.

The Product Release-to-Service Offer seam is an explicit Release Blueprint relation. FPAW names the logical relation realizes-offer-through-release-blueprint; an adapter MAY use a dedicated blueprint object or a versioned relation carrying release, offer, compatibility, environment, and effective-period fields, but MUST NOT collapse Product Release and Service Offer.

IT4IT §11.9.2 uses the relationship cardinalities to state maximum shape and globally does not prescribe mandatory participation. Owner-section prose such as “belongs to” or “one or more” remains valuable context, but an adapter MUST preserve source notation, normalized bounds, direction, participationSpecified=false, and any source conflict, and it MUST NOT convert that prose into an IT4IT minimum or silently strengthen 0..1 to exactly one. A stricter minimum must be an independently evidenced implementation rule and be reported separately from the source cardinality. Data-flow arrows are integration triggers, not process-flow or guaranteed one-way information semantics. Each IT4IT key data object is controlled by exactly one logical functional component, while one component may control several objects. A DPF adapter MUST record that logical owner and the concrete operational system of record; EaReferenceModel and EaReferenceModelElement are reference/assessment definitions, never operational object stores.

The source prescribes no direct Product Release-to-Service Offer cardinality. The seam is mediated by Product Release Blueprint, and the two explicit conflict rows above retain the source’s incompatible presentations instead of silently synthesizing n:m, 1:n, or n:1 as one authoritative rule.

The FPAW R0–R5 resolution depths and IT4IT Levels 1–5 are orthogonal. Implementations may report a qualified relation—typically R0/R1 to Level 1 context, R2 to Level 2, R3/R4 across Level 3 and implementation-specific Level 4, and R5 adjacent to Level 5 operational evidence—but MUST NOT assert numeric equivalence.

13.4 Source-validated CSDM 5 and AICT bridge

These are standard-level semantic mappings under SUD-CSDM-LOCAL-2026-08-01. The following common envelope applies to every concept and relation row in Section 13.4; each row adds its source identifier, FPAW target, semantic relation or sentinel, and known loss.

A StandardMapState of present-verified means the source concept and FPAW relation were reviewed; a concrete ServiceNow adapter BindingState remains present-unverified until its family/release, plugins, table dictionary, relationship directions, lifecycle choices, and sample records are fingerprinted. absent is a verified extension boundary: the named source does not provide the FPAW construct and the adapter must preserve FPAW/TAK authority rather than fabricate an equivalence.

The table uses none only as a sentinel when StandardMapState is absent; it is not an asserted Section 13.1 semantic relation. Every asserted mapping uses one of exact, close, broad, narrow, or related in the source-to-target direction defined by Section 3.3.

The following source cardinalities and prescribed directions constrain an adapter. An arrow supplies an implementation relationship, not permission to merge endpoint identities.

CSDM’s domain progression and per-object Life Cycle Stage/Status pair are independent state systems. Product Instance synchronization among CI, Asset, and Install Base does not synchronize the Product Model and MUST NOT be projected as FPAW release approval, AI binding state, subject status, work state, or evidence verification. CSDM also contains publication-sensitive class-label inconsistencies; therefore every physical adapter binding MUST carry ServiceNow family/release, active plugins, dictionary/table/relationship fingerprints, source page/version, known conflict, reviewer, and date.

The bridge’s anti-collapse rule is normative: BusinessProduct, Product Model, DigitalProduct, design, release, asset, package, deployment intent/event, DigitalProductInstance, ServiceInstance/runtime CI, ServiceDefinition, Offering, ConsumptionAgreement, Entitlement, catalog item, UsageOccurrence, AgentSubject, AIProductOperatingBinding, WorkAssignment, and Evidence MUST retain distinct identities and typed relations. An adapter may create several explicit projections from one source record, but it MUST report projection level, direction, cardinality, provenance, and known loss.

13.5 Industry-standard profiles

Industry mappings belong in versioned profile facets, not in the core. A profile SHOULD select authoritative sources for the actual regulated or transaction boundary—for example BIAN in banking, HL7 FHIR in healthcare data exchange, NIEM in public-sector information exchange, TM Forum in telecommunications, GS1 in supply chains, or jurisdiction-specific law and professional doctrine.

Selection MUST be based on applicability, version, license, and actual implementation evidence. A category label alone is not proof that a standard applies to every leaf or WorkUnitDefinition.

14. Conformance model

14.1 Profiles

A conformance claim includes the Core profile plus any claimed profiles:

Profile dependency and minimum claimable depth are normative:

Profile scope is non-vacuous. A claim MUST contain the profile’s characteristic anchors below; objects outside the declared scope remain outside the claim, but an empty characteristic scope cannot earn conformance:

An implementation MUST NOT claim a profile below its minimum depth or omit a dependency. It conforms only if every applicable MUST in the union of the exact membership expressions above, the selected facet manifest, and Core is satisfied with acceptable evidence.

A Gap may document that a mandatory anchor is missing during a readiness assessment, but it is not the anchor and cannot make the scope non-empty. Any Gap against a mandatory characteristic anchor blocks conformance to that profile until the required object exists and the Gap is verified closed.

Two conditional closures are additive to every row above and prevent requirements from disappearing through an escape path: a claim that records or references any Gap MUST add FPAW-GAP-*, and a claim that asserts any external mapping or candidate binding MUST add FPAW-MAP-*. A not-assessed or unsatisfied RequirementStatus, or a requirement carrying an active waiver record, is not itself a Gap; if the implementation creates a Gap from it, the Gap family becomes part of the exact membership expression.

Resolution is cumulative: an Rn assessment includes R0 through Rn and cannot selectively omit a lower level. A catalog row becomes depth-applicable when assessed depth is at least its Minimum depth, subject to profile membership and object applicability. Because each profile’s minimum claimable depth equals or exceeds the deepest requirement in its membership, a shallower exercise is only a readiness/gap assessment; it is not profile conformance.

Achieved depth is derived, not declared: it is the deepest Rn for which all mandatory anchors, applicable requirement objects, upward/downward traces, and required evidence through Rn have been assessed. The implementation statement records both requested and achieved depth; conformance uses the lower of the two and cannot claim a profile whose minimum is deeper.

Every requirement ID inherits a default applicability predicate from its family:

A row’s own conditional text may narrow this default, but every exclusion MUST carry the Section 4.1 applicability decision. Profile membership and applicability are different axes: a requirement can belong to a profile yet be not-applicable only with that evidence.

14.2 Implementation statement

A claim MUST state:

• standard and profile versions
• organization, BusinessProduct, DigitalProduct, ValueStream, workforce, deployment, and jurisdiction scope
• requested and derived achieved resolution depth R0–R5
• requirement applicability and status
• evidence references, provenance, confidence, freshness, verifier, and verification method
• deviations/waivers, owner, rationale, expiry, and review date
• external mappings, SourceUseDecision status/ID, permitted-use scope, and ContributorAttestation ID when applicable

Requirement status uses exactly:

• satisfied
• partial
• unsatisfied
• not-applicable
• not-assessed

Implementation state is a separate axis:

• defined
• mapped
• implemented
• verified
• operated

Evidence verification status is also a separate axis:

• verified
• provisional
• unverified
• stale
• not-required

StandardMapState uses exactly absent | present-unverified | present-verified. It reports whether a source-to-FPAW semantic correspondence is absent, proposed but not source-reviewed, or source-reviewed. BindingState uses exactly absent | present-unverified | present-verified independently for a concrete edition/object/relation/system-of-record binding in one implementation. The identical tokens do not make the axes interchangeable: a present-verified StandardMapState does not verify an adapter, and a verified adapter does not change the standard-level map. Both are distinct from AIProductOperatingBinding.bindingState, whose Product/subject lifecycle vocabulary is defined in Section 11.3.

MappingConfidence uses unknown | low | medium | high, optionally accompanied by a calibrated 0..1 value and method. It, StandardMapState, BindingState, ImplementationState, and EvidenceVerificationStatus are separate axes. None may be collapsed into a single status.

14.3 Evidence rules

• Missing mandatory evidence sets RequirementStatus to not-assessed and EvidenceVerificationStatus to unverified; it never implies satisfaction.
• Derived evidence MUST retain its method, inputs, source versions, and confidence.
• Lower-confidence projections MUST NOT overwrite a human-verified assessment.
• Runtime evidence MUST identify the relevant deployed version and effective policy/profile.
• Evidence MUST be re-evaluated after an applicable standard/profile change or material BusinessProduct, DigitalProduct, or operating-profile change.
• SHOULD deviations require a recorded rationale even when they do not block conformance.
• A waiver MUST be scoped, owned, reasoned, time-bounded, and reviewed.
• A waiver records governance acceptance or temporary risk treatment only. It does not change an unsatisfied MUST to satisfied; the claim remains nonconformant unless the governing profile applies a tailoring point expressly delegated by the owning core requirement and satisfies its evidence contract. A profile cannot invent an exception to a core MUST.
• DPF’s archetype readiness ladder is an implementation-evidence ladder, not an external certification ladder.

14.4 Machine-readable projection

A conforming implementation SHOULD publish a machine-readable implementation statement. JSON, JSON-LD/RDF, ArchiMate exchange, or another governed representation may be used. If RDF is used, SHACL SHOULD express conformance constraints, SKOS SHOULD express concept mappings, and PROV-O SHOULD express evidence attribution.

At minimum, the exchange representation MUST preserve:

• canonical object type/ID/version, organization scope, owner, and effective period
• GovernedAspect kind-definition reference, target, placement, uniqueness/non-overlap assertion, and split/merge/supersession lineage
• relation subject/object IDs and versions, canonical direction/key, owner, effective period, and evidence
• intended Outcome targets separately from append-only OutcomeObservations and their measure, acceptance, provenance, confidence, and verifier fields
• BusinessProduct-to-DigitalProduct realization plus the separate product/deployment lineage: DigitalProduct → DigitalProductDesign → DigitalProductRelease → DigitalProductAsset → DeploymentPackage → DeploymentIntent → Deployment → DigitalProductInstance → ServiceInstance, with distinct IDs, versions, directions, cardinalities, owners, states, and effective periods
• the separate consumption lineage: Offering → ConsumptionAgreement → Entitlement → UsageOccurrence, preserving optional agreement/entitlement/usage participation and the provider/consumer identities
• typed joins rather than one forced serial chain: release-blueprint relations join DigitalProductRelease to Offering; request/agreement/entitlement and fulfillment relations may join consumption to DeploymentIntent; realization/exposure relations join DigitalProductInstance and ServiceInstance to the offered service while retaining every endpoint identity
• WorkUnitDefinition executionMedia, connectivityMode, applicable PHY-* decisions, authoritative completion evidence, and physical-resource/custody references
• AllocationDecision pattern, complete atomic WorkAssignment set, ActivityDefinition-or-Role responsibilities, Performer/Principal references, and the one Collaboration when required
• WorkforceTransitionAssessment state/version, immutable snapshots, baseline/target partitions, predecessor/successor mappings, people treatment, rollback/fallback, and verification evidence
• AIProductOperatingBinding state and uniqueness fields, the pairwise AIProductBindingCompatibility relations, effective-time TAK-JSI qualification/deployment, and the WorkAssignment/evidence references that select one current binding
• Profile IDs/versions/dependencies, characteristic anchors, merge-axis controls, and applicability
• requested/achieved depth plus each requirement’s applicability, RequirementStatus, waiver reference, evidence references, and verifier
• Evidence type/integrity/provenance/time/freshness/verification fields and derived-method lineage
• Gap target/observation, assessment scales, verification state/history, closure evidence, and canonical work reference or disposition rationale
• external mappings, source notation and normalized bounds, direction, participation-known flag, source-conflict/known-loss fields, standard-map state separately from implementation BindingState, SourceUseDecision status/IDs, applicable ContributorAttestation references, and permitted-use scope

Round-tripping a diagram or a single score without these fields is insufficient.

15. Gap-analysis model

15.1 Gap types

Gap.type uses a controlled vocabulary:

missing | partial | misaligned | unverified | stale | duplicate | orphaned | obsolete | under-controlled | over-constrained | incompatible.

15.2 Gap dimensions

Every Gap has one primary dimension key and may have related dimension keys:

15.3 Assessment scales

Gap records use these closed scales:

• severity: unknown | informational | low | moderate | high | critical
• gate disposition: none | hard-gate | undetermined, with source authority and reason
• confidence: unknown | low | medium | high, optionally accompanied by a calibrated 0..1 value
• freshness: unknown | current | aging | stale, computed from observedAt, validUntil or a profile-owned maximum age, and assessedAt
• verification state: open | verification-pending | closed | superseded

unknown or undetermined is conservative: it cannot satisfy a mandatory control or reduce prioritization. hard-gate is a blocking disposition reserved for unsatisfied law, rights, safety, or mandatory authority constraints; it is independent of severity. Each profile MUST publish any domain-specific threshold that maps evidence to these shared keys.

Evidence records also use controlled classification:

• type: authoritative-record | execution-receipt | observation | test | attestation | document | projection | inference
• integrity: signature-verified | source-verified | controlled-copy | unverified | failed

Every evidence reference MUST carry type, integrity, provenance, observed/issued time, assessed time, applicable freshness policy, and verification status. A projection or inference cannot become an authoritative record merely because confidence is high.

Gap verification state is independent from backlog/remediation status. A Gap is open when created; it may enter verification-pending only after remediation or an accepted no-remediation disposition has supplied the declared acceptance evidence. It becomes closed only when an authorized verifier confirms that the target is achieved or no longer applicable and records the evidence/decision. A failed verification returns it to open. A closed Gap returns to open when its closure evidence expires or is invalidated while the target/requirement version and scope identity are unchanged; the prior closure event, verifier, evidence, and reopening reason remain in append-only state history. When a target, requirement, Profile, or scope identity/version changes, the existing Gap is not retargeted: if the newly applicable comparison exposes a delta, create a new open successor Gap and mark the prior Gap superseded with that replacement reference. If no new delta exists, retain the closed record and append the re-evaluation event. Backlog completion alone never closes a Gap.

15.4 Gap record

A Gap MUST contain:

• stable key, scope, profile/requirement version, and applicability
• explicit target/requirement and observed state
• type, primary/related dimensions, severity, gate disposition, confidence, and freshness
• verification state, state-change times, verifier, closure/supersession evidence, and replacement Gap when applicable
• every applicable impacted Outcome, BusinessProduct, DigitalProduct, Stage, Capability, work, Performer, and Resource reference; each omitted impact class carries a Section 4.1 applicability decision
• evidence and provenance
• cause hypothesis kept separate from established observation
• business impact, safety/regulatory severity, frequency, load-bearing relevance, and urgency
• remediation alternatives, remediationOwnerPortfolio (or unassigned while triaging), dependent portfolios, and constraints
• rootCausePortfolio only when causal evidence is verified; otherwise the cause remains a hypothesis
• expected acceptance evidence and test when remediation or disposition is proposed
• canonical BacklogItem or equivalent work reference when remediation is planned; otherwise an explicit no-remediation/triage disposition rationale, owner, and review date

A Gap MUST NOT duplicate backlog work status. Remediation progress is read from canonical work; Gap verification state is changed only by the lifecycle and evidence rules above.

15.5 Prioritization

Gap prioritization remains a vector. Safety, legality, rights, and mandatory authority constraints act as hard gates. Other gaps SHOULD expose stakeholder impact, flow criticality, frequency, confidence, cost of delay, remediation effort, dependency leverage, reversibility, and evidence freshness. A single composite percentage MUST NOT conceal these dimensions.

16. Normative requirement catalog

This catalog is the stable requirement index for Candidate 0.1.0. Sections 1–15 define the terms and interpretation context. Requirement IDs remain stable within a major version; changed meaning requires a new ID or major-version change.

16.1 Core semantic requirements

16.2 Four-portfolio requirements

16.3 Product and value-flow requirements

16.4 Work, workforce, and allocation requirements

16.5 Physical and non-digital work requirements

16.6 AI coworker and DigitalProduct requirements

16.7 Profile, mapping, and conformance requirements

16.8 Gap requirements

16.9 Publication-governance requirements

16.10 Requirement verification contract

The numbered rows in Section 16 are the complete stable core requirement index for Candidate 0.1.0. A versioned profile may add requirements only through registered, namespaced IDs; the companion catalog’s FPAW-CAT-* register is part of an Industry-Archetype claim. Normative prose elsewhere in this document defines the interpretation, controlled fields, and tests referenced by these IDs; it does not create a second untracked requirement status. An assessment MUST create one record per applicable core or selected-profile requirement and scope object with:

• requirement ID and standard version
• resolved profile membership and dependency set
• applicability predicate/decision and scope-object reference
• minimum and assessed resolution depth
• RequirementStatus, ImplementationState, and EvidenceVerificationStatus
• evidence IDs, verification method, test-case ID/result, verifier, and assessment date
• one result per atomic clause using this Candidate 0.1.0 decomposition: mandatory keywords are numbered left-to-right as .m1, .m2, and so on; recommendation keywords are numbered left-to-right as .s1, .s2, and so on; entries in a referenced field set are numbered in their published order as .f1, .f2, and so on
• deviation rationale for every applicable SHOULD/SHOULD NOT not followed

All applicable .m* and .f* subtests must pass for the parent row to be satisfied; a partial pass is partial, never an implementation-defined rearrangement of suffixes.

Default verification patterns are:

17. Worked end-to-end traces

These examples are informative. They demonstrate use of the same core across different archetypes; they are not complete jurisdictional operating instructions.

17.1 HVAC maintenance agreement with AI dispatch

The AI dispatcher can recommend or execute assignment only within its authority and qualification. It cannot infer a technician’s license, declare physical repair complete, or turn a DigitalProduct release into permission to contact a customer or modify a schedule.

17.2 Community bank loan application delta

The same macro-backbone is tailored to disclose/consent, identity/KYC, application capture, eligibility and underwriting, decision/approval, booking, servicing, and retention. Work units separate document extraction, risk analysis, adverse-action reasoning, credit decision, approval, and customer communication because their authority, explainability, data, and legal consequences differ.

A shared document or scheduling coworker may be reused. A financial decision coworker requires a specialized profile when regulation, model risk, adverse-action evidence, or delegated decision authority differs. Human approval is required where the applicable policy or law requires it—not merely because the performer is AI.

17.3 Warehouse custody delta

The warehouse sells custody, storage, and handling, not the client’s inventory. The profile inserts receive/store and dispatch custody transitions, records owner/custodian and condition at every transfer, and adds lot/serialization, count, segregation, cold-chain, bonded, or dangerous-goods controls where applicable. A scanner or AI allocation decision is not proof that goods moved; the authoritative inventory/custody event and its provenance provide the evidence.

18. DPF implementation baseline and convergence plan

This section is an informative, source-derived baseline as of 2026-08-01. It is not a claim about every live customer organization’s operational state.

18.1 Current coverage

• The authoritative source contains 25 categories and 107 unique leaf archetypes with 574 item templates.
• All 107 can derive an operational-value-stream projection, but the current stage shape lacks the complete work/performer/resource/evidence contract defined here.
• 69 leaves have explicit activation profiles; 38 do not.
• 66 leaves have explicit four-portfolio decompositions; 41 rely on missing or legacy inference.
• Only two leaves declare an explicit productMix; most business Products are derived from item templates.
• 59 leaves contain legacy Request-to-Fulfill metadata; 30 explicit decompositions contain no other lifecycle label. Neither fact is acceptable as evidence of an external lifecycle mapping.
• The occupation registry has six profiles across healthcare, trades, and agriculture. The two agriculture profiles declare a WSID profession family but still have null governance-profile references; no profile is thereby proven job-qualified.
• The platform has 70 agent definitions: 19 active, 50 defined, and one draft Farm & Ranch Steward. Two of 11 coworker-service seeds declare archetype coverage; a seed or draft is not a deployment, qualification, or conforming coworker profile.
• The current workforce projection can create a DigitalProduct record for every active Agent, but it does not by itself prove the offer, economic treatment, accepted-consumption terms, instance readiness, and lifecycle evidence required for the FPAW managed-product qualification; a managed instance is additionally required only for an operated implementation-state claim.
• Six specialized metric-pack registrations exist: five target current leaves and one (independent-hotel) is orphaned from the current 106-leaf registry; the remaining leaves rely on generic metrics.
• Thirty-one leaves derive one or more trust gates and 76 do not; field-dispatch has rich type definitions but no configured built-in profile registry.
• Four of 25 categories currently meet the mechanically checked Tier-2 depth floor; 21 remain grandfathered gaps.
• Current readiness claims are template-ready; no category has source evidence here for a blanket ops-ready, connector-ready, regulated-ready, or sole-platform-ready claim.

These are gaps, not failures of the standard. They establish an honest starting point for applying it.

18.2 Existing substrate to reuse

18.3 Priority convergence backlog

The documentation release reserves approximately 20% of its effort for convergence. The following implementation work is deliberately identified rather than prematurely built:

1. normalize stable portfolio slugs and retire camelCase/legacy aliases at adapter boundaries
2. widen or layer Manufacturing and Delivery and Foundational definitions to include the business’s physical/service delivery and shared non-digital foundations
3. separate local lifecycle keys, legacy functional groups, candidate external identifiers, and industry stages into typed vocabularies; do not promote legacy exact fields before authorized review
4. remove blanket Request-to-Fulfill fallback and require evidence-bearing DigitalProduct bindings
5. expand the thin Stage projection into the Stage contract, with typed capability relations
6. apply multi-archetype composition consistently to BusinessProduct, DigitalProduct, capability, and ValueStream projections
7. converge performer assignment on canonical Principal so humans, AI, robots, partners, crews, and mixed allocations can be represented honestly
8. establish a shared job/activity/skill/competence crosswalk that reuses TAK-JSI rather than creating another qualification model
9. replace critical JSON-only coworker applicability, activity, authority, and portfolio axes with typed/versioned relations when a real consumer workflow is proven
10. preserve empty coworker applicability as a gap; add explicit governed-universal coverage
11. add an evidenced AI-coworker DigitalProduct qualification state, a referentially constrained AIProductOperatingBinding across release, operating profile, GAID subject, and deployment, and pairwise AIProductBindingCompatibility evidence for overlapping bindings; keep projected records explicitly candidate until proven
12. define BusinessProduct/DigitalProduct realization dependencies only after endpoint and consumer evidence, and clarify the existing DigitalProduct-only dependency model
13. reconcile the several conformance/gap ledgers and project them into one report without creating a fifth general-purpose Gap authority
14. add a canonical generalized intended-Outcome target and Objective→Outcome→OutcomeObservation cardinalities without recasting append-only ProductOutcomeObservation evidence as intent
15. refactor the Work Case source registry and Workroom read model into the Section 9.5 WorkUnitDefinition/WorkOccurrence bridge, preserving domain authorities and existing cycle, evidence, estimate, token/tool telemetry, backlog, worktree, PR, and receipt records

18.4 Documentation convergence in this release

This release updates canonical pointers and status notes in the existing business-operating-model, archetype-value-stream, workforce, agent-standards, and architecture-orientation documents. Their historical decisions remain traceable; superseded claims no longer compete with this standard.

19. Governance and versioning

19.1 Ownership

The accountable authority is the human DPF Standards Steward designated by the platform maintainer. AI coworkers and contributors may research, draft, test, and review changes but cannot adopt a normative version. The steward approves version state, owns the conformance policy, and records any delegation or succession of that role.

The standard owns only enterprise value, four-portfolio placement, operating-flow, work-allocation, AI dual-aspect, cross-standard traceability, conformance, and gap semantics. Changes to commerce, IT4IT, archetypes, TAK, GAID, TAK-JSI, WSID, or domain records occur in their owning sources.

19.2 Versioning

• major version: incompatible semantic or normative change
• minor version: additive concepts, requirements, profiles, or mappings
• patch version: clarification or erratum with no changed conformance meaning

Profiles, mappings, conformance claims, qualifications, and implementation evidence have independent versions or immutable IDs. Updating this standard MUST NOT silently update them.

19.3 Change process

A normative change proposal MUST include:

• problem and evidence
• affected requirement/concept/profile IDs
• compatibility and migration impact
• source/standards research, SourceUseDecisions, ContributorAttestations, and independent rights review when Section 13.1.1 requires it
• archetype and implementation impact
• alternatives and decision record
• conformance-test and documentation impact

New industry content should normally enter through a profile. A core change requires proof that the concern is universal and cannot be expressed without weakening consistency.

Candidate-to-adopted transition requires all of the following:

1. complete requirement/profile/test coverage and a passing conformance-grammar audit
2. documented SourceUseDecisions and source-rights review, including independent human acceptance of contributor-origin use when Section 13.1.1 requires it, and closure of every Section 20.5 source gap whose gate disposition is stop
3. independent architecture/semantic review with material findings resolved
4. an approved human decision record from the DPF Standards Steward
5. versioned publication and migration/compatibility notice

Submission to an external standards body is a separate state. DPF ownership remains until that body accepts a contribution under its own process; no submission or liaison implies adoption.

19.4 Review cadence

• core standard: at least annually and after material IT4IT Reference Architecture, DPPM guide, or DPF architecture change
• external mapping: on source version change or at its declared cadence
• archetype profile: on source-registry, regulation, BusinessProduct/DigitalProduct, or operating-model change
• conformance/evidence: on expiry, incident, material change, or declared surveillance cadence

20. Research and source register

20.1 Bounded operator-source locators

The authenticated task log is the immutable evidence store for these three source records. Their opening markers identify the exact turns without republishing the full messages. Later explanations are not included; each future source requires a new locator and SourceUseDecision.

20.2 Complete SourceUseDecision records

Every record below resolves the complete Section 13.1.1 field contract. “No” in an action matrix means the decision supplies no permission for that action, even if a legacy repository path or runtime currently performs it. Such current behavior is a Gap, not evidence of authorization.

20.2.1 SUD-MB-FPAW-DIRECT-2026-08-01

20.2.2 SUD-MB-CSDM-DIRECT-2026-08-01

20.2.3 SUD-MB-RIGHTS-STATEMENT-2026-08-01

20.2.4 SUD-C24A-COMPILED-2026-08-01

20.2.5 SUD-G252-COMPILED-2026-08-01

20.2.6 SUD-W205-2026-08-01

20.2.7 SUD-PORTFOLIO-WORKBOOK-V2-2026-08-01

20.2.8 SUD-PORTFOLIO-WORKBOOK-V3-2026-08-01

20.2.9 SUD-IT4IT-CRITERIA-WORKBOOK-2026-08-01

20.2.10 SUD-TAXONOMY-V3-COMPOSITE-2026-08-01

20.2.11 SUD-CSDM-LOCAL-2026-08-01

20.2.12 Historical source-access events

SAE-2026-08-01-01 — C24A/G252 front matter

SAE-2026-08-01-02 — AICT/CSDM orientation review

20.3 ContributorAttestation records

20.3.1 CA-MB-2026-08-01-IT4IT-PROVENANCE

20.3.2 CA-MB-2026-08-01-CSDM-PROVENANCE

20.4 SourceCitation register

Every row is reference-only, accessed 2026-08-01, and supplies orientation or identity context only. It is not a license decision or normative/mapping/conformance evidence.

DPF-owned code, schema, portfolio/archetype registries, TAK, GAID, TAK-JSI, and existing design documents are current implementation evidence, subject to their own provenance. “DPF-owned” is not used to launder inherited fields whose lineage is unresolved.

20.5 Current source-control and ingestion gaps

These are observed repository nonconformities, not permissions granted by this candidate. The candidate may be reviewed as an independently expressed draft, but adoption, a repository conformance claim, external publication, or standards-body submission is blocked while any stop row applies. Removing, quarantining, or rights-clearing pre-existing assets and derived outputs is a separate governed remediation action; this documentation release does not silently perform it.

20.6 Originality and licensing declaration

The candidate authorship process asserts that this document’s prose, diagrams, requirement IDs, metamodel, profile system, and conformance grammar are independently expressed DPF work. The four-portfolio, DigitalProduct, and AI-coworker idea lineage includes Mark Bodman’s bounded direct statements under the decisions above. This assertion excludes taxonomy_v3.json, the reference workbooks, compiled publications, and inherited data fields whose provenance is unresolved.

This document does not reproduce IT4IT Reference Architecture functional criteria, exact G252 four-role wording, APQC taxonomies, ISO/IEC clauses, CSDM diagrams/table definitions, or other restricted artifacts. Implementers remain responsible for obtaining authoritative editions and licenses. DPF mappings are not a substitute for those sources.

Appendix A — DPF logical mapping

This appendix is informative and intentionally identifies conceptual gaps rather than inventing parallel persistence.

Appendix B — Interpretation precedence

For semantic and control interpretation, apply this order:

1. applicable law and regulation, non-waivable rights, and mandatory safety constraints
2. valid contract and explicit human/organizational authority, only within tier 1 bounds
3. the authoritative external standard for the concept it owns, when lawfully accessible and applicable
4. this standard for its owned bridge semantics
5. the applicable versioned profile and organization override
6. informative examples, white papers, videos, projections, and inferred defaults

A profile or organization override may tighten a higher-tier requirement but MUST NOT weaken it. Current DPF schema, registry, and domain records are authoritative evidence of as-is implementation state; they do not outrank FPAW target semantics for concerns FPAW owns. A conflict between current state and target requirement is recorded as a Gap. All conflicts MUST be recorded; precedence determines temporary interpretation, not silent deletion of the discrepancy.