# Vercy AI instruction - YAML 1.2 (JSON-compatible)
{
"vercy": "1.0-draft",
"publication": {
"status": "published",
"adjudicationStatus": "reviewable-draft",
"publishableCanonical": false,
"generatedAt": "2026-08-25T10:55:56Z",
"synthesisSha256": "fbc34d6c9ed694e8195bc5e4a4d73fdfccbcc1f52990a747cce93cd7b2736b8a",
"providerMode": "dual-provider",
"providers": [
"Claude",
"Grok"
],
"waivedProviders": []
},
"metaModel": {
"id": "WM-ACT-006",
"registryId": "vr.wm-act-006",
"name": "Task",
"version": "0.3.0-research.1",
"previousVersions": [],
"entryKind": "aggregate",
"family": "World Models",
"category": "Activities and processes",
"industry": [
"Cross-industry"
],
"domain": [
"ACT.TSK"
],
"tags": [
"task",
"act.tsk"
],
"status": "published"
},
"canonicalUrl": "https://ver.cy/models/wm-act-006-task/",
"sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-006",
"model": {
"registry_id": "vr.wm-act-006",
"model_id": "WM-ACT-006",
"name": "Task",
"entry_kind": "aggregate",
"purpose": "Provide a format-neutral governed context model for a task instance: a stateful, assignable unit of work with identity, authorisation, lifecycle, timing, inputs, outputs and evidence, reusable by human and automated performers.",
"scope_statement": "The model governs the task instance as a consistency boundary: the task record plus the parts that have no independent identity outside it (status history, role assignments, deadlines, typed inputs and outputs, progress measurements, provenance entries). Reusable task definitions, plans, work orders, projects, parties and produced documents are separate models referenced by typed edges. Storage and interface (JSON, YAML, Markdown, Git, MCP, MongoDB) are projections of these semantics, not part of them.",
"in_scope": [
"Identity of a task instance and correlation of identifiers across exchanging systems",
"Binding of an instance to a reusable task definition and its version",
"Classification: task type, performer kind, priority scale and severity",
"Authorisation and actionability level (proposal, plan, order) and the authorising reference",
"Role assignment, claiming, release, delegation and forwarding",
"Canonical state model, terminality, blocking and failure classification",
"State transition events with event time and recording time separated",
"Deadlines, escalations, recurrence and temporal anchors",
"Decomposition into subtasks and typed dependencies with lead or lag",
"Typed inputs, completion and acceptance criteria, outputs and produced artifacts",
"Progress and effort measurement, execution provenance and evidence",
"Access control, confidentiality classification, retention and deletion of the task record",
"Alignment crosswalks to external task vocabularies and exchange integrity controls"
],
"out_of_scope": [
"Project and programme portfolio semantics (WM-ACT-005)",
"Plan and schedule authoring, baselining and versioning (WM-ACT-008)",
"Work order raising, contractual authorisation and billing (WM-ACT-007)",
"Process and case definition languages themselves (BPMN process models, CMMN case models)",
"Party, organisation, role directory and competency registries",
"Document, dataset and physical deliverable content models referenced as outputs",
"Calendar event and appointment scheduling of people's time",
"Issue, defect and change-request domain semantics beyond alignment",
"Cost, rate, invoicing and financial accounting of work",
"Robot motion-level or actuator-level decomposition of physical actions"
],
"boundary_notes": [
{
"neighbor": "Task definition or template (BPMN task, CMMN task, FHIR ActivityDefinition, WS-HumanTask task definition)",
"distinction": "A definition is a reusable, versioned specification of work; this model governs the instance that instantiates it and tracks its execution state. The instance carries a version-pinned reference to the definition, never a copy that can silently diverge.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-010",
"SRC-014"
]
},
{
"neighbor": "Project (WM-ACT-005)",
"distinction": "A project is a temporary endeavour with objectives, budget and governance; a task is a single unit of assignable work inside it. Project membership is an edge on the task, not an attribute the task owns.",
"source_refs": [
"SRC-002",
"SRC-003"
]
},
{
"neighbor": "Work order (WM-ACT-007)",
"distinction": "A work order is the authorising instrument that permits and groups execution; the task records the authorisation reference and its actionability level but does not model the authorising instrument's own approval chain.",
"source_refs": [
"SRC-001",
"SRC-002"
]
},
{
"neighbor": "Plan or schedule (WM-ACT-008)",
"distinction": "A plan is independently versioned and places tasks in time; the task holds planned and actual anchors plus a version-pinned plan reference. When planned dates disagree with the plan, the plan is authoritative unless the Dimension states otherwise.",
"source_refs": [
"SRC-002",
"SRC-004"
]
},
{
"neighbor": "Provenance activity record (PROV-O Activity)",
"distinction": "A PROV Activity is a retrospective assertion about something that occurred; a task is prospective and assignable, with deadlines, owners and terminal failure states. The task emits provenance; it is not itself only provenance.",
"source_refs": [
"SRC-006"
]
},
{
"neighbor": "Calendar event (iCalendar VEVENT) and appointment",
"distinction": "An event occupies a time block and has its own status vocabulary (TENTATIVE, CONFIRMED, CANCELLED); a to-do or task has completion semantics (NEEDS-ACTION, IN-PROCESS, COMPLETED, CANCELLED), a due time and percent complete.",
"source_refs": [
"SRC-003",
"SRC-015"
]
},
{
"neighbor": "Change request or issue (OSLC ChangeRequest)",
"distinction": "A change request is a domain record about a requested change with review predicates; a task is the unit of work that may implement it. Alignment is one-directional and lossy because OSLC expresses state as independent boolean predicates.",
"source_refs": [
"SRC-008",
"SRC-013"
]
},
{
"neighbor": "Message or notification (WS-HumanTask notification, A2A Message)",
"distinction": "A notification is one-way and expects no response or completion tracking; a task is stateful and must reach a terminal state. Messages requesting missing input attach to a task but are not tasks.",
"source_refs": [
"SRC-001",
"SRC-009"
]
},
{
"neighbor": "Outcome or procedure record (FHIR Procedure)",
"distinction": "An outcome record asserts a change made to a subject; a task tracks whether the work was requested, performed and completed. Both may exist for the same real-world action and must not be merged.",
"source_refs": [
"SRC-002"
]
}
]
},
"sources": [
{
"id": "SRC-001",
"title": "Web Services – Human Task (WS-HumanTask) Specification Version 1.1",
"organization": "OASIS BPEL4People Technical Committee",
"url": "https://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cs-01.html",
"version_or_date": "Committee Specification 01, 17 August 2010",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:05:00Z",
"relevance": "Normative source for the ten-state human task lifecycle, the seven generic human roles, people assignment mechanisms, priority, deadlines and escalations, composite subtasks and task instance data categories."
},
{
"id": "SRC-002",
"title": "FHIR Release 5 Resource Task",
"organization": "Health Level Seven International (HL7)",
"url": "https://hl7.org/fhir/R5/task.html",
"version_or_date": "FHIR v5.0.0 (R5), Trial Use, Maturity Level 3",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:07:00Z",
"relevance": "Normative element set for a task instance (status, intent, businessStatus, basedOn, partOf, focus, owner, executionPeriod, restriction, input, output) and explicit boundary statements against request, definition and procedure resources."
},
{
"id": "SRC-003",
"title": "RFC 5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar)",
"organization": "Internet Engineering Task Force (IETF)",
"url": "https://datatracker.ietf.org/doc/html/rfc5545",
"version_or_date": "RFC 5545, September 2009",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:09:00Z",
"relevance": "Normative VTODO component: required UID and DTSTAMP, DUE and DURATION exclusivity, PERCENT-COMPLETE, PRIORITY scale, STATUS values, RELATED-TO PARENT/CHILD/SIBLING, RRULE, LOCATION, GEO, RESOURCES, CLASS and SEQUENCE."
},
{
"id": "SRC-004",
"title": "RFC 9253 Support for iCalendar Relationships",
"organization": "Internet Engineering Task Force (IETF)",
"url": "https://www.rfc-editor.org/rfc/rfc9253.html",
"version_or_date": "RFC 9253, August 2022 (updates RFC 5545)",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:11:00Z",
"relevance": "Normative dependency relationship types FINISHTOSTART, FINISHTOFINISH, STARTTOSTART, STARTTOFINISH and DEPENDS-ON, the GAP parameter for lead and lag, and the LINK, CONCEPT and REFID properties."
},
{
"id": "SRC-005",
"title": "RFC 3339 Date and Time on the Internet: Timestamps",
"organization": "Internet Engineering Task Force (IETF)",
"url": "https://www.rfc-editor.org/rfc/rfc3339",
"version_or_date": "RFC 3339, July 2002",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:12:00Z",
"relevance": "Normative timestamp grammar requiring seconds and an explicit time offset, the -00:00 convention for unknown local offset, leap second handling and string ordering conditions."
},
{
"id": "SRC-006",
"title": "PROV-O: The PROV Ontology",
"organization": "World Wide Web Consortium (W3C)",
"url": "https://www.w3.org/TR/prov-o/",
"version_or_date": "W3C Recommendation, 30 April 2013",
"source_type": "ontology",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:14:00Z",
"relevance": "Entity, Activity and Agent model with used, wasGeneratedBy, wasAssociatedWith, actedOnBehalfOf, startedAtTime and endedAtTime, plus qualified Association with hadRole and hadPlan for attributing execution."
},
{
"id": "SRC-007",
"title": "Activity Streams 2.0 Vocabulary",
"organization": "World Wide Web Consortium (W3C)",
"url": "https://www.w3.org/TR/activitystreams-vocabulary/",
"version_or_date": "W3C Recommendation, 23 May 2017",
"source_type": "ontology",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:15:00Z",
"relevance": "Activity model with actor, object, target, result, origin and instrument, and object properties for published, updated, startTime, endTime, duration, attributedTo, context and audience."
},
{
"id": "SRC-008",
"title": "OSLC Change Management Version 3.0 Part 2: Vocabulary",
"organization": "OASIS Open Projects (OSLC Open Project)",
"url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-vocab.html",
"version_or_date": "OASIS Standard, 26 May 2021",
"source_type": "schema",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:17:00Z",
"relevance": "ChangeRequest vocabulary with state, priority and severity individuals, closeDate, parent and relatedChangeRequest links, and the boolean predicates approved, closed, fixed, inProgress, reviewed and verified."
},
{
"id": "SRC-009",
"title": "Agent2Agent (A2A) Protocol Specification",
"organization": "A2A Project (Linux Foundation)",
"url": "https://a2a-protocol.org/latest/specification/",
"version_or_date": "Version 1.0.0 (latest released), accessed August 2026",
"source_type": "first-party-doc",
"primary_source": true,
"authority_tier": 2,
"accessed_at": "2026-08-25T09:19:00Z",
"relevance": "Agent-to-agent task object with server-generated id, contextId, TaskStatus with state and timestamp, terminal state immutability, input-required and auth-required interruption states, and Artifact output structure."
},
{
"id": "SRC-010",
"title": "Business Process Model and Notation (BPMN) Version 2.0.2",
"organization": "Object Management Group (OMG)",
"url": "https://www.omg.org/spec/BPMN/2.0.2/",
"version_or_date": "Version 2.0.2, formal/13-12-09, January 2014",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:21:00Z",
"relevance": "Establishes that process and task definitions are modelled and interchanged independently of running instances and are precise enough to be translated into executable software components; cited only for the definition-versus-instance boundary."
},
{
"id": "SRC-011",
"title": "schema.org ActionStatusType and Action",
"organization": "Schema.org community (W3C Schema.org Community Group)",
"url": "https://schema.org/ActionStatusType",
"version_or_date": "Version 30.0, 19 March 2026",
"source_type": "schema",
"primary_source": true,
"authority_tier": 2,
"accessed_at": "2026-08-25T09:23:00Z",
"relevance": "Minimal four-value action status vocabulary (potential, active, completed, failed) and the Action property set (agent, object, instrument, participant, result, location, startTime, endTime, error) used as a coarse alignment target."
},
{
"id": "SRC-012",
"title": "NIST Special Publication 800-53 Revision 5, Security and Privacy Controls for Information Systems and Organizations",
"organization": "National Institute of Standards and Technology (NIST)",
"url": "https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final",
"version_or_date": "Revision 5, September 2020 (updates through 10 December 2020)",
"source_type": "public-authority",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:25:00Z",
"relevance": "Establishes Access Control and Audit and Accountability as required control families for systems handling task records; cited for the existence and necessity of access enforcement and audit record controls, not for individual control text."
},
{
"id": "SRC-013",
"title": "OSLC Change Management Version 3.0 Part 1: Specification",
"organization": "OASIS Open Projects (OSLC Open Project)",
"url": "https://docs.oasis-open-projects.org/oslc-op/cm/v3.0/os/change-mgt-spec.html",
"version_or_date": "OASIS Standard, 26 May 2021",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:27:00Z",
"relevance": "States that a standard state set must be extensible per resource type and lifecycle, and defines RDF-based linking and reified link labelling for relationships between work records."
},
{
"id": "SRC-014",
"title": "Case Management Model and Notation (CMMN) Version 1.1",
"organization": "Object Management Group (OMG)",
"url": "https://www.omg.org/spec/CMMN/1.1/About-CMMN/",
"version_or_date": "Version 1.1, formal/16-12-01, December 2016",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T09:29:00Z",
"relevance": "Confirms a separate metamodel and interchange format for case models in which work is planned discretionarily rather than fully predefined; cited only for the boundary between case or process definitions and task instances."
},
{
"id": "SRC-015",
"title": "iCalendar RFC 5545 Section 3.8.1.11 STATUS (reference reproduction)",
"organization": "iCalendar.org",
"url": "https://icalendar.org/iCalendar-RFC-5545/3-8-1-11-status.html",
"version_or_date": "Reproduction of RFC 5545 (September 2009), accessed August 2026",
"source_type": "secondary",
"primary_source": false,
"authority_tier": 3,
"accessed_at": "2026-08-25T09:31:00Z",
"relevance": "Used only to disambiguate a competing interpretation: it confirms that VTODO STATUS is limited to four values and that ACCEPTED, DECLINED, TENTATIVE and DELEGATED belong to PARTSTAT, not STATUS."
},
{
"id": "SRC-016",
"title": "HL7 FHIR Release 5 Resource Task",
"organization": "HL7 International",
"url": "https://hl7.org/fhir/task.html",
"version_or_date": "FHIR R5 v5.0.0, 26 March 2023",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:00:00Z",
"relevance": "Normative healthcare Task resource covering scope, state machine, REST queue usage, focus versus basedOn, inputs and outputs, definition binding, suspend and resume of children, and boundaries with Procedure and Request resources."
},
{
"id": "SRC-017",
"title": "HL7 FHIR Release 5 Task Detailed Descriptions",
"organization": "HL7 International",
"url": "https://www.hl7.org/fhir/task-definitions.html",
"version_or_date": "FHIR R5 v5.0.0, 26 March 2023",
"source_type": "schema",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:05:00Z",
"relevance": "Element-level schema for identifier, instantiatesCanonical, instantiatesUri, basedOn, groupIdentifier, partOf, status, statusReason, businessStatus, intent, priority, doNotPerform, code, description, focus, for, encounter, requestedPeriod, executionPeriod, authoredOn, lastModified, requester, requestedPerformer, owner, performer, location, reason, restriction, input and output."
},
{
"id": "SRC-018",
"title": "HL7 FHIR ValueSet Task Status",
"organization": "HL7 International",
"url": "https://hl7.org/fhir/valueset-task-status.html",
"version_or_date": "FHIR R5 v5.0.0, 26 March 2023",
"source_type": "classifier",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:10:00Z",
"relevance": "Required Task status codes: draft, requested, received, accepted, rejected, ready, cancelled, in-progress, on-hold, failed, completed, entered-in-error, with definitions used to ground lifecycle findings."
},
{
"id": "SRC-019",
"title": "schema.org Action",
"organization": "Schema.org",
"url": "https://schema.org/Action",
"version_or_date": "V30.0, 2026-03-19",
"source_type": "schema",
"primary_source": true,
"authority_tier": 2,
"accessed_at": "2026-08-25T16:15:00Z",
"relevance": "Web vocabulary for an action performed by an agent and participants upon an object, with instrument, location, startTime, endTime, result, error, actionStatus and identifier, used as an alignment rather than a work-item schema."
},
{
"id": "SRC-020",
"title": "RFC 5545 Internet Calendaring and Scheduling Core Object Specification, section 3.6.2 To-Do Component",
"organization": "Internet Engineering Task Force",
"url": "https://icalendar.org/iCalendar-RFC-5545/3-6-2-to-do-component.html",
"version_or_date": "RFC 5545, September 2009",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:20:00Z",
"relevance": "Normative VTODO as an action-item or assignment with required UID and DTSTAMP, optional CLASS, COMPLETED, DUE, DURATION, DTSTART, PERCENT-COMPLETE, PRIORITY, STATUS, SUMMARY, ORGANIZER, ATTENDEE, RELATED-TO, RRULE, ATTACH, RESOURCES, VALARM, and the non-nesting rule."
},
{
"id": "SRC-021",
"title": "Microsoft Graph v1.0 todoTask resource type",
"organization": "Microsoft",
"url": "https://learn.microsoft.com/en-us/graph/api/resources/todotask?view=graph-rest-1.0",
"version_or_date": "Microsoft Graph v1.0, document date 2024-07-22, page updated 2025-12-03",
"source_type": "first-party-doc",
"primary_source": true,
"authority_tier": 2,
"accessed_at": "2026-08-25T16:40:00Z",
"relevance": "Personal and work-item Task API with id that changes when moved between lists, status notStarted/inProgress/completed/waitingOnOthers/deferred, importance, due/start/completed/reminder times, recurrence, checklistItems, linkedResources, attachments and ISO 8601 timestamps."
},
{
"id": "SRC-022",
"title": "OMG Business Process Model and Notation Specification Version 2.0.2",
"organization": "Object Management Group",
"url": "https://www.omg.org/spec/BPMN/2.0.2/About-BPMN",
"version_or_date": "BPMN 2.0.2, January 2014",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:45:00Z",
"relevance": "Authoritative process-modeling standard that FHIR Task may instantiate via instantiatesUri. Used to bound Task instance against process-definition semantics; detailed BPMN Task-type taxonomy is not taken from this landing page and is recorded as a gap."
},
{
"id": "SRC-023",
"title": "ISO 21502:2020 Project, programme and portfolio management — Guidance on project management",
"organization": "International Organization for Standardization",
"url": "https://www.iso.org/obp/ui/#iso:std:iso:21502:en",
"version_or_date": "ISO 21502:2020",
"source_type": "standard",
"primary_source": true,
"authority_tier": 1,
"accessed_at": "2026-08-25T16:55:00Z",
"relevance": "Public terms define a work package as a group of activities with defined scope, deliverable, timescale and cost, used to keep Task finer-grained than work package and outside project-management method ownership. Full clauses beyond the public preview remain a paywalled evidence gap."
}
],
"structure": {
"bundles": [
{
"id": "b-identity-and-definition",
"name": "Identity and definition",
"description": "What this task is, how it is identified, which reusable definition it instantiates, and how it is classified.",
"rationale": "Every cited specification makes identity and typing mandatory or near-mandatory (iCalendar UID and DTSTAMP are REQUIRED, FHIR requires status and intent, A2A requires a server-generated id), and all of them separate a reusable definition from a running instance. Without this bundle no other context can be attached reliably.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-010"
],
"layers": [
{
"id": "l-task-identity",
"name": "Task identity and definition binding",
"description": "Identifier authority, uniqueness scope, correlation across systems, and the versioned link from instance to definition.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-010"
],
"findings": [
{
"id": "f-task-identity-and-identifiers",
"name": "Task instance identity and identifier correlation",
"description": "Which identifier is authoritative for a task instance, who mints it, in what namespace it is unique, and how it correlates with identifiers held by other systems.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009"
],
"questions": [
{
"id": "q-identity-authoritative",
"text": "Which system of record holds the authoritative identifier for this task instance, and what is that identifier value?",
"kind": "identity",
"answer_data": [
"Master system code and its identifier scheme URI",
"Authoritative identifier value",
"Minting authority and assignment time"
]
},
{
"id": "q-identity-uniqueness-scope",
"text": "Within what namespace is the identifier guaranteed unique, and is uniqueness global or scoped to one server?",
"kind": "constraint",
"answer_data": [
"Namespace or IRI base",
"Uniqueness scope (global, tenant, server)",
"Collision handling rule"
]
},
{
"id": "q-identity-correlation",
"text": "Which additional business, group or external identifiers correlate this task across exchanging systems?",
"kind": "interoperability",
"answer_data": [
"Business identifier values with scheme",
"Group identifier shared by sibling tasks",
"External UID or IRI held by partner systems"
]
},
{
"id": "q-identity-recurrence",
"text": "If the work repeats, is each occurrence separately identified or derived from one recurring definition?",
"kind": "identity",
"answer_data": [
"Recurrence identifier of the occurrence",
"Identifier of the recurring parent",
"Occurrence expansion rule"
]
}
],
"data_elements": [
{
"id": "de-task-id",
"name": "Task identifier",
"description": "Authoritative identifier of the task instance, resolved by the identity priority rule.",
"value_kind": "identifier",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-009"
]
},
{
"id": "de-task-business-identifier",
"name": "Business identifier",
"description": "Human-facing or partner-system identifier carried alongside the authoritative identifier, each with its scheme.",
"value_kind": "identifier",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-008"
]
},
{
"id": "de-task-group-identifier",
"name": "Group identifier",
"description": "Identifier shared by tasks created together or fulfilling one authorisation.",
"value_kind": "identifier",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-recurrence-identifier",
"name": "Recurrence occurrence identifier",
"description": "Identifies one occurrence of a recurring task series.",
"value_kind": "identifier",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
}
],
"artifacts": [
{
"id": "art-task-record",
"name": "Canonical task record",
"description": "The addressable record carrying the task's identity, classification, state, assignment and temporal anchors, independent of serialisation.",
"media_or_form": [
"Structured record in any governed serialisation",
"RDF or JSON-LD graph node",
"FHIR Task resource instance",
"iCalendar VTODO component",
"Row in a task table or document store"
],
"serial": false,
"identity_strategy": "Authoritative master-system identifier; otherwise a governed IRI or iCalendar-style UID; otherwise a UUID or ULID minted by the adopting Dimension and recorded with its minting authority.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-009"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-definition-binding-and-version",
"name": "Binding to a reusable task definition and its version",
"description": "Which definition, process model or case model the instance realises, at which version, and how divergence from it is authorised and detected.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-010",
"SRC-014"
],
"questions": [
{
"id": "q-definition-source",
"text": "Which reusable task definition or process model does this instance instantiate, and at which pinned version?",
"kind": "definition",
"answer_data": [
"Definition reference (canonical URI)",
"Definition version identifier",
"Definition owner"
]
},
{
"id": "q-definition-divergence",
"text": "Where does the running instance deviate from its definition, and who authorised the deviation?",
"kind": "validation",
"answer_data": [
"Deviation description and affected fields",
"Authorising party and time",
"Whether the deviation is permitted by the definition"
]
},
{
"id": "q-definition-propagation",
"text": "How are later changes to the definition propagated to instances that are already running?",
"kind": "lifecycle",
"answer_data": [
"Propagation policy (pin, migrate, fork)",
"Migration record for affected instances",
"Cutover time"
]
},
{
"id": "q-definition-discretionary",
"text": "Was this task planned in advance by a definition or added discretionarily during execution?",
"kind": "decision",
"answer_data": [
"Origin flag (predefined or discretionary)",
"Party who added it",
"Justification"
]
}
],
"data_elements": [
{
"id": "de-instantiates-definition",
"name": "Instantiated definition reference",
"description": "Version-pinned reference to the task, process or case definition realised by this instance.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-010"
]
},
{
"id": "de-definition-version",
"name": "Definition version",
"description": "Version label or revision of the referenced definition at binding time.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-definition-deviation",
"name": "Definition deviation note",
"description": "Recorded divergence between the instance and its definition, with authorisation.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001",
"SRC-014"
]
}
],
"artifacts": [
{
"id": "art-task-definition",
"name": "Reusable task definition",
"description": "The versioned specification the instance realises, including its interface, roles, deadlines and completion behaviour.",
"media_or_form": [
"Process or case model element",
"Activity definition resource",
"Human task definition document",
"Machine-readable workflow description"
],
"serial": false,
"identity_strategy": "Canonical definition URI plus version label, owned by the publishing package; never re-minted by consuming instances.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-010",
"SRC-014"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-task-designation-and-description",
"name": "Descriptive identity and confidentiality class",
"description": "Human-readable name, description, categories and iCalendar CLASS distinguish the Task for people and access control without serving as identity.",
"source_refs": [
"SRC-017",
"SRC-020",
"SRC-021"
],
"questions": [
{
"id": "f-task-designation-and-description-q01",
"text": "What title or summary and free-text description should a human or agent use to recognize this Task?",
"kind": "definition",
"answer_data": [
"title",
"description",
"disambiguating_description"
]
},
{
"id": "f-task-designation-and-description-q02",
"text": "Which categories, tags or outlook-style labels classify this Task for queues and search?",
"kind": "classification",
"answer_data": [
"categories",
"labels"
]
},
{
"id": "f-task-designation-and-description-q03",
"text": "Is the Task public, private or confidential, and what privacy rules follow from that class?",
"kind": "privacy",
"answer_data": [
"confidentiality_class",
"privacy_handling_rule"
]
}
],
"data_elements": [
{
"id": "f-task-designation-and-description-data01",
"name": "Title or summary",
"description": "Short human-readable name; FHIR code text, Graph title or iCalendar SUMMARY.",
"value_kind": "text",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-017",
"SRC-020",
"SRC-021"
]
},
{
"id": "f-task-designation-and-description-data02",
"name": "Description",
"description": "Free-text explanation of what is to be performed.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-017",
"SRC-020"
]
},
{
"id": "f-task-designation-and-description-data03",
"name": "Categories",
"description": "Classification labels such as iCalendar CATEGORIES or Graph categories.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-020",
"SRC-021"
]
},
{
"id": "f-task-designation-and-description-data04",
"name": "Confidentiality class",
"description": "iCalendar CLASS of PUBLIC, PRIVATE or CONFIDENTIAL, or an aligned access class.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-020"
]
}
],
"artifacts": [
{
"id": "f-task-designation-and-description-artifact01",
"name": "Task narrative",
"description": "Human-readable title, body and category set used in task lists and renderings.",
"media_or_form": [
"narrative",
"item-body",
"html-rendering"
],
"serial": true,
"identity_strategy": "Inherit the Task master-system identifier; version the narrative separately from identity.",
"source_refs": [
"SRC-001",
"SRC-021"
]
}
],
"inline_only_rationale": null
}
]
},
{
"id": "l-task-classification",
"name": "Classification, priority and severity",
"description": "Controlled typing of the work and the ranking scales that drive queueing and escalation.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008"
],
"findings": [
{
"id": "f-task-type-and-category",
"name": "Task type, category and performer kind",
"description": "The controlled codes that classify the kind of work and whether it is to be performed by a person, an automated agent, or both.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-004",
"SRC-009"
],
"questions": [
{
"id": "q-type-code",
"text": "What controlled code classifies the kind of work this task represents?",
"kind": "classification",
"answer_data": [
"Task type code with code system and version",
"Free-text label for display",
"Additional categories or tags"
]
},
{
"id": "q-type-performer-kind",
"text": "Is the work to be performed by a human, by an automated agent or service, or by a combination?",
"kind": "classification",
"answer_data": [
"Performer kind code",
"Required performer type or capability",
"Whether an actual owner is required at all"
]
},
{
"id": "q-type-taxonomy-authority",
"text": "Which taxonomy governs these codes, who may extend it, and how are local extensions marked?",
"kind": "authority",
"answer_data": [
"Governing vocabulary identifier and version",
"Extension procedure and approver",
"Local extension namespace"
]
}
],
"data_elements": [
{
"id": "de-task-code",
"name": "Task type code",
"description": "Coded classification of the work, carrying code system and version.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-004"
]
},
{
"id": "de-task-categories",
"name": "Task categories",
"description": "Additional non-exclusive categories or tags applied to the task.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-performer-kind",
"name": "Performer kind",
"description": "Whether execution is by a human, an automated agent, or a mixed team.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-009"
]
}
],
"artifacts": [
{
"id": "art-task-type-code-list",
"name": "Task type code list",
"description": "The governed vocabulary of task types, categories and performer kinds, with versions and deprecation notes.",
"media_or_form": [
"Concept scheme or code system",
"Value set or enumeration list",
"Tabular code list with version column"
],
"serial": false,
"identity_strategy": "Governed vocabulary IRI plus version; individual concepts identified by concept IRI, never by label.",
"source_refs": [
"SRC-002",
"SRC-004",
"SRC-008"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-priority-urgency-and-severity",
"name": "Priority scale, urgency and severity",
"description": "How ranking is expressed, in which direction the scale runs, and how business impact is kept distinct from scheduling urgency.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008"
],
"questions": [
{
"id": "q-priority-scale",
"text": "Which priority scale is in force, in which direction does it run, and what does an absent value mean?",
"kind": "measurement",
"answer_data": [
"Scale identifier and permitted range",
"Direction (low number highest or lowest)",
"Meaning of an unset or undefined value"
]
},
{
"id": "q-priority-versus-severity",
"text": "Is business impact recorded separately from scheduling urgency on this task?",
"kind": "classification",
"answer_data": [
"Severity code",
"Priority code or value",
"Rule linking the two, if any"
]
},
{
"id": "q-priority-mapping-loss",
"text": "How is the local priority mapped when exchanged with a system using a different scale, and what precision is lost?",
"kind": "interoperability",
"answer_data": [
"Mapping table entry",
"Loss note for unmappable values",
"Direction of the mapping"
]
},
{
"id": "q-priority-change-authority",
"text": "Who may change a task's priority after creation, and is the change recorded with a reason?",
"kind": "authority",
"answer_data": [
"Roles permitted to change priority",
"Prior and new value with reason",
"Change time and actor"
]
}
],
"data_elements": [
{
"id": "de-priority-value",
"name": "Priority value",
"description": "Ranking value expressed on a named scale; invalid without its scale identifier.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003"
]
},
{
"id": "de-priority-scheme",
"name": "Priority scale identifier",
"description": "Names the scale and its direction so that bare integers cannot be misread.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-003"
]
},
{
"id": "de-severity",
"name": "Severity",
"description": "Coded business impact of the task's subject matter, distinct from scheduling urgency.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-008"
]
}
],
"artifacts": [],
"inline_only_rationale": "Priority and severity are inline coded scalars on the task record; they have no separable carrier. The only detachable object is the scale definition itself, which is governed as part of the task type code list artifact (art-task-type-code-list) so that a value and its scale are versioned together."
}
]
}
]
},
{
"id": "b-authority-and-assignment",
"name": "Authority, oversight and assignment",
"description": "Why the task exists, what authorises it, who is accountable, and who may or must perform it.",
"rationale": "WS-HumanTask defines seven generic human roles and multiple assignment mechanisms; FHIR separates intent, requester, owner and requested performer; PROV-O supplies delegation and on-behalf-of chains. Authorisation and accountability are therefore first-class and cannot be inferred from state or assignment alone.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-006",
"SRC-012"
],
"layers": [
{
"id": "l-authorization-intent",
"name": "Authorisation, intent and oversight",
"description": "Actionability level, the authorising reference, and the accountability chain when work is delegated to people or automated agents.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-006",
"SRC-009",
"SRC-012"
],
"findings": [
{
"id": "f-authorization-intent-and-actionability",
"name": "Authorisation reference and actionability level",
"description": "Whether the task is a proposal, a plan or an authorised order, which instrument authorises it, and what limits that authorisation carries.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-013"
],
"questions": [
{
"id": "q-intent-level",
"text": "At what level of actionability does this task exist: proposal, plan, or authorised order?",
"kind": "authority",
"answer_data": [
"Intent code",
"Whether execution may begin under this intent",
"Escalation path to a higher intent"
]
},
{
"id": "q-authorization-source",
"text": "Which request, work order or higher-level authorisation caused this task to exist, and is it still valid?",
"kind": "provenance",
"answer_data": [
"Authorising instrument reference",
"Validity period of the authorisation",
"Party who issued it"
]
},
{
"id": "q-authorization-limits",
"text": "What does the authorisation permit and forbid in terms of repetitions, period and named recipient?",
"kind": "constraint",
"answer_data": [
"Permitted repetition count",
"Period within which fulfilment is sought",
"Named recipient or performer restriction"
]
}
],
"data_elements": [
{
"id": "de-intent",
"name": "Intent",
"description": "Actionability level of the task, governing whether work may lawfully begin.",
"value_kind": "code",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-based-on",
"name": "Authorising reference",
"description": "Typed reference to the request, work order or authorisation the task fulfils.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-013"
]
},
{
"id": "de-requester",
"name": "Requester",
"description": "Party that asked for the task to be done.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002"
]
}
],
"artifacts": [],
"inline_only_rationale": "The authorising instrument is a work order or request owned by the sibling model WM-ACT-007; duplicating it here would create two masters for one authorisation. The task therefore carries only an inline intent code plus a typed, resolvable reference and the recorded validity window of that authorisation."
},
{
"id": "f-oversight-and-delegated-authority",
"name": "Accountability, oversight and automated performer limits",
"description": "Who stays accountable when execution is delegated, what an automated performer may do unattended, and which role combinations are prohibited.",
"source_refs": [
"SRC-001",
"SRC-006",
"SRC-009",
"SRC-012"
],
"questions": [
{
"id": "q-oversight-accountable-party",
"text": "Which party remains accountable for the outcome when execution is delegated to another person or to an automated agent?",
"kind": "ownership",
"answer_data": [
"Accountable party reference",
"On-behalf-of chain from performer to accountable party",
"Whether accountability transfers on delegation"
]
},
{
"id": "q-oversight-agent-limits",
"text": "What may an automated performer do without a human confirmation step, and how is that boundary enforced?",
"kind": "security",
"answer_data": [
"Permitted unattended action set",
"Confirmation checkpoints and their triggers",
"Enforcement point and failure behaviour"
]
},
{
"id": "q-oversight-separation-of-duties",
"text": "Which combinations of requester, performer and approver are prohibited on the same task?",
"kind": "constraint",
"answer_data": [
"Prohibited role combinations",
"Detection rule and enforcement point",
"Recorded waivers with approver"
]
},
{
"id": "q-oversight-intervention",
"text": "Who may intervene to suspend, reassign or terminate the task, and on what stated grounds?",
"kind": "decision",
"answer_data": [
"Intervening roles",
"Permitted grounds",
"Record of the intervention with time and reason"
]
}
],
"data_elements": [
{
"id": "de-acted-on-behalf-of",
"name": "On-behalf-of chain",
"description": "Chain linking an executing agent to the human or organisational party bearing responsibility.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006"
]
},
{
"id": "de-oversight-checkpoint",
"name": "Oversight checkpoint",
"description": "Point at which human confirmation is required before the task may proceed.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-009",
"SRC-012"
]
},
{
"id": "de-excluded-parties",
"name": "Excluded parties",
"description": "Parties that must not become potential or actual owner of this task.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001"
]
}
],
"artifacts": [
{
"id": "art-delegation-record",
"name": "Delegation and authority record",
"description": "Entry asserting that a party acted on behalf of another for this task, with role, grounds and validity.",
"media_or_form": [
"Qualified delegation assertion",
"Signed approval entry",
"Authorisation audit record"
],
"serial": true,
"identity_strategy": "Task identifier plus monotonic sequence within the delegation series; each entry records the delegating and delegated parties and the time the delegation took effect.",
"source_refs": [
"SRC-006",
"SRC-012"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-authorization-basis-versus-focus",
"name": "Based-on authorization versus focus object",
"description": "FHIR basedOn is a higher-level authorization such as a CarePlan. focus is the request being fulfilled or resource being manipulated. They are never the same. for is the beneficiary. doNotPerform inverts the requested action within tight time or phase bounds.",
"source_refs": [
"SRC-016",
"SRC-017",
"SRC-019"
],
"questions": [
{
"id": "f-authorization-basis-versus-focus-q01",
"text": "What higher-level authorization or request created this Task, if any?",
"kind": "relationship",
"answer_data": [
"based_on_refs"
]
},
{
"id": "f-authorization-basis-versus-focus-q02",
"text": "What object, request or resource is this Task acting on, and must subtasks be used if more than one resource is manipulated?",
"kind": "composition",
"answer_data": [
"focus_ref",
"subtask_required_flag"
]
},
{
"id": "f-authorization-basis-versus-focus-q03",
"text": "Who benefits from the Task, and is the Task asking that the action not occur?",
"kind": "constraint",
"answer_data": [
"beneficiary_ref",
"do_not_perform"
]
}
],
"data_elements": [
{
"id": "f-authorization-basis-versus-focus-data01",
"name": "Based-on authorizations",
"description": "Higher-level requests that triggered creation of the Task.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-017"
]
},
{
"id": "f-authorization-basis-versus-focus-data02",
"name": "Focus",
"description": "Request being fulfilled or resource being manipulated.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-017"
]
},
{
"id": "f-authorization-basis-versus-focus-data03",
"name": "Beneficiary",
"description": "Entity who benefits from performance, such as a patient.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-017"
]
},
{
"id": "f-authorization-basis-versus-focus-data04",
"name": "Encounter or context event",
"description": "Healthcare or other event during which the Task originated.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-017"
]
},
{
"id": "f-authorization-basis-versus-focus-data05",
"name": "Do not perform",
"description": "True if the Task prohibits the specified action.",
"value_kind": "boolean",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-017"
]
},
{
"id": "f-authorization-basis-versus-focus-data06",
"name": "Action object",
"description": "schema.org object upon which the action is carried out.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-019"
]
}
],
"artifacts": [
{
"id": "f-authorization-basis-versus-focus-artifact01",
"name": "Fulfillment context",
"description": "Record linking basedOn, focus, beneficiary and prohibition flag for fulfillment Tasks.",
"media_or_form": [
"fulfillment-context",
"request-reference-set"
],
"serial": true,
"identity_strategy": "Identify by Task master-system identifier; referenced requests keep their own master identifiers.",
"source_refs": [
"SRC-016",
"SRC-017"
]
}
],
"inline_only_rationale": null
}
]
},
{
"id": "l-assignment-ownership",
"name": "Assignment, claiming and reassignment",
"description": "How the performer set is resolved, how ownership is taken and released, and how work is delegated or forwarded.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003"
],
"findings": [
{
"id": "f-human-and-agent-role-assignment",
"name": "Role assignment and performer eligibility",
"description": "Which parties hold which role on the task, how the potential performer set is resolved, and what eligibility a performer must satisfy.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-007"
],
"questions": [
{
"id": "q-assignment-roles",
"text": "Which parties hold each role on this task: initiator, potential owners, actual owner, stakeholders, administrators and excluded owners?",
"kind": "ownership",
"answer_data": [
"Role code with party references",
"Assignment time per role",
"Whether the role is mandatory for this task type"
]
},
{
"id": "q-assignment-eligibility",
"text": "What competence, qualification, licence or system capability must a performer hold to be eligible?",
"kind": "requirement",
"answer_data": [
"Required capability or qualification codes",
"Verification source for the qualification",
"Whether eligibility is enforced or advisory"
]
},
{
"id": "q-assignment-resolution",
"text": "How is the potential performer set resolved: by literal party list, by group query, or by expression over task data?",
"kind": "process",
"answer_data": [
"Resolution mechanism identifier",
"Query or expression text with parameters",
"Time of resolution and resulting set"
]
},
{
"id": "q-assignment-empty-set",
"text": "Is an unassigned task valid, and what happens when the potential performer set resolves to empty?",
"kind": "exception",
"answer_data": [
"Whether an actual owner is required",
"Fallback assignment or escalation target",
"State entered when no performer exists"
]
}
],
"data_elements": [
{
"id": "de-role-assignment",
"name": "Role assignment",
"description": "Binding of a party to a named task role, with the time and mechanism of assignment.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002"
]
},
{
"id": "de-actual-owner",
"name": "Actual owner",
"description": "Party currently responsible for performing the task.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002"
]
},
{
"id": "de-potential-owners",
"name": "Potential owners",
"description": "Parties eligible to claim the task before an actual owner exists.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001"
]
}
],
"artifacts": [
{
"id": "art-people-assignment-expression",
"name": "Performer assignment rule",
"description": "The stored rule that resolves parties to task roles, whether a literal list, a group query or a data-driven expression.",
"media_or_form": [
"Logical people group query with parameters",
"Expression over task input data",
"Literal party or group list"
],
"serial": false,
"identity_strategy": "Rule identifier owned by the task definition package plus version; resolved result sets are recorded against the task with their resolution time.",
"source_refs": [
"SRC-001"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-claim-release-and-reassignment",
"name": "Claiming, release, delegation and forwarding",
"description": "The operations that move ownership between parties, the permissions that govern them, and whether responsibility travels with the work.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-015"
],
"questions": [
{
"id": "q-claim-protocol",
"text": "What operation makes a party the actual owner, and may more than one party hold the task simultaneously?",
"kind": "process",
"answer_data": [
"Claim operation and its guard condition",
"Exclusivity rule",
"Time the claim took effect"
]
},
{
"id": "q-claim-release",
"text": "Under what conditions may an owner release the task, and to which state does it return?",
"kind": "exception",
"answer_data": [
"Permitted release conditions",
"Target state after release",
"Notification recipients on release"
]
},
{
"id": "q-delegation-permissions",
"text": "Who is permitted to receive a delegated or forwarded task, and does accountability transfer with it?",
"kind": "access",
"answer_data": [
"Permitted delegatee set code",
"Whether responsibility transfers or is retained",
"Record of the transfer"
]
},
{
"id": "q-participation-response",
"text": "How is a performer's response to an assignment recorded when it differs from the task's own status?",
"kind": "state",
"answer_data": [
"Participation status per assignee",
"Response time",
"Reason for decline or delegation"
]
}
],
"data_elements": [
{
"id": "de-delegation-permission",
"name": "Delegation permission",
"description": "Coded rule stating who may receive the task by delegation or forwarding.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001"
]
},
{
"id": "de-participation-status",
"name": "Participation status",
"description": "Per-assignee response to the assignment, distinct from the task's own status.",
"value_kind": "code",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-003",
"SRC-015"
]
},
{
"id": "de-claim-time",
"name": "Claim time",
"description": "Time at which the current owner took the task, recorded with an explicit offset.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-005"
]
}
],
"artifacts": [],
"inline_only_rationale": "Claim, release, delegation and forwarding are transitions rather than objects: each produces an entry on the append-only transition log artifact (art-state-transition-log), and the current result is inline on the task record as actual owner and participation status. Creating a separate assignment artifact would fork the audit trail into two competing histories."
}
]
}
]
},
{
"id": "b-lifecycle-and-state",
"name": "Lifecycle, state and exceptions",
"description": "The governed state vocabulary, blocking conditions, transition history and unsuccessful endings.",
"rationale": "All five task specifications examined define a state machine, but with 4, 8, 10 and 12 or more values and incompatible terminality rules. A canonical state model with explicit terminality, blocking reasons and a complete transition history is therefore the only defensible basis for interoperation.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-011"
],
"layers": [
{
"id": "l-state-model",
"name": "Canonical state model and blocking",
"description": "The state vocabulary in force, which states are terminal, and how blocked work is represented.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-011",
"SRC-015"
],
"findings": [
{
"id": "f-canonical-state-model",
"name": "State vocabulary, terminality and status qualification",
"description": "The governed set of states, which are terminal, and how coded state is qualified by a reason and a domain-specific business status.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009",
"SRC-011",
"SRC-015"
],
"questions": [
{
"id": "q-state-current",
"text": "What is the task's current state in the governed vocabulary, and when was that state entered?",
"kind": "state",
"answer_data": [
"State code with vocabulary version",
"Time the state was entered",
"Actor who caused the transition"
]
},
{
"id": "q-state-terminality",
"text": "Which states are terminal, and may a terminal task be reopened or must a successor task be created?",
"kind": "lifecycle",
"answer_data": [
"Terminal state list",
"Reopening policy",
"Successor task reference where reopening is prohibited"
]
},
{
"id": "q-state-qualification",
"text": "What reason and domain-specific business status qualify the coded state beyond the enumerated value?",
"kind": "definition",
"answer_data": [
"Status reason text or code",
"Business status code",
"Whether the qualifier affects downstream routing"
]
},
{
"id": "q-state-mapping",
"text": "How does the local state map onto each aligned external vocabulary, and which distinctions cannot be preserved?",
"kind": "interoperability",
"answer_data": [
"Per-target mapping entry",
"Unmappable distinction note",
"Default value used when no mapping exists"
]
}
],
"data_elements": [
{
"id": "de-status",
"name": "Status",
"description": "Current state of the task in the governed state vocabulary.",
"value_kind": "code",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009"
]
},
{
"id": "de-status-reason",
"name": "Status reason",
"description": "Explanation of why the task holds its current state.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-business-status",
"name": "Business status",
"description": "Domain-specific status nuance that the canonical vocabulary deliberately does not encode.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-013"
]
},
{
"id": "de-status-entered-at",
"name": "State entry time",
"description": "Time the current state was entered, with seconds and explicit offset.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-005",
"SRC-009"
]
}
],
"artifacts": [
{
"id": "art-state-model-definition",
"name": "State model definition",
"description": "The declared state list, permitted transitions, guards and terminality flags governing every task of a given type.",
"media_or_form": [
"State transition table",
"State machine graph or diagram",
"Code system of state values with version"
],
"serial": false,
"identity_strategy": "State model IRI plus version, owned by the model package; every task record cites the version of the state model it was validated against.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-013"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-interruption-blocking-and-input-requirements",
"name": "Suspension, blocking and outstanding input requirements",
"description": "Why progress has stopped, exactly what must happen to resume, and how long a stalled task may remain in that condition.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-004",
"SRC-009"
],
"questions": [
{
"id": "q-blocking-cause",
"text": "What is blocking progress: missing input, missing authorisation, an unmet dependency, or a deliberate hold?",
"kind": "exception",
"answer_data": [
"Blocking reason code",
"Reference to the blocking dependency or request",
"Party that imposed a deliberate hold"
]
},
{
"id": "q-blocking-resume-condition",
"text": "What exact condition must be satisfied for work to resume, and who is able to satisfy it?",
"kind": "constraint",
"answer_data": [
"Resume condition expression or description",
"Party able to satisfy it",
"Notification sent to that party"
]
},
{
"id": "q-blocking-timeout",
"text": "How long may the task remain blocked before escalation or automatic termination applies?",
"kind": "temporal",
"answer_data": [
"Maximum blocked duration",
"Escalation or termination action",
"Time blocking began"
]
}
],
"data_elements": [
{
"id": "de-blocking-reason",
"name": "Blocking reason",
"description": "Coded cause of interruption, such as awaiting input, awaiting authorisation or on hold.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-009"
]
},
{
"id": "de-required-input-request",
"name": "Outstanding input request",
"description": "The specific additional information or authorisation being requested before work can continue.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-009"
]
},
{
"id": "de-blocked-since",
"name": "Blocked since",
"description": "Time the task entered its blocked or suspended condition.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-005"
]
}
],
"artifacts": [
{
"id": "art-input-request-message",
"name": "Input or authorisation request message",
"description": "The message sent to a party asking for the input, decision or authorisation that unblocks the task.",
"media_or_form": [
"Structured request message with typed parts",
"Notification to a named recipient",
"Form or prompt presented to a performer"
],
"serial": true,
"identity_strategy": "Message identifier assigned by the sender, correlated to the task identifier and, where present, the conversation or context identifier.",
"source_refs": [
"SRC-001",
"SRC-009"
]
}
],
"inline_only_rationale": null
}
]
},
{
"id": "l-state-history",
"name": "Transition history and unsuccessful endings",
"description": "The recorded sequence of state changes and the classification and handling of failure, rejection and cancellation.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009",
"SRC-012"
],
"findings": [
{
"id": "f-state-transition-events-and-history",
"name": "State transition events and tamper-evident history",
"description": "What is recorded for each transition, how event time is kept distinct from recording time, and how completeness of the history is demonstrated.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-005",
"SRC-006",
"SRC-009",
"SRC-012"
],
"questions": [
{
"id": "q-history-transition-record",
"text": "What is captured for each state transition: prior state, new state, actor, reason and time?",
"kind": "event",
"answer_data": [
"Prior and new state codes",
"Actor and role",
"Reason code or text"
]
},
{
"id": "q-history-event-versus-record-time",
"text": "Is the time a transition occurred recorded separately from the time the system observed or ingested it?",
"kind": "temporal",
"answer_data": [
"Event time with explicit offset",
"Observation or ingestion time with explicit offset",
"Clock source for each"
]
},
{
"id": "q-history-completeness",
"text": "Is the transition history complete and tamper-evident, and how would a missing entry be detected?",
"kind": "evidence",
"answer_data": [
"Sequence numbering scheme",
"Chaining or digest mechanism",
"Gap detection result"
]
},
{
"id": "q-history-subtask-propagation",
"text": "Which transitions on subtasks are propagated to the parent task's history, and which stay local?",
"kind": "relationship",
"answer_data": [
"Propagated event types",
"Parent task reference",
"Propagation rule identifier"
]
}
],
"data_elements": [
{
"id": "de-transition-event",
"name": "Transition event",
"description": "One recorded state change with its prior state, new state, actor and reason.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001",
"SRC-009"
]
},
{
"id": "de-event-time",
"name": "Event time",
"description": "Time the transition actually occurred, in RFC 3339 form with seconds and explicit offset.",
"value_kind": "timestamp",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-005"
]
},
{
"id": "de-recorded-at",
"name": "Recording time",
"description": "Time the transition was observed, received or written by the recording system.",
"value_kind": "timestamp",
"cardinality": "1",
"required": true,
"source_refs": [
"SRC-005",
"SRC-012"
]
}
],
"artifacts": [
{
"id": "art-state-transition-log",
"name": "Append-only transition log",
"description": "The ordered history of state, assignment and priority changes for one task, usable as the audit record for that task.",
"media_or_form": [
"Append-only log entries",
"Provenance graph of start and end events",
"Audit event records",
"Event stream messages"
],
"serial": true,
"identity_strategy": "Task identifier plus a monotonic sequence number that is never reused; each entry carries both event time and recording time and references the digest of the previous entry.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-012"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-failure-cancellation-and-exceptions",
"name": "Failure, rejection, cancellation and error classification",
"description": "How unsuccessful endings are distinguished from one another, what fault detail is retained, and what compensating action follows.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009",
"SRC-011"
],
"questions": [
{
"id": "q-failure-classification",
"text": "How is an unsuccessful ending classified: failed, rejected, cancelled, obsolete, or entered in error?",
"kind": "classification",
"answer_data": [
"Ending classification code",
"Distinguishing criterion applied",
"Party who determined the classification"
]
},
{
"id": "q-failure-fault-detail",
"text": "What fault or error payload is retained, and is it safe to disclose to the requester?",
"kind": "evidence",
"answer_data": [
"Fault payload with type",
"Disclosure classification",
"Redacted variant for external parties"
]
},
{
"id": "q-failure-compensation",
"text": "What compensating, retry or successor action follows, and does it reuse the same task identity?",
"kind": "process",
"answer_data": [
"Compensating or retry action reference",
"Successor task identifier",
"Whether the original identity is reused"
]
}
],
"data_elements": [
{
"id": "de-fault-data",
"name": "Fault data",
"description": "Structured error or fault payload produced by an unsuccessful ending.",
"value_kind": "object",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001",
"SRC-011"
]
},
{
"id": "de-cancellation-requester",
"name": "Cancellation requester",
"description": "Party that requested cancellation and the grounds given.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-009"
]
},
{
"id": "de-retry-of",
"name": "Successor or retry reference",
"description": "Link from a replacement task to the task it supersedes.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-009"
]
}
],
"artifacts": [],
"inline_only_rationale": "Fault payloads, cancellation grounds and successor links are inline operational fields on the task record, and every unsuccessful ending already produces an entry on the transition log artifact. A separate failure artifact would duplicate that entry and create a second, divergent account of the same ending."
}
]
}
]
},
{
"id": "b-time-composition-and-dependency",
"name": "Time, composition and dependency",
"description": "When the task is anchored in time, how it decomposes and groups, and how it depends on other work.",
"rationale": "iCalendar and its relationship extension supply normative temporal anchors, recurrence and four typed dependency relationships with lead and lag; WS-HumanTask supplies deadlines and escalations; FHIR supplies partOf, groupIdentifier and executionPeriod. These are distinct concerns that recur in every task system examined.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-004",
"SRC-005"
],
"layers": [
{
"id": "l-temporal-control",
"name": "Temporal anchors, deadlines and recurrence",
"description": "The time values a task carries, the deadlines that constrain it, the escalations they trigger, and repetition rules.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-005",
"SRC-006",
"SRC-007"
],
"findings": [
{
"id": "f-temporal-anchors-and-timestamps",
"name": "Temporal anchors and timestamp discipline",
"description": "The set of time anchors a task carries, their required format and offset handling, and which clock prevails in a dispute.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-005",
"SRC-006",
"SRC-007"
],
"questions": [
{
"id": "q-time-anchor-set",
"text": "Which time anchors are recorded: authored, planned start, due, actual start, actual end and last modified?",
"kind": "temporal",
"answer_data": [
"Anchor name with value",
"Whether the anchor is planned or actual",
"Source system for each anchor"
]
},
{
"id": "q-time-format-offset",
"text": "Are all time values expressed with seconds and an explicit offset, and how is an unknown local offset represented?",
"kind": "validation",
"answer_data": [
"Format conformance result",
"Offset used per value",
"Handling of unknown local offset"
]
},
{
"id": "q-time-local-context",
"text": "In which local time zone or civil calendar is a deadline meaningful for the performer?",
"kind": "spatial",
"answer_data": [
"Time zone identifier of performance",
"Working calendar reference",
"Whether the deadline is wall-clock or absolute"
]
},
{
"id": "q-time-clock-authority",
"text": "Which clock or system prevails when two systems report different times for the same transition?",
"kind": "provenance",
"answer_data": [
"Authoritative clock source",
"Observed skew",
"Reconciliation rule applied"
]
}
],
"data_elements": [
{
"id": "de-authored-on",
"name": "Authored time",
"description": "Time the task record was created, with seconds and explicit offset.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-005"
]
},
{
"id": "de-planned-start",
"name": "Planned start",
"description": "Time at which work is intended to begin.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-due-at",
"name": "Due time",
"description": "Time by which the task is expected to be completed.",
"value_kind": "timestamp",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-execution-period",
"name": "Execution period",
"description": "Actual start and end of performance as an interval.",
"value_kind": "object",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-006"
]
}
],
"artifacts": [],
"inline_only_rationale": "Temporal anchors are inline scalar fields of the task record and of each transition log entry; they carry no independent content and cannot be dereferenced separately. Their governance lives in the service-layer timestamp rule rather than in a detachable artifact."
},
{
"id": "f-deadlines-escalation-and-recurrence",
"name": "Deadlines, escalation actions and recurrence",
"description": "Which deadlines bind the task, what fires when they pass, and how repeating work is instantiated and closed.",
"source_refs": [
"SRC-001",
"SRC-003",
"SRC-004"
],
"questions": [
{
"id": "q-deadline-types",
"text": "Which deadlines apply, latest start or latest completion, and are they contractual or advisory?",
"kind": "requirement",
"answer_data": [
"Deadline type and value",
"Binding force (contractual or advisory)",
"Source of the deadline"
]
},
{
"id": "q-deadline-escalation-action",
"text": "What escalation fires when a deadline passes, to whom is it directed, and how often does it repeat?",
"kind": "process",
"answer_data": [
"Escalation action type",
"Recipient roles or parties",
"Repetition and cooldown"
]
},
{
"id": "q-recurrence-rule",
"text": "Does this work repeat on a rule, and how is each occurrence instantiated and closed?",
"kind": "temporal",
"answer_data": [
"Recurrence rule expression",
"Occurrence generation policy",
"Closure rule for missed occurrences"
]
},
{
"id": "q-duration-versus-due",
"text": "When both an absolute due time and a duration are present, which one governs?",
"kind": "constraint",
"answer_data": [
"Precedence rule applied",
"Validation result for the conflicting pair",
"Corrective action taken"
]
}
],
"data_elements": [
{
"id": "de-start-deadline",
"name": "Start deadline",
"description": "Latest permitted start time before escalation applies.",
"value_kind": "timestamp",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001"
]
},
{
"id": "de-completion-deadline",
"name": "Completion deadline",
"description": "Latest permitted completion time before escalation applies.",
"value_kind": "timestamp",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001"
]
},
{
"id": "de-recurrence-rule",
"name": "Recurrence rule",
"description": "Rule generating repeated occurrences of the task.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-escalation-action",
"name": "Escalation action",
"description": "Action triggered when a deadline passes, with recipients and repetition.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001"
]
}
],
"artifacts": [
{
"id": "art-escalation-rule",
"name": "Deadline and escalation rule",
"description": "The stored definition of deadlines, their escalation actions and recipients for a class of tasks.",
"media_or_form": [
"Rule expression with trigger and action",
"Notification template with recipient roles",
"Alarm or reminder definition"
],
"serial": false,
"identity_strategy": "Rule identifier within the owning task definition package plus version; firings are recorded against the task on the transition log with their event time.",
"source_refs": [
"SRC-001",
"SRC-003"
]
}
],
"inline_only_rationale": null
}
]
},
{
"id": "l-composition-dependency",
"name": "Decomposition, dependency and plan placement",
"description": "Parent and subtask structure, typed dependencies with lead and lag, and the reference to an independently versioned plan.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-004",
"SRC-008"
],
"findings": [
{
"id": "f-decomposition-and-grouping",
"name": "Parent, subtasks and grouping",
"description": "How a task sits inside a parent, project or work order, how subtasks execute, and how their outcomes assemble into the parent result.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008"
],
"questions": [
{
"id": "q-decomposition-parent",
"text": "Which parent task, work order or project does this task belong to, and is that membership exclusive?",
"kind": "composition",
"answer_data": [
"Parent or container reference with relation type",
"Exclusivity flag",
"Group identifier shared with siblings"
]
},
{
"id": "q-decomposition-subtask-mode",
"text": "Are subtasks executed in parallel or in sequence, and are they created automatically or on demand?",
"kind": "process",
"answer_data": [
"Execution mode code",
"Creation pattern (automatic or manual)",
"Ordering constraint among subtasks"
]
},
{
"id": "q-decomposition-completion-condition",
"text": "What condition over subtask outcomes completes the parent, and how is the parent result assembled?",
"kind": "lifecycle",
"answer_data": [
"Completion condition expression",
"Result aggregation rule",
"Behaviour for still-running subtasks at parent completion"
]
}
],
"data_elements": [
{
"id": "de-part-of",
"name": "Container reference",
"description": "Typed reference to the parent task, work order or project containing this task.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008"
]
},
{
"id": "de-subtask-execution-mode",
"name": "Subtask execution mode",
"description": "Whether subtasks run in parallel or in sequence, and how they are created.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001"
]
},
{
"id": "de-completion-condition",
"name": "Completion condition",
"description": "Expression over subtask outcomes that determines parent completion.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-001"
]
}
],
"artifacts": [],
"inline_only_rationale": "Containment is a typed edge between independently identified task, project and work order records; the parent and the child are each their own artifact. Materialising the hierarchy as a further artifact would create a third copy of a relationship already asserted at both ends, so the edge set is governed with the dependency graph artifact instead."
},
{
"id": "f-inter-task-dependencies-and-gaps",
"name": "Typed dependencies, lead and lag",
"description": "How ordering constraints between tasks are typed, how lead or lag is expressed, and how cycles and cross-system references are handled.",
"source_refs": [
"SRC-003",
"SRC-004",
"SRC-006",
"SRC-008"
],
"questions": [
{
"id": "q-dependency-type",
"text": "What dependency type links this task to another: finish-to-start, start-to-start, finish-to-finish, start-to-finish, or a plain dependency?",
"kind": "relationship",
"answer_data": [
"Dependency type code",
"Referenced task identifier",
"Direction of the constraint"
]
},
{
"id": "q-dependency-gap",
"text": "What lead or lag applies to the dependency, and in which duration units?",
"kind": "measurement",
"answer_data": [
"Gap value as a duration",
"Sign convention (lead negative, lag positive)",
"Calendar basis for the duration"
]
},
{
"id": "q-dependency-integrity",
"text": "How are dependency cycles and dangling references detected and rejected?",
"kind": "validation",
"answer_data": [
"Cycle detection result",
"Dangling reference list",
"Rejection or quarantine action"
]
},
{
"id": "q-dependency-cross-system",
"text": "How is a dependency on a task held in another system or organisation expressed and resolved?",
"kind": "interoperability",
"answer_data": [
"External reference form (URI or UID)",
"Resolution endpoint or contact",
"Staleness handling when the target cannot be resolved"
]
}
],
"data_elements": [
{
"id": "de-dependency-edge",
"name": "Dependency edge",
"description": "One typed ordering relationship from this task to another, with its type and target.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-003",
"SRC-004"
]
},
{
"id": "de-dependency-gap",
"name": "Dependency gap",
"description": "Lead or lag duration applied to a dependency edge.",
"value_kind": "duration",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-004"
]
},
{
"id": "de-dependency-target",
"name": "Dependency target reference",
"description": "Identifier or resolvable link to the related task, possibly in another system.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-004",
"SRC-008"
]
}
],
"artifacts": [
{
"id": "art-task-dependency-graph",
"name": "Task relationship and dependency graph",
"description": "The materialised set of typed edges among tasks, containers and external work items, with gaps and resolution status.",
"media_or_form": [
"Directed graph of typed edges",
"Relationship property set on each record",
"Adjacency table with edge type and gap"
],
"serial": false,
"identity_strategy": "Edges are identified by the ordered pair of endpoint task identifiers plus the relationship type; the graph itself is identified by the container or plan scope it was materialised for.",
"source_refs": [
"SRC-003",
"SRC-004",
"SRC-008"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-plan-and-schedule-reference",
"name": "Reference to plan or schedule",
"description": "How the task points at an independently versioned plan, and which side prevails when planned and actual timing disagree.",
"source_refs": [
"SRC-002",
"SRC-004"
],
"questions": [
{
"id": "q-plan-reference",
"text": "Which plan or schedule version places this task, and is that reference pinned to a version?",
"kind": "relationship",
"answer_data": [
"Plan reference",
"Plan version identifier",
"Whether the reference is pinned or floating"
]
},
{
"id": "q-plan-variance",
"text": "How is variance between planned and actual timing measured and reported back to the plan?",
"kind": "measurement",
"answer_data": [
"Variance value and unit",
"Reporting cadence and recipient",
"Threshold that triggers replanning"
]
},
{
"id": "q-plan-authority-conflict",
"text": "When the plan and the task disagree about dates, which one is authoritative?",
"kind": "authority",
"answer_data": [
"Authoritative side",
"Reconciliation procedure",
"Party empowered to resolve the conflict"
]
}
],
"data_elements": [
{
"id": "de-plan-reference",
"name": "Plan reference",
"description": "Version-pinned reference to the plan or schedule that places this task.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-plan-version",
"name": "Plan version",
"description": "Version label of the referenced plan at the time of binding.",
"value_kind": "text",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-schedule-variance",
"name": "Schedule variance",
"description": "Measured difference between planned and actual timing.",
"value_kind": "quantity",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-004"
]
}
],
"artifacts": [],
"inline_only_rationale": "The plan or schedule is an independently versioned artifact owned by the sibling model WM-ACT-008, consistent with the registered REFERENCE relation. The task holds only a version-pinned reference plus a computed variance value; copying plan content into the task would create a second, silently stale master for the schedule."
}
]
}
]
},
{
"id": "b-work-content-and-evidence",
"name": "Work content, results and evidence",
"description": "What goes into the task, what counts as done, what comes out, and what proves it happened.",
"rationale": "FHIR, WS-HumanTask and A2A all model typed inputs and outputs plus completion behaviour, and PROV-O supplies the used and generated relations that connect them. Acceptance, measurement and evidence are separable concerns that determine whether a completion claim can be trusted.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-006",
"SRC-008",
"SRC-009"
],
"layers": [
{
"id": "l-work-specification",
"name": "Inputs, acceptance criteria and execution constraints",
"description": "What must be supplied, what must be true to call the work done, and the conditions and resources execution requires.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-007",
"SRC-008",
"SRC-009"
],
"findings": [
{
"id": "f-task-inputs-and-parameters",
"name": "Typed inputs, parameters and subject focus",
"description": "The typed information a task consumes, when each value is bound, what the task acts upon, and how inputs are validated.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-007",
"SRC-009"
],
"questions": [
{
"id": "q-input-set",
"text": "What typed inputs, parameters and attachments must be present before work can start?",
"kind": "composition",
"answer_data": [
"Input type code and value per entry",
"Required or optional flag",
"Attachment references with media type"
]
},
{
"id": "q-input-binding-time",
"text": "Which input values are bound at creation and which are supplied during execution?",
"kind": "process",
"answer_data": [
"Binding time per input",
"Party supplying each late-bound input",
"State the task waits in for late inputs"
]
},
{
"id": "q-input-validation",
"text": "How are inputs validated against the task definition, and what happens when validation fails?",
"kind": "validation",
"answer_data": [
"Validation rule reference",
"Validation outcome per input",
"Failure handling action"
]
},
{
"id": "q-input-focus",
"text": "What entity does this task act upon, and for whose benefit is it performed?",
"kind": "relationship",
"answer_data": [
"Focus entity reference",
"Beneficiary or subject reference",
"Relationship of focus to beneficiary"
]
}
],
"data_elements": [
{
"id": "de-task-input",
"name": "Task input",
"description": "Typed input entry consisting of a type code and a value of any data type.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009"
]
},
{
"id": "de-focus-entity",
"name": "Focus entity",
"description": "The entity the task acts upon.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-007"
]
},
{
"id": "de-beneficiary",
"name": "Beneficiary",
"description": "Party for whom the task is performed.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
}
],
"artifacts": [
{
"id": "art-task-input-payload",
"name": "Task input payload and attachments",
"description": "The concrete parameter set and ad hoc attachments supplied to the task, retrievable separately from its summary record.",
"media_or_form": [
"Typed parameter set",
"Attached document or file with media type",
"Structured message parts"
],
"serial": false,
"identity_strategy": "Task identifier plus input type code, with a content digest for each attachment; attachments retain the identifier of their source system where one exists.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-completion-criteria-and-acceptance",
"name": "Completion criteria, acceptance and verification",
"description": "What must hold for the task to count as complete, who accepts the result, and whether acceptance is separate from completion.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-008",
"SRC-013"
],
"questions": [
{
"id": "q-completion-definition",
"text": "What conditions must hold for the task to count as complete, and are they machine-checkable?",
"kind": "requirement",
"answer_data": [
"Completion criterion statements",
"Machine-checkable flag with the check used",
"Party who defined the criteria"
]
},
{
"id": "q-acceptance-authority",
"text": "Who accepts, reviews or verifies the result, and is acceptance a separate step from completion?",
"kind": "authority",
"answer_data": [
"Accepting or verifying party",
"Whether acceptance is a distinct state",
"Outcome of the review"
]
},
{
"id": "q-partial-completion",
"text": "Is partial or conditional completion permitted, and how is it represented without misreporting success?",
"kind": "state",
"answer_data": [
"Partial completion representation",
"Outstanding items list",
"Follow-on task reference"
]
}
],
"data_elements": [
{
"id": "de-acceptance-criteria",
"name": "Acceptance criteria",
"description": "Stated conditions that the result must satisfy to be accepted.",
"value_kind": "text",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002"
]
},
{
"id": "de-verification-flags",
"name": "Verification predicates",
"description": "Independent review outcomes such as approved, reviewed, verified or fixed.",
"value_kind": "boolean",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-008",
"SRC-013"
]
},
{
"id": "de-accepted-by",
"name": "Accepting party",
"description": "Party that accepted or rejected the result, with the time of the decision.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-008"
]
}
],
"artifacts": [
{
"id": "art-acceptance-record",
"name": "Acceptance and verification record",
"description": "The recorded decision that the result meets the criteria, including reviewer, outcome and any conditions attached.",
"media_or_form": [
"Sign-off entry with reviewer and outcome",
"Review comment set",
"Verification or test result summary"
],
"serial": true,
"identity_strategy": "Task identifier plus monotonic review sequence; each record cites the criteria version it was assessed against.",
"source_refs": [
"SRC-001",
"SRC-008"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-execution-constraints-and-resources",
"name": "Preconditions, resources, instruments and location",
"description": "The conditions that must hold to execute, the resources and instruments required, and where performance must take place.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-007"
],
"questions": [
{
"id": "q-constraint-preconditions",
"text": "What preconditions, safety rules or policy constraints must hold before and during execution?",
"kind": "constraint",
"answer_data": [
"Precondition statements",
"Enforcement point",
"Consequence of proceeding without them"
]
},
{
"id": "q-resource-instruments",
"text": "Which resources, tools, systems or instruments are required, and are any reserved exclusively for this task?",
"kind": "requirement",
"answer_data": [
"Required resource references",
"Reservation status and window",
"Substitutability of each resource"
]
},
{
"id": "q-execution-location",
"text": "Where must the work be performed, and is that location a hard constraint or advisory?",
"kind": "spatial",
"answer_data": [
"Location reference or coordinates",
"Binding force of the location",
"Permitted alternatives such as remote performance"
]
}
],
"data_elements": [
{
"id": "de-execution-location",
"name": "Execution location",
"description": "Place at which the work is to be performed, as a reference or coordinates.",
"value_kind": "reference",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-007"
]
},
{
"id": "de-required-resources",
"name": "Required resources",
"description": "Resources, tools or instruments needed to perform the task.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-003",
"SRC-007"
]
},
{
"id": "de-execution-restriction",
"name": "Execution restriction",
"description": "Limits on fulfilment such as permitted repetitions, period and named recipient.",
"value_kind": "object",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
}
],
"artifacts": [],
"inline_only_rationale": "Preconditions, resource needs and location are inline structured constraints evaluated against the task record. The resources and places themselves are governed by sibling asset, facility and party models, and reservations are their records, not the task's, so no artifact is minted here."
}
]
},
{
"id": "l-outputs-and-artifacts",
"name": "Outputs and measurement",
"description": "What the task produces and how progress and effort are quantified.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-006",
"SRC-009"
],
"findings": [
{
"id": "f-task-outputs-and-artifacts",
"name": "Outputs, produced artifacts and derivation",
"description": "What the task produces, how each output is identified and linked to the inputs it came from, and whether outputs may change after closure.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-007",
"SRC-009"
],
"questions": [
{
"id": "q-output-set",
"text": "What outputs, artifacts or deliverables does the task produce, and is each individually identified?",
"kind": "composition",
"answer_data": [
"Output type code and value or reference",
"Artifact identifier and name",
"Media type or form of each output"
]
},
{
"id": "q-output-derivation",
"text": "How is each output linked to the task that generated it and to the inputs it was derived from?",
"kind": "provenance",
"answer_data": [
"Generation link to the task",
"Derivation links to source entities",
"Generation time"
]
},
{
"id": "q-output-immutability",
"text": "Are outputs immutable once the task reaches a terminal state, or may they be superseded?",
"kind": "quality",
"answer_data": [
"Immutability policy",
"Supersession mechanism and pointer",
"Digest of the frozen output"
]
}
],
"data_elements": [
{
"id": "de-task-output",
"name": "Task output",
"description": "Typed output entry produced by the task, as a value or a reference.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-009"
]
},
{
"id": "de-output-artifact-reference",
"name": "Produced artifact reference",
"description": "Reference to an independently identified artifact generated by the task.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006",
"SRC-009"
]
},
{
"id": "de-output-derivation",
"name": "Output derivation",
"description": "Link from an output to the entities it was derived from.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006"
]
}
],
"artifacts": [
{
"id": "art-task-output-artifact",
"name": "Produced output artifact",
"description": "A discrete result generated by the task, composed of one or more typed parts and retrievable independently of the task record.",
"media_or_form": [
"Structured result with typed parts",
"Document, dataset or file",
"Record of a physical deliverable"
],
"serial": true,
"identity_strategy": "Artifact identifier assigned by the producing system, correlated to the task identifier and ordered by a monotonic sequence; a content digest fixes the version claimed at completion.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-009"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-progress-and-effort-measurement",
"name": "Progress reporting and effort accounting",
"description": "How progress is quantified, what effort was estimated and consumed, and how far a self-reported figure can be trusted.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008"
],
"questions": [
{
"id": "q-progress-metric",
"text": "How is progress quantified, on what scale, and who is permitted to update it?",
"kind": "measurement",
"answer_data": [
"Progress value and scale",
"Permitted updating roles",
"Time of last progress update"
]
},
{
"id": "q-effort-accounting",
"text": "What effort or duration was estimated and what has actually been consumed, in which units?",
"kind": "measurement",
"answer_data": [
"Estimated effort with unit",
"Consumed effort with unit",
"Basis of the estimate"
]
},
{
"id": "q-progress-trust",
"text": "How reliable is a self-reported progress figure, and what independent signal corroborates it?",
"kind": "quality",
"answer_data": [
"Corroborating signal or measurement",
"Discrepancy between reported and observed progress",
"Confidence statement"
]
}
],
"data_elements": [
{
"id": "de-percent-complete",
"name": "Percent complete",
"description": "Integer completion percentage where zero means not started and one hundred means complete.",
"value_kind": "number",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-effort-estimate",
"name": "Estimated effort",
"description": "Expected effort or duration with an explicit unit.",
"value_kind": "quantity",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"id": "de-effort-actual",
"name": "Consumed effort",
"description": "Effort or duration actually consumed with an explicit unit.",
"value_kind": "quantity",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-006"
]
}
],
"artifacts": [],
"inline_only_rationale": "Progress and effort are inline scalar measurements on the task record; only percent complete has direct normative support in the sources examined. Detailed time recording, rates and cost belong to a sibling effort and cost model, so no artifact is minted here and the effort fields are declared a supported gap."
}
]
},
{
"id": "l-provenance-and-evidence",
"name": "Provenance and evidence",
"description": "Who did what, using what, and what proves the claim.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-012"
],
"findings": [
{
"id": "f-execution-provenance-and-attribution",
"name": "Execution provenance and attribution",
"description": "Which agent performed each step, in which role and on whose behalf, and which entities were used and generated.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-009",
"SRC-012"
],
"questions": [
{
"id": "q-provenance-actor",
"text": "Which agent actually performed each step, in which role, and on whose behalf did it act?",
"kind": "provenance",
"answer_data": [
"Performing agent reference",
"Role held during the activity",
"On-behalf-of party"
]
},
{
"id": "q-provenance-used-generated",
"text": "Which entities were used and which were generated, with start and end times for the activity?",
"kind": "evidence",
"answer_data": [
"Used entity references",
"Generated entity references",
"Activity start and end times"
]
},
{
"id": "q-provenance-plan-association",
"text": "Which plan or definition qualified the agent's association with this task?",
"kind": "relationship",
"answer_data": [
"Plan or definition reference in the association",
"Role in the association",
"Association record identifier"
]
}
],
"data_elements": [
{
"id": "de-performed-by",
"name": "Performing agent",
"description": "Agent, human or automated, that carried out the work.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006",
"SRC-009"
]
},
{
"id": "de-agent-role",
"name": "Agent role in association",
"description": "Role the agent held with respect to the task activity.",
"value_kind": "code",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006"
]
},
{
"id": "de-used-entities",
"name": "Used entities",
"description": "Entities consumed or relied upon during execution.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-006"
]
}
],
"artifacts": [
{
"id": "art-provenance-record",
"name": "Provenance record",
"description": "Assertions about the execution of the task expressed as activity, agent and entity relations with qualified associations.",
"media_or_form": [
"Provenance graph statements",
"Provenance resource referenced from the task history",
"Audit event records"
],
"serial": true,
"identity_strategy": "Provenance record identifier minted by the recording system, bound to the task identifier and to the transition log sequence it describes.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-012"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-evidence-verification-and-quality",
"name": "Evidence capture, integrity and sufficiency",
"description": "What evidence must be captured to prove the work was done as specified, how its integrity is protected, and who judges sufficiency.",
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-008",
"SRC-012"
],
"questions": [
{
"id": "q-evidence-required",
"text": "What evidence must be captured to prove the work was performed as specified?",
"kind": "evidence",
"answer_data": [
"Required evidence types",
"Capture point in the lifecycle",
"Party responsible for capture"
]
},
{
"id": "q-evidence-integrity",
"text": "How is evidence integrity protected against later alteration?",
"kind": "security",
"answer_data": [
"Digest algorithm and value",
"Signature or append-only storage mechanism",
"Verification result and time"
]
},
{
"id": "q-evidence-sufficiency",
"text": "What makes the captured evidence sufficient for audit, and who decides sufficiency?",
"kind": "quality",
"answer_data": [
"Sufficiency criteria",
"Deciding role",
"Recorded shortfalls and remediation"
]
}
],
"data_elements": [
{
"id": "de-evidence-item",
"name": "Evidence item",
"description": "Individual piece of evidence captured for the task with its type and capture time.",
"value_kind": "collection",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-012"
]
},
{
"id": "de-evidence-digest",
"name": "Evidence digest",
"description": "Content digest fixing an evidence item, with the algorithm named.",
"value_kind": "text",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-012"
]
},
{
"id": "de-verification-method",
"name": "Verification method",
"description": "Method by which the evidence was verified.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-008"
]
}
],
"artifacts": [
{
"id": "art-evidence-bundle",
"name": "Evidence bundle",
"description": "The collected proof supporting the completion claim, each item digested and bound to the task and its transition entries.",
"media_or_form": [
"Signed evidence set",
"Captured images, scans or readings",
"Test or inspection results"
],
"serial": true,
"identity_strategy": "Task identifier plus monotonic evidence sequence, with a content digest per item; items retain the identifier assigned by their capturing system where one exists.",
"source_refs": [
"SRC-002",
"SRC-012"
]
}
],
"inline_only_rationale": null
}
]
}
]
},
{
"id": "b-governance-and-interoperability",
"name": "Access, retention and interoperability",
"description": "Who may see and change the task, how long it is kept, and how it exchanges safely with other systems.",
"rationale": "NIST establishes access control and audit accountability as required control families; iCalendar and FHIR carry confidentiality classification; A2A, OSLC and iCalendar each define exchange controls such as sequence numbers and terminal-state immutability. Governance and exchange integrity are therefore modelled explicitly rather than left to the storage projection.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009",
"SRC-012",
"SRC-013"
],
"layers": [
{
"id": "l-access-privacy-retention",
"name": "Access, confidentiality and retention",
"description": "Visibility rules, classification, exceptional access, and how long task content survives closure.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-012"
],
"findings": [
{
"id": "f-access-control-and-confidentiality",
"name": "Visibility, classification and exceptional access",
"description": "Who may see or change the task and its content, what classification applies, and how emergency access is authorised and reviewed.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-012"
],
"questions": [
{
"id": "q-access-visibility",
"text": "Who may see the task, its inputs and its outputs, and does visibility follow role assignment on the task?",
"kind": "access",
"answer_data": [
"Permitted roles per scope",
"Whether visibility derives from assignment or from a grant",
"Scope of each grant"
]
},
{
"id": "q-access-classification",
"text": "What confidentiality classification applies to the task, and does it differ from that of its attachments?",
"kind": "security",
"answer_data": [
"Classification code for the record",
"Classification per attachment",
"Rule for the more restrictive of the two"
]
},
{
"id": "q-access-exception",
"text": "How is emergency or break-glass access authorised, recorded and afterwards reviewed?",
"kind": "exception",
"answer_data": [
"Authorising role and justification",
"Access audit entry with time and scope",
"Review outcome"
]
}
],
"data_elements": [
{
"id": "de-confidentiality-class",
"name": "Confidentiality classification",
"description": "Coded confidentiality level of the task record and its content.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003"
]
},
{
"id": "de-access-grant",
"name": "Access grant",
"description": "Explicit grant of a scope to a party, with validity window and grantor.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-009",
"SRC-012"
]
},
{
"id": "de-access-audit-entry",
"name": "Access audit entry",
"description": "Record that a party read or changed protected task content.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-012"
]
}
],
"artifacts": [],
"inline_only_rationale": "Access decisions are enforced at runtime by the interface projection and are recorded on the existing transition and audit log artifact; the authorisation policy itself is a governance document owned by the adopting Dimension's policy model. The task therefore carries only an inline classification code and grant records, with no artifact of its own."
},
{
"id": "f-personal-data-retention-and-deletion",
"name": "Personal data, retention period and erasure",
"description": "Which task fields can carry personal data, how long the record and its history are kept, and how deletion is performed without destroying audit integrity.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-012"
],
"questions": [
{
"id": "q-retention-personal-data",
"text": "Which task fields can carry personal data about performers or subjects, and are they minimised?",
"kind": "privacy",
"answer_data": [
"Fields carrying personal data",
"Minimisation decision per field",
"Lawful basis or authority recorded by the Dimension"
]
},
{
"id": "q-retention-period",
"text": "How long are the task record, its history and its attachments retained after closure, and under whose authority?",
"kind": "retention",
"answer_data": [
"Retention class and period",
"Authority or schedule reference",
"Retention start event"
]
},
{
"id": "q-retention-deletion-method",
"text": "Is deletion logical or physical, and what tombstone remains for audit after erasure?",
"kind": "retention",
"answer_data": [
"Deletion method",
"Tombstone content retained",
"Deletion record with actor and time"
]
},
{
"id": "q-retention-legal-hold",
"text": "How does a legal hold or investigation suspend a scheduled deletion, and who lifts it?",
"kind": "exception",
"answer_data": [
"Hold identifier and scope",
"Party imposing and lifting the hold",
"Effect on the retention clock"
]
}
],
"data_elements": [
{
"id": "de-retention-class",
"name": "Retention class",
"description": "Coded retention category determining how long the record survives closure.",
"value_kind": "code",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-012"
]
},
{
"id": "de-retention-until",
"name": "Retention expiry",
"description": "Date after which the record becomes eligible for deletion.",
"value_kind": "date",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-012"
]
},
{
"id": "de-deletion-record",
"name": "Deletion record",
"description": "Tombstone recording that content was erased, by whom and under what authority.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-012"
]
}
],
"artifacts": [],
"inline_only_rationale": "Retention is expressed as inline classification codes and dates on the record, plus a tombstone entry on the existing audit log. The retention schedule and the legal basis for holding performer-identifying data are jurisdiction-specific governance instruments of the adopting Dimension; no legislative source was retrieved in this pass, so this model deliberately mints no artifact and asserts no statutory period."
}
]
},
{
"id": "l-interoperability-alignment",
"name": "Alignment and exchange integrity",
"description": "Crosswalks to external task vocabularies and the controls that keep exchanged copies consistent.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009",
"SRC-011"
],
"findings": [
{
"id": "f-external-standard-alignment",
"name": "Alignment crosswalks and conformance evidence",
"description": "Which external vocabularies the model is aligned to, which fields and states survive a round trip, and what evidence any conformance claim rests on.",
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-004",
"SRC-008",
"SRC-009",
"SRC-011"
],
"questions": [
{
"id": "q-alignment-targets",
"text": "Which external task vocabularies is this model aligned to, and at which versions?",
"kind": "interoperability",
"answer_data": [
"Target vocabulary identifier and version",
"Direction of alignment",
"Owner of the crosswalk"
]
},
{
"id": "q-alignment-fidelity",
"text": "Which fields and states survive a round trip to each aligned vocabulary without loss?",
"kind": "validation",
"answer_data": [
"Round-trip test result per field",
"Lossy field list with the distinction lost",
"Test date and dataset used"
]
},
{
"id": "q-alignment-conformance-claim",
"text": "What evidence supports a conformance claim, and where is alignment only partial?",
"kind": "evidence",
"answer_data": [
"Conformance evidence reference",
"Scope of partial alignment",
"Statement of what is not claimed"
]
}
],
"data_elements": [
{
"id": "de-alignment-mapping",
"name": "Alignment mapping entry",
"description": "One mapping from a local element or state to an element or state in a target vocabulary.",
"value_kind": "object",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008"
]
},
{
"id": "de-alignment-target-version",
"name": "Alignment target version",
"description": "Pinned version of the external vocabulary the mapping was authored against.",
"value_kind": "text",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-002",
"SRC-009"
]
},
{
"id": "de-conformance-evidence",
"name": "Conformance evidence reference",
"description": "Reference to the test results supporting a conformance or alignment claim.",
"value_kind": "reference",
"cardinality": "0..n",
"required": false,
"source_refs": [
"SRC-011"
]
}
],
"artifacts": [
{
"id": "art-alignment-crosswalk",
"name": "Alignment crosswalk",
"description": "The stored field-level and state-level mapping between this model and each aligned external vocabulary, annotated with loss notes.",
"media_or_form": [
"Mapping table with source, target and loss note",
"Machine-readable concept map",
"Transformation definition with test fixtures"
],
"serial": false,
"identity_strategy": "Crosswalk identifier composed of the model identifier and the pinned target vocabulary version; superseded crosswalks are retained and marked, never overwritten.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009"
]
}
],
"inline_only_rationale": null
},
{
"id": "f-exchange-integrity-and-concurrency",
"name": "Concurrency, idempotency and ordering on exchange",
"description": "How competing updates, duplicate requests and out-of-order status delivery are detected and resolved between systems.",
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-009",
"SRC-013"
],
"questions": [
{
"id": "q-exchange-concurrency",
"text": "How are concurrent updates to the same task detected and resolved: sequence number, revision token, or last writer wins?",
"kind": "constraint",
"answer_data": [
"Concurrency control mechanism",
"Conflict resolution rule",
"Record of rejected updates"
]
},
{
"id": "q-exchange-idempotency",
"text": "How are duplicate create or transition requests recognised and made idempotent?",
"kind": "process",
"answer_data": [
"Idempotency key and its scope",
"Deduplication window",
"Response returned for a repeat request"
]
},
{
"id": "q-exchange-ordering",
"text": "How is out-of-order delivery of status updates detected and corrected?",
"kind": "temporal",
"answer_data": [
"Ordering signal used (sequence or event time)",
"Detection of stale updates",
"Correction action"
]
},
{
"id": "q-exchange-terminal-immutability",
"text": "What happens when an update arrives for a task that has already reached a terminal state?",
"kind": "exception",
"answer_data": [
"Rejection or annotation policy",
"Successor task created, if any",
"Record of the rejected update"
]
}
],
"data_elements": [
{
"id": "de-sequence-number",
"name": "Revision sequence number",
"description": "Monotonic revision counter used to order updates to the same task.",
"value_kind": "number",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-003"
]
},
{
"id": "de-revision-token",
"name": "Revision token",
"description": "Opaque token identifying the current version of the record for optimistic concurrency.",
"value_kind": "identifier",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-002",
"SRC-013"
]
},
{
"id": "de-idempotency-key",
"name": "Idempotency key",
"description": "Key supplied by a client so that repeated requests produce one effect.",
"value_kind": "identifier",
"cardinality": "0..1",
"required": false,
"source_refs": [
"SRC-009"
]
}
],
"artifacts": [],
"inline_only_rationale": "Concurrency and idempotency controls are inline scalars on the record and headers of whichever access interface is used; they are meaningless outside the record whose version they identify. Rejected and duplicate updates are captured on the existing transition log rather than in a dedicated artifact."
}
]
}
]
}
]
},
"functions": [
{
"id": "fn-create-task-instance",
"name": "Create task instance",
"description": "Mint a task instance from a definition or ad hoc request, establishing identity, intent, classification and authorising reference.",
"inputs": [
"Definition reference and version, where one exists",
"Intent code and authorising reference",
"Task type code, inputs and temporal anchors"
],
"outputs": [
"Task record with authoritative identifier",
"Initial state entry on the transition log"
],
"preconditions": [
"Identity policy resolved for the owning system",
"Intent recorded and, for order intent, an authorising reference present",
"Task type code resolves in the governing vocabulary"
],
"effects": [
"Task exists in its initial state with authored time recorded",
"Definition binding pinned to a version",
"Identifier registered in the owning namespace"
],
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003",
"SRC-009"
]
},
{
"id": "fn-assign-and-claim",
"name": "Resolve assignment and claim ownership",
"description": "Resolve the potential performer set, and record a party taking or releasing ownership of the task.",
"inputs": [
"Assignment rule or literal party list",
"Claiming party identity and eligibility evidence"
],
"outputs": [
"Resolved potential owner set with resolution time",
"Actual owner or an empty-set escalation"
],
"preconditions": [
"Task is in a state that permits claiming",
"Claiming party is not on the excluded list",
"Eligibility requirements are satisfied or waived with a record"
],
"effects": [
"Ownership recorded with claim time",
"Transition log entry created",
"Exclusivity enforced against competing claims"
],
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-003"
]
},
{
"id": "fn-transition-state",
"name": "Transition task state",
"description": "Apply a guarded state change against the declared state model, rejecting transitions that are not permitted or that target a terminal record.",
"inputs": [
"Target state code and reason",
"Actor identity and role",
"Event time and recording time"
],
"outputs": [
"Updated current state with entry time",
"Transition log entry"
],
"preconditions": [
"Transition is permitted by the pinned state model version",
"Task is not already in a terminal state, unless the policy permits annotation",
"Actor holds a role authorised for the transition"
],
"effects": [
"Current state, status reason and business status updated",
"History extended append-only",
"Dependent tasks notified where propagation applies"
],
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009",
"SRC-013"
]
},
{
"id": "fn-record-blocking-and-request-input",
"name": "Record blocking and request missing input",
"description": "Move the task into a blocked condition, state the resume condition, and issue a request to the party able to satisfy it.",
"inputs": [
"Blocking reason code",
"Resume condition and responsible party",
"Timeout and escalation policy"
],
"outputs": [
"Blocked state with blocked-since time",
"Input or authorisation request message"
],
"preconditions": [
"Task is active and cannot proceed",
"A party able to satisfy the condition is identifiable or an escalation target exists"
],
"effects": [
"Task blocked and excluded from active work queues",
"Timeout clock started",
"Requester notified"
],
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-009"
]
},
{
"id": "fn-evaluate-completion-and-accept",
"name": "Evaluate completion and record acceptance",
"description": "Assess outputs against completion criteria, record the acceptance or rejection decision, and complete or reopen the task accordingly.",
"inputs": [
"Outputs and evidence items",
"Completion criteria version",
"Accepting party identity"
],
"outputs": [
"Acceptance record with outcome",
"Terminal or reworked state"
],
"preconditions": [
"Outputs present or explicitly declared absent",
"Accepting party is distinct from the performer where separation of duties applies"
],
"effects": [
"Verification predicates set",
"Outputs frozen with digests on acceptance",
"Follow-on task created where completion is partial"
],
"source_refs": [
"SRC-001",
"SRC-002",
"SRC-008"
]
},
{
"id": "fn-escalate-on-deadline",
"name": "Escalate on deadline expiry",
"description": "Detect a passed start or completion deadline and execute the configured escalation, including reassignment or notification.",
"inputs": [
"Deadline values and current time",
"Escalation rule with recipients"
],
"outputs": [
"Escalation event on the transition log",
"Notification or reassignment result"
],
"preconditions": [
"Deadline is set and has passed",
"Task is not in a terminal state"
],
"effects": [
"Recipients notified",
"Ownership or priority changed where the rule so specifies",
"Repetition and cooldown applied"
],
"source_refs": [
"SRC-001",
"SRC-003"
]
},
{
"id": "fn-resolve-dependencies",
"name": "Resolve dependencies and gaps",
"description": "Evaluate typed dependency edges with their lead or lag to determine whether the task may start or finish, and report cycles.",
"inputs": [
"Dependency edges with types and gaps",
"States and times of referenced tasks"
],
"outputs": [
"Readiness determination with the binding constraint named",
"Cycle and dangling reference report"
],
"preconditions": [
"Referenced tasks resolve, or an unresolved-reference policy is in force"
],
"effects": [
"Task marked ready or blocked by a named dependency",
"Invalid graphs rejected before scheduling"
],
"source_refs": [
"SRC-003",
"SRC-004",
"SRC-008"
]
},
{
"id": "fn-emit-provenance-and-audit",
"name": "Emit provenance and audit records",
"description": "Write activity, agent and entity assertions plus access and change audit entries for the task, with event and recording times kept separate.",
"inputs": [
"Transition and access events",
"Agent, role and on-behalf-of chain",
"Used and generated entity references"
],
"outputs": [
"Provenance record",
"Audit entries with actor, scope and time"
],
"preconditions": [
"Agent identity resolved",
"Clock source declared for each recorded time"
],
"effects": [
"Provenance graph extended",
"Audit trail made tamper-evident by chained digests"
],
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-012"
]
},
{
"id": "fn-project-to-external-vocabulary",
"name": "Project task to an aligned vocabulary",
"description": "Transform the task record into an aligned external representation using the pinned crosswalk, reporting every value that cannot be carried.",
"inputs": [
"Task record",
"Target vocabulary identifier and version",
"Crosswalk artifact"
],
"outputs": [
"Projected representation in the target vocabulary",
"Loss report listing unmappable values"
],
"preconditions": [
"Crosswalk exists for the pinned target version",
"Priority values carry their scale identifier"
],
"effects": [
"Interoperable representation produced",
"Loss recorded so that no unqualified conformance claim is made"
],
"source_refs": [
"SRC-002",
"SRC-003",
"SRC-008",
"SRC-009",
"SRC-011"
]
},
{
"id": "fn-apply-retention-and-erasure",
"name": "Apply retention, hold and erasure",
"description": "Evaluate the retention class against the closure date, honour legal holds, and perform logical or physical erasure leaving an auditable tombstone.",
"inputs": [
"Retention class and expiry",
"Active legal holds",
"Erasure request with authority"
],
"outputs": [
"Deletion or hold decision",
"Tombstone record where content is erased"
],
"preconditions": [
"Task is in a terminal state or the request cites an overriding authority",
"No active hold covers the record, or the hold is explicitly lifted"
],
"effects": [
"Content erased or retained per class",
"Identifier, terminal state and deletion provenance preserved",
"Audit entry written for the deletion decision"
],
"source_refs": [
"SRC-002",
"SRC-012"
]
},
{
"id": "fn-delegate-or-forward",
"name": "Delegate or forward Task",
"description": "Transfer potential or actual ownership to another person or group without creating a new Task identity.",
"inputs": [
"Task identifier",
"source actor",
"target actor or group",
"delegate versus forward flag"
],
"outputs": [
"Updated potential owners or actual owner"
],
"preconditions": [
"Source actor is actual owner, stakeholder or administrator as specified by the people-assignment policy",
"Target is not an excluded owner"
],
"effects": [
"Assignment record is rewritten",
"History records delegation or forwarding",
"Status may return to ready if the current owner stopped work"
],
"source_refs": [
"SRC-001"
]
},
{
"id": "fn-terminate-abnormally",
"name": "Cancel, fail, reject or enter-in-error",
"description": "Terminate abnormally, distinguish external cancellation, execution failure, pre-start rejection and never-valid entered-in-error.",
"inputs": [
"Task identifier",
"actor",
"terminal path",
"status reason"
],
"outputs": [
"Terminal status",
"reason",
"optional error object"
],
"preconditions": [
"Cancel and fail apply to non-terminal states except where policy allows entered-in-error on any state",
"Reject applies before performance",
"Caller has requester, owner or administrator authority as required"
],
"effects": [
"Task becomes terminal on the declared path",
"Children may be cancelled when policy cascades",
"History records the terminal event and reason"
],
"source_refs": [
"SRC-016",
"SRC-018",
"SRC-001"
]
}
],
"composition": [
{
"target": "WM-ACT-005 Project",
"relation": "CHILD",
"purpose": "A task may be contained by a project as one unit of its work; the task holds the container reference and the project owns objectives, budget and governance.",
"required": false,
"source_refs": [
"SRC-002",
"SRC-003"
]
},
{
"target": "WM-ACT-007 Work Order",
"relation": "CHILD",
"purpose": "A work order authorises and groups tasks; the task records the authorising reference and its actionability level while the work order owns the authorisation chain.",
"required": false,
"source_refs": [
"SRC-001",
"SRC-002"
]
},
{
"target": "WM-ACT-008 Plan or Schedule",
"relation": "REFERENCE",
"purpose": "The task cites a version-pinned plan that places it in time and reports variance back, without copying plan content.",
"required": false,
"source_refs": [
"SRC-002",
"SRC-004"
]
},
{
"target": "Party, organisation and agent identity model (sibling; identifier assigned by the adopting Dimension)",
"relation": "REFERENCE",
"purpose": "All role assignments, delegations and on-behalf-of chains resolve to parties governed elsewhere; the task stores references and roles only.",
"required": true,
"source_refs": [
"SRC-001",
"SRC-006"
]
},
{
"target": "Artifact, document and deliverable model (sibling; identifier assigned by the adopting Dimension)",
"relation": "COMPOSE",
"purpose": "Produced outputs and attachments are independently identified artifacts composed into the task's result set by generation links.",
"required": false,
"source_refs": [
"SRC-002",
"SRC-006",
"SRC-009"
]
},
{
"target": "Provenance and audit event mix-in",
"relation": "MIX-IN",
"purpose": "Supplies the agent, activity and entity assertions plus audit entry structure reused by the task's transition history.",
"required": true,
"source_refs": [
"SRC-006",
"SRC-012"
]
},
{
"target": "Timestamp and interval mix-in",
"relation": "MIX-IN",
"purpose": "Supplies the RFC 3339 timestamp discipline, interval structure and the separation of event time from recording time used across every layer.",
"required": true,
"source_refs": [
"SRC-005"
]
},
{
"target": "Generic action or activity pattern model",
"relation": "EXTEND",
"purpose": "Task specialises the general action pattern of actor, object, instrument, result and status by adding assignment, deadlines, terminality and acceptance.",
"required": false,
"source_refs": [
"SRC-006",
"SRC-007",
"SRC-011"
]
},
{
"target": "Process and case definition models (BPMN process, CMMN case)",
"relation": "REFERENCE",
"purpose": "The instance cites the definition it realises; the definition languages and their interchange formats remain outside this model.",
"required": false,
"source_refs": [
"SRC-010",
"SRC-014"
]
},
{
"target": "FHIR Task (HL7 FHIR R5)",
"relation": "ALIGN",
"purpose": "Alignment target for status, intent, businessStatus, basedOn, partOf, focus, owner, executionPeriod, restriction and input or output; alignment is partial and recorded in a crosswalk.",
"required": false,
"source_refs": [
"SRC-002"
]
},
{
"target": "iCalendar VTODO with relationship extensions",
"relation": "ALIGN",
"purpose": "Alignment target for UID, DTSTAMP, DUE, PERCENT-COMPLETE, STATUS, PRIORITY, RRULE and the typed dependency relationships with lead or lag.",
"required": false,
"source_refs": [
"SRC-003",
"SRC-004"
]
},
{
"target": "WS-HumanTask task instance",
"relation": "ALIGN",
"purpose": "Alignment target for the human task lifecycle, generic human roles, people assignment, deadlines with escalation and composite subtask completion.",
"required": false,
"source_refs": [
"SRC-001"
]
},
{
"target": "A2A Task",
"relation": "ALIGN",
"purpose": "Alignment target for agent-executed tasks: server-generated identity, context grouping, interruption states and produced artifacts with terminal-state immutability.",
"required": false,
"source_refs": [
"SRC-009"
]
},
{
"target": "OSLC ChangeRequest",
"relation": "ALIGN",
"purpose": "Alignment target for work records expressed with boolean state predicates and typed links; the mapping to a single enumerated state is lossy and recorded as such.",
"required": false,
"source_refs": [
"SRC-008",
"SRC-013"
]
}
],
"serviceLayers": {
"dimension": {
"owner_package_requirements": [
"The adopting Dimension MUST designate one owner package that holds this model, its state model definition, its task type code list and its escalation rules, and MUST name an accountable maintainer for each.",
"The owner package MUST publish the identifier policy (which master system is authoritative, which IRI scheme is used, and when a UUID or ULID may be minted) before any task record is created under this model.",
"The owner package MUST pin the version of every aligned external vocabulary it claims, store the corresponding crosswalk, and re-verify round-trip fidelity at each release.",
"The owner package MUST declare retention classes, legal-hold procedure and the authority under which performer-identifying data is retained, since no statutory period is asserted by this model."
],
"namespace_guidance": "Mint task identifiers only under an HTTPS IRI base controlled by the adopting Dimension, for example /act/task/{identifier}, and keep the state vocabulary and task type code list under sibling bases such as /act/task/state and /act/task/type. External vocabulary IRIs from FHIR, iCalendar, PROV, Activity Streams, OSLC, schema.org and A2A appear only as alignment targets and are never used to mint local identifiers.",
"registry_links": [
"Registry entry vr.wm-act-006 in the world-model record plane, navigation path NAV.ACT.TSK",
"Relations file planning/VERCY-MODEL-RELATIONS.csv for the CONTAINS and REFERENCE edges to WM-ACT-005, WM-ACT-007 and WM-ACT-008",
"State model definition registry entry holding the canonical state list, terminality flags and permitted transitions",
"Task type and priority scale vocabulary registry entry, versioned independently of this model"
]
},
"canon_and_patch": {
"canonicalization_rules": [
"Serialise with deterministic key ordering and Unicode NFC normalisation of all text values so that digests are reproducible across projections.",
"Express every time value in RFC 3339 form with seconds and an explicit offset; preserve the original offset rather than silently converting to Z, because the offset carries the performer's civil context.",
"Represent every coded value as the triple of code system, code and code system version; a bare code or a bare priority integer is not canonical.",
"Represent references as absolute IRIs or as an identifier plus its scheme; distinguish an absent field from a field present with an empty value."
],
"patch_rules": [
"Patches address stable local identifiers of bundles, layers, findings, questions, data elements and artifacts; they never address values by array position.",
"State changes are applied only through the transition function; direct field writes to the state value are rejected.",
"Records in a terminal state accept additive annotations only; a correction is made by a superseding record that references the closed one, never by rewriting history.",
"Every patch carries actor, reason, event time and recording time, and appends to the transition log; silent updates are invalid.",
"Deletions are tombstoned: the identifier, terminal state, retention class and deletion provenance survive the removal of content."
],
"compatibility_rules": [
"Adding an optional data element, question or artifact class is a minor change; consumers must ignore unknown optional fields.",
"Removing or narrowing a state value, changing the direction of a priority scale, changing terminality, or changing the identity policy is a breaking change requiring a major version and a migration note.",
"Any change to an alignment mapping requires a new crosswalk revision with an explicit loss note; the superseded crosswalk is retained.",
"A conformance claim may only be strengthened when new round-trip evidence is stored; otherwise the claim is downgraded to partial alignment."
]
},
"artifact_rules": {
"identity_priority": [
"Authoritative master-system identifier issued by the system of record that owns the task instance, for example the workflow engine, ticketing system or agent server that created it; where the producing server mandates that it alone generates task identifiers, that server is the master system.",
"Governed global identifier or IRI, such as an iCalendar-style globally unique UID or an HTTPS IRI minted under the adopting Dimension's namespace, used when no master system exists.",
"UUID or ULID assigned by the adopting Dimension, recorded together with its minting authority and minting time.",
"A date, due time, title, sequence position, assignee name or queue position is never an identifier and must not be used as one, including for occurrences of a recurring task."
],
"timestamp_rule": "All time values MUST be RFC 3339 date-time strings that include seconds and an explicit offset, either Z or a signed hh:mm offset; the -00:00 offset is used only when the UTC time is known but the local offset genuinely is not. Event time, meaning when the state change, claim, execution or deadline breach actually occurred, MUST be recorded separately from observation or ingestion time, meaning when the recording system received or wrote the fact, whenever the two can differ, and each MUST carry its own offset. Where a leap second is represented, the value 60 in the seconds field is accepted and preserved rather than normalised away.",
"serial_naming_rule": "Serial artifacts, namely transition log entries, delegation records, input requests, acceptance records, output artifacts and evidence items, are named //, where the sequence is monotonic within the task and its artifact class, starts at one, and is never reused after deletion or supersession.",
"integrity_rule": "Every artifact carries a named digest algorithm with its digest value, its size and its media type or form. The transition log is append-only and each entry references the digest of the preceding entry, so that a missing or altered entry is detectable. Outputs are frozen with a digest at acceptance. A claim of conformance to any external vocabulary requires both a stored crosswalk pinned to the target version and stored round-trip test evidence; without both, only partial alignment may be stated."
},
"policies": [
"Do not claim conformance to FHIR, iCalendar, WS-HumanTask, OSLC or A2A without a stored crosswalk and round-trip evidence; state partial alignment and name the distinctions that are lost.",
"A priority value MUST carry its scale identifier, because the direction and meaning of the scale differ across the cited sources and a bare integer is therefore ambiguous.",
"Terminal states are immutable by default: reopening requires a new task that references the closed one. Where an aligned system permits status correction instead, that behaviour is recorded as a declared exception with its own audit entry.",
"An automated performer MUST be recorded as the acting agent together with an on-behalf-of chain to an accountable human or organisational party; an unattributed automated action is invalid.",
"Every state, assignment and priority change is recorded with actor, reason, event time and recording time; silent transitions are prohibited.",
"Personal data carried in task descriptions, comments and attachments is minimised at creation and inherits the retention class of the task unless a stricter class applies to the attachment.",
"Least-privilege access by generic human role: potential owners see queue fields; actual owners update execution fields; requesters may cancel according to policy; stakeholders and business administrators may escalate; excluded owners are denied claim and start.",
"Retain terminal Task records and lifecycle history for the Dimension retention period unless a legal hold applies; entered-in-error records are retained because they may have been used, but must be labeled so they are not treated as valid work.",
"Treat external standards as alignments. Store native codes and declared maps; do not overwrite native status with a canonical code.",
"Cascade suspend and resume to children unless a child is already terminal. Do not auto-complete a parent solely because one child completed unless a completion condition says so."
],
"crud": {
"read": [
"Read by task identifier returns identity, classification, current state, assignment and temporal anchors; history, attachments and evidence are retrieved as separate scopes so that summary access does not disclose payload content.",
"Reads are filtered by the caller's role on the task or on its container, and reads of confidential content are logged with caller, scope and time."
],
"create": [
"Creation requires an intent code, a task type code and either an authorising reference or an explicit statement that none exists; identity is minted according to the identity priority rule and the authored time is recorded.",
"Creation from a definition pins the definition version; creation without a definition records that the task is ad hoc or discretionary."
],
"update": [
"Field-scoped updates are guarded by the revision token or sequence number; a stale token causes rejection rather than a merge.",
"State, ownership and priority are changed only through their functions, each of which appends to the transition log with reason and both times."
],
"delete": [
"Deletion is logical by default: content is removed but the identifier, terminal state, retention class and deletion provenance are retained as a tombstone so that references from other tasks remain resolvable.",
"Physical erasure occurs only on a recorded erasure request citing its authority, is blocked by any active legal hold, and always leaves an audit entry describing the scope erased."
]
},
"roles": [
{
"name": "Model steward",
"responsibilities": [
"Maintain this model, its state model definition and its vocabularies",
"Approve breaking changes and publish migration notes",
"Re-verify alignment crosswalks when a target vocabulary version changes"
]
},
{
"name": "Task initiator or requester",
"responsibilities": [
"Create tasks with intent, type and authorising reference",
"Supply required inputs and acceptance criteria",
"Respond to requests for missing input or authorisation"
]
},
{
"name": "Task performer (human or automated agent)",
"responsibilities": [
"Claim, execute and report progress on assigned tasks",
"Produce outputs and capture required evidence",
"Declare blocking conditions instead of silently stalling"
]
},
{
"name": "Task stakeholder or business administrator",
"responsibilities": [
"Oversee outcomes and intervene on escalation",
"Reassign, suspend or terminate tasks within declared authority",
"Resolve conflicts between plan dates and task dates"
]
},
{
"name": "Auditor or records officer",
"responsibilities": [
"Verify completeness and integrity of transition history and evidence",
"Apply retention classes, legal holds and erasure decisions",
"Review break-glass access events"
]
},
{
"name": "Integration engineer",
"responsibilities": [
"Maintain crosswalks and loss notes for each aligned vocabulary",
"Operate concurrency, idempotency and ordering controls on exchange",
"Report unmappable values back to the model steward"
]
}
],
"access": {
"default_rule": "Deny by default. A party may read a task only through an explicit role assignment on that task, an inherited assignment on its container, or an administrative scope granted for a stated period; write access is always narrower than read access and never implied by it.",
"scopes": [
"bundle",
"layer",
"finding",
"artifact"
],
"exceptions": [
"Break-glass access for urgent operational need, requiring a stated justification, a time limit and post hoc review.",
"Auditor and regulator read access across scopes, permitted for verification and always logged.",
"Aggregate or anonymised metrics that expose counts and durations without identifying performers or subjects.",
"Subject access requests, which disclose a person's own data across the record and its history under an identity-verified procedure.",
"Delegated automated agents, whose scope is limited to the task and its context grouping and expires when the task reaches a terminal state.",
"Entered-in-error Tasks remain readable to auditors and original requesters but are excluded from work queues.",
"Legal hold suspends deletion even when retention has expired.",
"Excluded owners are denied claim, start and complete even if they can read a redacted queue item.",
"Confidential CLASS or equivalent labels restrict title and body from unprivileged list views."
],
"audit_requirements": [
"Log every read of confidential or personal task content with caller identity, scope, event time and recording time.",
"Log every state, assignment, priority, acceptance and export action with actor, reason and both times.",
"Protect audit records against modification, retain them under their own retention class, and detect gaps through the chained digests of the transition log.",
"Record actor, role, operation, Task identifier, event time and ingestion time for create, claim, assign, start, complete, cancel, fail, enter-in-error, delegate, forward, escalate, suspend, resume and delete.",
"Retain audit records at least as long as the Task evidence pack."
]
},
"agents_bootstrap": {
"filename": "AGENTS.md",
"required_fields": [
"Name",
"Type",
"Specification URL",
"Storage type URL",
"Interface URL",
"Processes URL",
"Registry ID",
"Model ID",
"Owner or maintainer",
"Alignment crosswalk URL"
],
"read_order": [
"AGENTS.md at the package root, to obtain Name, Type, Specification URL, Storage type URL, Interface URL and Processes URL before any other file, including when the storage projection is MongoDB or the interface is MCP",
"The model specification at Specification URL, for scope, boundaries and the bundle, layer, finding and question structure",
"The storage type document at Storage type URL, for the concrete projection, canonicalisation and identifier placement",
"The interface document at Interface URL, for read, create, update and delete operations, concurrency tokens and access scopes",
"The processes document at Processes URL, for the state model, transition guards, escalation and retention procedures",
"The registry entry vr.wm-act-006 and the relations file, for containment and reference edges to sibling models"
]
}
},
"coverage": {
"claim": "The merged model covers identity, definition binding, human-readable designation, classification, authorisation and actionability, oversight, assignment and claiming, canonical state with terminality and blocking, transition history, unsuccessful endings, temporal anchors and deadlines, recurrence, decomposition, typed dependencies with lead or lag, plan reference, typed inputs, completion and acceptance, outputs, progress, provenance, evidence, access, retention and interoperability of a single task instance, grounded in tier-1 and tier-2 primary specifications from HL7, IETF, OASIS, OMG, W3C, NIST, Schema.org, the A2A project and Microsoft. Effort accounting and statutory retention remain declared gaps; cost, competency, robotics-level decomposition and jurisdictional data-protection obligations are out of scope. No universal, metaphysical or cross-domain completeness is claimed, and adequacy outside the profiles actually exercised is unverified.",
"confidence": "medium",
"checklist": [
{
"dimension": "identity",
"status": "covered",
"notes": "Identity priority, uniqueness scope, correlation identifiers and recurrence occurrence identity are modelled; grounded in the required UID of iCalendar VTODO, the FHIR identifier and business identifier split, and the server-generated task identifier mandated by A2A."
},
{
"dimension": "lifecycle",
"status": "covered",
"notes": "Canonical state model with explicit terminality, blocking and unsuccessful-ending classification, grounded in four independent state vocabularies of differing size; the divergence itself is recorded as a conflict rather than harmonised away."
},
{
"dimension": "relationships",
"status": "covered",
"notes": "Containment, subtask decomposition, four typed dependency relations with lead or lag, plan reference and cross-system references are all modelled with primary support from iCalendar relationship extensions, FHIR and OSLC."
},
{
"dimension": "temporal",
"status": "covered",
"notes": "Anchor set, RFC 3339 format discipline with seconds and explicit offset, event time separated from recording time, deadlines with escalation, recurrence, and the due-versus-duration precedence conflict."
},
{
"dimension": "provenance",
"status": "covered",
"notes": "Agent, activity and entity assertions with qualified association, role and plan, plus an append-only chained transition log; grounded in PROV-O and the FHIR relevant-history pattern."
},
{
"dimension": "ownership",
"status": "covered",
"notes": "Seven generic human roles, actual owner, excluded owners, claiming and release, delegation with or without transfer of accountability, and the on-behalf-of chain for automated performers."
},
{
"dimension": "validation",
"status": "covered",
"notes": "Input validation against the definition, dependency cycle and dangling-reference detection, timestamp format conformance, concurrency token checking, and round-trip fidelity testing for each crosswalk."
},
{
"dimension": "access",
"status": "covered",
"notes": "Deny-by-default rule with four scopes, confidentiality classification, break-glass and auditor exceptions, and mandatory access logging; grounded in the NIST access control and audit accountability control families and in the confidentiality classification carried by iCalendar and FHIR."
},
{
"dimension": "retention and deletion",
"status": "gap",
"notes": "Retention class, expiry, legal hold, tombstoned logical deletion and erasure provenance are modelled, but only audit-record retention has primary support in the sources retrieved. Attempts to retrieve legislative text failed, so no statutory period, lawful basis or erasure right is asserted; the adopting Dimension must supply the governing schedule."
},
{
"dimension": "interoperability",
"status": "covered",
"notes": "Five alignment targets with pinned versions, a crosswalk artifact with loss notes, an explicit prohibition on unqualified conformance claims, and exchange controls for concurrency, idempotency and ordering."
},
{
"dimension": "classification",
"status": "covered",
"notes": "Task type, category, performer kind, intent and priority or severity are modelled with governed vocabularies; the incompatibility of the four priority scales found is recorded as a conflict."
},
{
"dimension": "authority",
"status": "covered",
"notes": "Actionability level, authorising reference with validity, restriction limits, separation of duties, intervention rights and automated-performer boundaries are modelled; the separation-of-duties rule rests on the NIST control family rather than on individual control text."
},
{
"dimension": "measurement",
"status": "gap",
"notes": "Percent complete has direct primary support, but effort estimation, consumption and variance units have only weak support in the retrieved sources. Effort and cost accounting are deferred to a sibling model and this dimension is presented as incomplete rather than canonical."
},
{
"dimension": "evidence and quality",
"status": "covered",
"notes": "Acceptance and verification records, evidence bundles with digests, integrity protection and sufficiency judgement are modelled, drawing on OSLC review predicates, FHIR outputs and NIST audit controls."
},
{
"dimension": "spatial",
"status": "covered",
"notes": "Execution location, geographic position, resources and time-zone context for deadlines are modelled from iCalendar LOCATION, GEO and RESOURCES and from the FHIR task location element; routing optimisation and geofencing are out of scope."
},
{
"dimension": "security and privacy",
"status": "covered",
"notes": "Confidentiality classification, disclosure control on fault payloads, evidence integrity, agent scope expiry at terminal state and personal-data minimisation are modelled; enforcement mechanisms belong to the interface projection."
},
{
"dimension": "exceptions",
"status": "covered",
"notes": "Blocking with resume conditions and timeouts, empty performer sets, release and delegation, failure and rejection classification, break-glass access, legal hold and terminal-state update arrival are each modelled as explicit questions."
}
],
"known_omissions": [
"Cost, rate, invoicing and financial variance of work, deferred to a finance or cost model.",
"Competency, skill taxonomy and certification management beyond an eligibility reference.",
"Queue optimisation, workload balancing and dispatch algorithms, which are operational policy rather than task context.",
"Safety-critical and regulated-AI obligations for delegating work to automated performers; no legislative or sector source was retrieved in this pass.",
"Robotics motion-level or actuator-level decomposition, consistent with the registry robotics factor of zero for this model.",
"Negotiation, bidding and market-based task allocation protocols.",
"Localisation and internationalisation of presentation text beyond noting that presentation elements exist.",
"Offline and disconnected reconciliation semantics beyond sequence-based ordering.",
"Work breakdown structure vocabulary from ISO project-management standards, which could not be retrieved.",
"Full ISO 21502:2020 clauses beyond the public work-package definition remain paywalled.",
"BPMN 2.0.2 Task types (user, service, script, manual, business-rule, send, receive) were not read from the normative PDF and are not treated as canonical here.",
"OSLC Change Management, IHE XDW, JSCalendar Task conversion, RFC 5546 iTIP scheduling and CalDAV access protocols were not fetched.",
"IETF draft-okutomi-agent-human-interaction is emerging and not used as a primary source.",
"Military METL, legal obligation tasks, education assignments and GTD personal-productivity methods lack primary support in this pack.",
"No single global Task IRI registry exists.",
"Percent-complete semantics under composite routing patterns are only sketched from WS-HumanTask completion conditions."
],
"conflicts": [
"Priority scales are mutually incompatible: WS-HumanTask uses an integer range in which the lowest number is the highest priority, iCalendar reserves zero for undefined and runs one to nine from highest to lowest, OSLC uses named individuals with an explicit unassigned value, and FHIR uses an urgency code list. No lossless conversion exists, so the scale identifier is mandatory.",
"Terminal-state semantics conflict: A2A states that a task reaching a terminal state cannot be restarted and accepts no further messages, whereas FHIR and WS-HumanTask permit correction or return paths from active states. The model adopts immutability by default and records the permissive behaviour as a declared exception.",
"Identity assignment authority conflicts: A2A requires the server to generate the task identifier and forbids clients from supplying one, iCalendar expects a globally unique client-assigned UID, and FHIR distinguishes a logical resource identifier from business identifiers. The identity priority rule resolves this by deferring to the master system.",
"State vocabularies differ in granularity, from four values for a to-do component through eight agent states and ten human-task states to more than ten FHIR statuses; several distinctions, such as reserved versus in progress, or rejected versus failed, cannot survive a round trip.",
"Status is commonly conflated with participation status: for a to-do component the status property is limited to four values, while accepted, declined, tentative and delegated belong to the participation status of an attendee. The model keeps task status and per-assignee participation status as separate elements.",
"Boolean state predicates in OSLC allow combinations, such as simultaneously closed and fixed and verified, that no single enumerated state can express; the mapping to a canonical state is therefore lossy in one direction.",
"Temporal exclusivity differs: a to-do component may not carry both a due time and a duration, while FHIR permits an execution period with both start and end, so a precedence rule must be declared per deployment.",
"Status vocabularies conflict: FHIR twelve codes versus VTODO four versus ActionStatusType four versus Graph five versus WS-HumanTask richer human-task states. Native codes are retained.",
"Priority scales conflict: FHIR routine/urgent/asap/stat versus iCalendar 0-9 versus Graph low/normal/high versus WS-HumanTask integer priority.",
"Identifier stability conflicts: Graph todoTask id changes when moved between lists; FHIR Resource.id is assigned once; iCalendar UID is required and persistent.",
"Hierarchy conflicts: VTODO cannot nest; FHIR partOf and WS-HumanTask composite tasks allow children.",
"Intent-versus-event: FHIR Task spans intent and event; schema.org Action and PROV Activity describe occurrences; a proposal Task is not the same individual as its later execution record if intent is immutable.",
"Homonym: Amazon ECS task is a compute unit, not this work-item Task."
],
"regional_assumptions": [
"Data-protection, worker-monitoring and works-council constraints on recording performer identity and progress are jurisdiction-specific; attempts to retrieve legislative text failed in this pass, so no statutory claim is made and the adopting Dimension must supply the governing instrument.",
"Deadlines are meaningful only against a local civil calendar, working-hours calendar and time zone, which vary by region and by employer; the model records the time zone of performance but does not embed any working calendar.",
"Healthcare-specific alignment through FHIR assumes a clinical deployment; outside healthcare the FHIR crosswalk is optional and its encounter and insurance concepts have no counterpart.",
"Language, script and text direction of presentation elements and comments are locale-dependent and are carried as data rather than constrained by this model.",
"Records-retention schedules and legal-hold procedures differ by jurisdiction and sector; the retention class is a pointer into a Dimension-supplied schedule, not a period asserted here.",
"Healthcare examples (encounter, beneficiary, insurance) follow HL7 FHIR and are optional outside clinical Dimensions.",
"Confidentiality CLASS follows iCalendar PUBLIC/PRIVATE/CONFIDENTIAL; regional privacy law (for example GDPR erasure versus audit retention) is a Dimension policy overlay, not a universal Task rule.",
"WS-HumanTask people assignment assumes an organizational directory whose schema is out of scope.",
"Time zones in Graph dateTimeTimeZone must be projected to RFC 3339 instants with explicit offset or Z for canonical storage."
],
"adversarial_checks": [
"Searched for a normative international project-management vocabulary to ground work-breakdown and activity terms; the standards body's catalogue and browsing platform both returned HTTP 403, so no claim is derived from that family and the work-breakdown vocabulary is recorded as an omission rather than presented as supported.",
"Tested collapsing Task into a provenance Activity. Rejected: a provenance activity is a retrospective assertion with no assignment, no deadline, no potential-owner set and no terminal failure classification, so the merge would lose the entire prospective surface. Provenance is retained as a required mix-in instead.",
"Tested modelling state as independent boolean predicates in the OSLC style rather than a single enumerated state. Rejected as the canonical form because independent booleans admit contradictory combinations and cannot express terminality; retained only as an alignment projection with a documented one-directional loss.",
"Verified the to-do status value set directly against the normative section after an initial extraction returned a seven-value list that mixed in participation-status values. The four-value set was confirmed and the conflation is now recorded as a documented distinction rather than propagated as fact.",
"Sought a counterexample to mandatory assignment: agent-executed tasks in A2A have no owner, no human role and no potential-owner set. Assignment is therefore modelled as optional, and the empty potential-owner set is an explicit question with a defined fallback rather than an error case.",
"Tested whether a due date could serve as identity for occurrences of a recurring task. Rejected: recurrence requires a per-occurrence identifier, and the identity rule states explicitly that a date is never an identifier.",
"Rejected agile artefacts such as definition of done, story points, sprints and burndown as canonical structural nodes, since no primary standard support was found for them; the underlying need is served by the evidence-backed completion criteria and acceptance finding, and the agile vocabulary is listed as an omission.",
"Checked the depth of evidence behind the process and case notation citations: only specification metadata and scope statements were retrievable, not the task-type and marker detail. Those sources are therefore cited solely for the definition-versus-instance boundary, and no claim about specific task types is attributed to them.",
"If a consumer treats lastModified or due date as the Task identifier, identity policy is violated.",
"If basedOn and focus are collapsed, fulfillment authorization is mis-attributed.",
"If entered-in-error is physically deleted immediately, FHIR retention rationale that the Task may have been used is violated.",
"If VTODO non-nesting is used to reject FHIR subtasks, a projection rule has been mistaken for a Task semantic.",
"If Graph waitingOnOthers or deferred is dropped because FHIR lacks those codes, a rare lifecycle path is lost.",
"If notifications are stored as Tasks without a one-way flag, WS-HumanTask notification semantics are violated.",
"If a Dimension claims FHIR or iCalendar conformance from this alignment union, the claim is unsupported."
]
},
"researchAdjudication": {
"providerMode": "dual-provider",
"activeProviders": [
"claude",
"grok"
],
"waivedProviders": [],
"providerPolicy": {},
"boundaryDecision": {
"entry_kind": "aggregate",
"status": "accepted",
"rationale": "The providers disagree (claude: aggregate, grok: entity) and the base wins on its own evidence. The base scope statement draws an explicit consistency boundary: the task record plus parts that have no independent identity outside it (status history, role assignments, deadlines, typed inputs and outputs, progress measurements, provenance entries), with projects, plans, work orders, parties and produced documents held as typed edges to sibling models. Grok labels the same thing an entity while still nesting lifecycle history, assignment records, evidence packs, input-output payloads and checklist items inside it, which are precisely non-independent parts; its own boundary notes also defer project, work order and plan to sibling models. Aggregate is therefore the classification the structure of both packs already implies, and it is what makes the transition log, acceptance record and evidence bundle governable as parts rather than as free-standing entities."
},
"decisions": [
{
"concept": "Base provider selection",
"disposition": "Claude adopted as base",
"rationale": "Size was not decisive; boundary quality was. The base supplies nine boundary notes each with a stated distinction and source refs, an out-of-scope list that names the sibling models by registry id, an inline_only_rationale on every finding that mints no artifact, and a coverage checklist that declares two honest gaps. Grok's pack is thinner on boundary reasoning and marks retention as covered on evidence that does not support it."
},
{
"concept": "Source citation hygiene for RFC 5545",
"disposition": "Base hygiene prevails; re-anchor all merged iCalendar claims",
"rationale": "The base cites RFC 5545 at the IETF and marks the icalendar.org reproduction as non-primary tier 3. Grok cites RFC 5545 solely through icalendar.org mirrors while labelling them primary tier 1. Any iCalendar-derived content entering from the additions must be re-anchored to the normative IETF text before publication."
},
{
"concept": "Identifier stability under relocation",
"disposition": "Rejected as a separate finding; carried as a conflict on f-task-identity-and-identifiers",
"rationale": "Grok's task-identifiers finding matches the base identity finding and would duplicate it, but its concrete observation that a Microsoft Graph todoTask id changes when the item moves between lists, against immutable FHIR Resource.id and persistent iCalendar UID, is a real contradiction the base does not record. Add it to the merged conflict set under the existing identity-priority resolution rule rather than minting structure."
},
{
"concept": "Workflow status and rare lifecycle paths",
"disposition": "Rejected as duplicative",
"rationale": "The base f-canonical-state-model, f-interruption-blocking-and-input-requirements and f-failure-cancellation-and-exceptions already govern state vocabulary, terminality, business status qualification, blocking with resume conditions and the five-way classification of unsuccessful endings including entered-in-error. Grok's status-machine and rare-paths layers restate this from a narrower source set."
},
{
"concept": "Suspend and resume propagation to subtasks",
"disposition": "Deferred, not accepted as structure",
"rationale": "Grok's claim that suspending a task suspends its children and resuming resumes them is a genuine state-propagation rule with no counterpart in the base, which only asks about history propagation in q-history-subtask-propagation. It is too thin to justify a finding on one source and belongs in the deferred queue for grounding against the composite-task text."
},
{
"concept": "Composition, temporal and input-output layers from Grok",
"disposition": "Rejected as duplicative",
"rationale": "parent-child-and-group, temporal-bounds and inputs-outputs-and-restrictions are each covered more finely by the base: decomposition plus four typed dependency relations with lead or lag from RFC 9253, separate anchor and deadline findings with timestamp discipline, and separate input, output, acceptance and progress findings. Grok's fulfillment restriction content is already the base question q-authorization-limits on repetitions, period and named recipient."
},
{
"concept": "AGENTS.md bootstrap contract artifact",
"disposition": "Rejected outright",
"rationale": "Grok mints a-agents-bootstrap as an artifact of the Task model inside its access and retention layer. This is working-environment leakage into a format-neutral context model and would bind the model to one tooling convention. It must not enter the merged artifact set under any layer."
},
{
"concept": "Location, resources and virtual place",
"disposition": "Rejected as duplicative",
"rationale": "The base f-execution-constraints-and-resources governs preconditions, required resources and instruments, and place of performance as inline constraints referring out to sibling asset, facility and party models, and its spatial checklist entry already records LOCATION, GEO and RESOURCES coverage. Grok's virtual-location nuance does not justify parallel structure."
},
{
"concept": "Retention and deletion coverage status",
"disposition": "Retain the base gap declaration; reject Grok's covered status",
"rationale": "Grok marks retention covered on the strength of the FHIR rationale that an entered-in-error record may already have been used, plus a Dimension policy overlay. That supports a retention rationale, not a schedule, lawful basis or erasure right. The base position, that no legislative text was retrieved and no statutory period is asserted, is the defensible one and must survive the merge."
},
{
"concept": "Effort and progress measurement",
"disposition": "Retain as a declared gap",
"rationale": "Only percent complete has direct primary support in either pack. Neither provider retrieved a source for effort estimation, consumption or variance units, so the base gap declaration stands and effort accounting remains deferred to a sibling cost model rather than being presented as canonical."
},
{
"concept": "Agentic and automated-performer surface",
"disposition": "Retained from base, no Grok equivalent",
"rationale": "The base carries A2A-grounded coverage of server-assigned task identity, terminal-state immutability, automated performer limits without human confirmation, and the on-behalf-of accountability chain. Grok has no agentic source at all, so this surface exists only because the base was chosen and must not be diluted during merge."
},
{
"concept": "Typed dependencies with lead or lag",
"disposition": "Retained from base, no Grok equivalent",
"rationale": "Finish-to-start, start-to-start, finish-to-finish and start-to-finish relations with gap, grounded in RFC 9253 and OSLC, exist only in the base. Grok models composition but not ordering constraints, so nothing in the additions may weaken f-inter-task-dependencies-and-gaps."
},
{
"concept": "ISO 21502 work-package boundary grounding",
"disposition": "Noted, not merged as evidence",
"rationale": "Grok grounds the project-versus-task granularity boundary in ISO 21502, but concedes that clauses beyond the public work-package definition are paywalled. The base boundary note for WM-ACT-005 stands on its own sources; the ISO anchor goes to deferred research rather than into the merged register on preview text."
},
{
"concept": "Source identifier remapping for accepted additions",
"disposition": "Mandatory synthesizer step",
"rationale": "Both accepted findings carry Grok-local source ids (SRC-001, SRC-002, SRC-004, SRC-006, SRC-009) that collide with different documents in the base register. The synthesizer must remap them into the merged register, adding Microsoft Graph todoTask, schema.org Action and the FHIR Task detailed descriptions page as new entries, before any draft is emitted."
},
{
"concept": "Service layer merge",
"disposition": "Merge service layers as instructed",
"rationale": "The base already governs functions as a flat operation set aligned to its findings, and the two accepted function additions slot into that single set. Keeping provider-specific service layers separate would fork the operation vocabulary across two naming conventions for the same lifecycle."
}
],
"publicationHolds": [
"Source verification hold: every URL and version pin in the merged register must be re-checked live before publication. Specific items: the two FHIR Task URLs differ between providers (hl7.org/fhir/R5/task.html versus hl7.org/fhir/task.html) and must be reconciled to one version-pinned R5 address; the A2A specification is cited as 'latest released' and must be pinned to an immutable version; the OMG BPMN and CMMN pages were only reachable at specification-metadata depth; and the base records an HTTP 403 on the project-management standards catalogue.",
"Citation-provenance hold: all iCalendar claims arriving with the accepted Grok findings are anchored to icalendar.org reproductions labelled tier 1 by that provider. Re-anchor each to RFC 5545 at the IETF before publication, and keep the reproduction marked non-primary tier 3 as the base does.",
"Multi-profile validation hold: the merged model must be exercised against at least four domain profiles before any cross-domain adequacy claim: clinical workflow (FHIR Task), personal and calendaring to-do (VTODO and Microsoft Graph todoTask), organisational human workflow (WS-HumanTask and BPMN), and agent-to-agent execution (A2A). Only the first three are represented in both packs; the agentic profile rests on a single provider.",
"Retention hold: publish no statutory retention period, lawful basis or erasure right. No legislative or regulatory text was retrieved by either provider, and the retention dimension must ship as a declared gap pointing at a Dimension-supplied schedule.",
"Conformance-claim hold: the merged model is an alignment union. Block any wording that asserts conformance to FHIR, iCalendar, WS-HumanTask, schema.org or PROV-O; round-trip fidelity per crosswalk has not been tested, and the base already records lossy one-directional mappings for OSLC boolean predicates and for state-vocabulary granularity.",
"Source-remapping hold: do not emit a draft until Grok-local SRC ids on the two accepted findings are remapped into the merged register and the three newly carried sources (Microsoft Graph todoTask, schema.org Action, FHIR Task detailed descriptions) are added with their own tier and primary flags."
],
"deferredResearch": [
"Prohibitive task semantics (a task requesting that an action not occur, bounded by period or phase): grounded so far only in FHIR doNotPerform. Seek a second independent primary source before treating negative tasks as a canonical structural feature rather than an alignment nuance.",
"State propagation across composition: whether suspending a parent suspends its children and resuming restores them, and whether a stop from in-progress returns the task to ready for reassignment. Ground against the WS-HumanTask composite-task text and the FHIR status transition guidance.",
"Effort estimation, consumption and variance units, plus percent-complete semantics under parallel and mixed routing patterns. Neither provider retrieved a normative source; resolve with a sibling effort and cost model rather than by extending this aggregate.",
"Work breakdown structure and activity vocabulary from the project-management standards family, including ISO 21502 clauses beyond the public work-package definition. Blocked by HTTP 403 in one pack and by paywall in the other.",
"Unfetched calendaring and workflow standards named as omissions: JSCalendar task conversion, RFC 5546 iTIP scheduling, CalDAV access, and IHE XDW cross-enterprise workflow. Check whether any of these contradicts the accepted temporal or composition findings.",
"Safety-critical and regulated-AI obligations governing delegation of work to automated performers, and jurisdictional worker-monitoring and works-council constraints on recording performer identity and progress. No legislative or sector source was retrieved in either pass.",
"Re-verify the Microsoft Graph identifier re-key behaviour on list move against the live vendor documentation, since the identifier-stability conflict admitted into the merged conflict set rests on a single tier-2 vendor page."
]
},
"statistics": {
"sources": 23,
"bundles": 6,
"layers": 13,
"findings": 30,
"questions": 104,
"artifacts": 18,
"functions": 12
}
}