Task

Task instance identity and identifier correlation

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.

1. Which system of record holds the authoritative identifier for this task instance, and what is that identifier value? identity
2. Within what namespace is the identifier guaranteed unique, and is uniqueness global or scoped to one server? constraint
3. Which additional business, group or external identifiers correlate this task across exchanging systems? interoperability
4. If the work repeats, is each occurrence separately identified or derived from one recurring definition? identity

Binding to a reusable task definition and its version

Which definition, process model or case model the instance realises, at which version, and how divergence from it is authorised and detected.

1. Which reusable task definition or process model does this instance instantiate, and at which pinned version? definition
2. Where does the running instance deviate from its definition, and who authorised the deviation? validation
3. How are later changes to the definition propagated to instances that are already running? lifecycle
4. Was this task planned in advance by a definition or added discretionarily during execution? decision

Descriptive identity and confidentiality class

Human-readable name, description, categories and iCalendar CLASS distinguish the Task for people and access control without serving as identity.

1. What title or summary and free-text description should a human or agent use to recognize this Task? definition
2. Which categories, tags or outlook-style labels classify this Task for queues and search? classification
3. Is the Task public, private or confidential, and what privacy rules follow from that class? privacy

Task type, category and performer kind

The controlled codes that classify the kind of work and whether it is to be performed by a person, an automated agent, or both.

1. What controlled code classifies the kind of work this task represents? classification
2. Is the work to be performed by a human, by an automated agent or service, or by a combination? classification
3. Which taxonomy governs these codes, who may extend it, and how are local extensions marked? authority

Priority scale, urgency and severity

How ranking is expressed, in which direction the scale runs, and how business impact is kept distinct from scheduling urgency.

1. Which priority scale is in force, in which direction does it run, and what does an absent value mean? measurement
2. Is business impact recorded separately from scheduling urgency on this task? classification
3. How is the local priority mapped when exchanged with a system using a different scale, and what precision is lost? interoperability
4. Who may change a task's priority after creation, and is the change recorded with a reason? authority

Authorisation reference and actionability level

Whether the task is a proposal, a plan or an authorised order, which instrument authorises it, and what limits that authorisation carries.

1. At what level of actionability does this task exist: proposal, plan, or authorised order? authority
2. Which request, work order or higher-level authorisation caused this task to exist, and is it still valid? provenance
3. What does the authorisation permit and forbid in terms of repetitions, period and named recipient? constraint

Accountability, oversight and automated performer limits

Who stays accountable when execution is delegated, what an automated performer may do unattended, and which role combinations are prohibited.

1. Which party remains accountable for the outcome when execution is delegated to another person or to an automated agent? ownership
2. What may an automated performer do without a human confirmation step, and how is that boundary enforced? security
3. Which combinations of requester, performer and approver are prohibited on the same task? constraint
4. Who may intervene to suspend, reassign or terminate the task, and on what stated grounds? decision

Based-on authorization versus focus object

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.

1. What higher-level authorization or request created this Task, if any? relationship
2. What object, request or resource is this Task acting on, and must subtasks be used if more than one resource is manipulated? composition
3. Who benefits from the Task, and is the Task asking that the action not occur? constraint

Role assignment and performer eligibility

Which parties hold which role on the task, how the potential performer set is resolved, and what eligibility a performer must satisfy.

1. Which parties hold each role on this task: initiator, potential owners, actual owner, stakeholders, administrators and excluded owners? ownership
2. What competence, qualification, licence or system capability must a performer hold to be eligible? requirement
3. How is the potential performer set resolved: by literal party list, by group query, or by expression over task data? process
4. Is an unassigned task valid, and what happens when the potential performer set resolves to empty? exception

Claiming, release, delegation and forwarding

The operations that move ownership between parties, the permissions that govern them, and whether responsibility travels with the work.

1. What operation makes a party the actual owner, and may more than one party hold the task simultaneously? process
2. Under what conditions may an owner release the task, and to which state does it return? exception
3. Who is permitted to receive a delegated or forwarded task, and does accountability transfer with it? access
4. How is a performer's response to an assignment recorded when it differs from the task's own status? state

State vocabulary, terminality and status qualification

The governed set of states, which are terminal, and how coded state is qualified by a reason and a domain-specific business status.

1. What is the task's current state in the governed vocabulary, and when was that state entered? state
2. Which states are terminal, and may a terminal task be reopened or must a successor task be created? lifecycle
3. What reason and domain-specific business status qualify the coded state beyond the enumerated value? definition
4. How does the local state map onto each aligned external vocabulary, and which distinctions cannot be preserved? interoperability

Suspension, blocking and outstanding input requirements

Why progress has stopped, exactly what must happen to resume, and how long a stalled task may remain in that condition.

1. What is blocking progress: missing input, missing authorisation, an unmet dependency, or a deliberate hold? exception
2. What exact condition must be satisfied for work to resume, and who is able to satisfy it? constraint
3. How long may the task remain blocked before escalation or automatic termination applies? temporal

State transition events and tamper-evident history

What is recorded for each transition, how event time is kept distinct from recording time, and how completeness of the history is demonstrated.

1. What is captured for each state transition: prior state, new state, actor, reason and time? event
2. Is the time a transition occurred recorded separately from the time the system observed or ingested it? temporal
3. Is the transition history complete and tamper-evident, and how would a missing entry be detected? evidence
4. Which transitions on subtasks are propagated to the parent task's history, and which stay local? relationship

Failure, rejection, cancellation and error classification

How unsuccessful endings are distinguished from one another, what fault detail is retained, and what compensating action follows.

1. How is an unsuccessful ending classified: failed, rejected, cancelled, obsolete, or entered in error? classification
2. What fault or error payload is retained, and is it safe to disclose to the requester? evidence
3. What compensating, retry or successor action follows, and does it reuse the same task identity? process

Temporal anchors and timestamp discipline

The set of time anchors a task carries, their required format and offset handling, and which clock prevails in a dispute.

1. Which time anchors are recorded: authored, planned start, due, actual start, actual end and last modified? temporal
2. Are all time values expressed with seconds and an explicit offset, and how is an unknown local offset represented? validation
3. In which local time zone or civil calendar is a deadline meaningful for the performer? spatial
4. Which clock or system prevails when two systems report different times for the same transition? provenance

Deadlines, escalation actions and recurrence

Which deadlines bind the task, what fires when they pass, and how repeating work is instantiated and closed.

1. Which deadlines apply, latest start or latest completion, and are they contractual or advisory? requirement
2. What escalation fires when a deadline passes, to whom is it directed, and how often does it repeat? process
3. Does this work repeat on a rule, and how is each occurrence instantiated and closed? temporal
4. When both an absolute due time and a duration are present, which one governs? constraint

Parent, subtasks and grouping

How a task sits inside a parent, project or work order, how subtasks execute, and how their outcomes assemble into the parent result.

1. Which parent task, work order or project does this task belong to, and is that membership exclusive? composition
2. Are subtasks executed in parallel or in sequence, and are they created automatically or on demand? process
3. What condition over subtask outcomes completes the parent, and how is the parent result assembled? lifecycle

Typed dependencies, lead and lag

How ordering constraints between tasks are typed, how lead or lag is expressed, and how cycles and cross-system references are handled.

1. What dependency type links this task to another: finish-to-start, start-to-start, finish-to-finish, start-to-finish, or a plain dependency? relationship
2. What lead or lag applies to the dependency, and in which duration units? measurement
3. How are dependency cycles and dangling references detected and rejected? validation
4. How is a dependency on a task held in another system or organisation expressed and resolved? interoperability

Reference to plan or schedule

How the task points at an independently versioned plan, and which side prevails when planned and actual timing disagree.

1. Which plan or schedule version places this task, and is that reference pinned to a version? relationship
2. How is variance between planned and actual timing measured and reported back to the plan? measurement
3. When the plan and the task disagree about dates, which one is authoritative? authority

Typed inputs, parameters and subject focus

The typed information a task consumes, when each value is bound, what the task acts upon, and how inputs are validated.

1. What typed inputs, parameters and attachments must be present before work can start? composition
2. Which input values are bound at creation and which are supplied during execution? process
3. How are inputs validated against the task definition, and what happens when validation fails? validation
4. What entity does this task act upon, and for whose benefit is it performed? relationship

Completion criteria, acceptance and verification

What must hold for the task to count as complete, who accepts the result, and whether acceptance is separate from completion.

1. What conditions must hold for the task to count as complete, and are they machine-checkable? requirement
2. Who accepts, reviews or verifies the result, and is acceptance a separate step from completion? authority
3. Is partial or conditional completion permitted, and how is it represented without misreporting success? state

Preconditions, resources, instruments and location

The conditions that must hold to execute, the resources and instruments required, and where performance must take place.

1. What preconditions, safety rules or policy constraints must hold before and during execution? constraint
2. Which resources, tools, systems or instruments are required, and are any reserved exclusively for this task? requirement
3. Where must the work be performed, and is that location a hard constraint or advisory? spatial

Outputs, produced artifacts and derivation

What the task produces, how each output is identified and linked to the inputs it came from, and whether outputs may change after closure.

1. What outputs, artifacts or deliverables does the task produce, and is each individually identified? composition
2. How is each output linked to the task that generated it and to the inputs it was derived from? provenance
3. Are outputs immutable once the task reaches a terminal state, or may they be superseded? quality

Progress reporting and effort accounting

How progress is quantified, what effort was estimated and consumed, and how far a self-reported figure can be trusted.

1. How is progress quantified, on what scale, and who is permitted to update it? measurement
2. What effort or duration was estimated and what has actually been consumed, in which units? measurement
3. How reliable is a self-reported progress figure, and what independent signal corroborates it? quality

Execution provenance and attribution

Which agent performed each step, in which role and on whose behalf, and which entities were used and generated.

1. Which agent actually performed each step, in which role, and on whose behalf did it act? provenance
2. Which entities were used and which were generated, with start and end times for the activity? evidence
3. Which plan or definition qualified the agent's association with this task? relationship

Evidence capture, integrity and sufficiency

What evidence must be captured to prove the work was done as specified, how its integrity is protected, and who judges sufficiency.

1. What evidence must be captured to prove the work was performed as specified? evidence
2. How is evidence integrity protected against later alteration? security
3. What makes the captured evidence sufficient for audit, and who decides sufficiency? quality

Visibility, classification and exceptional access

Who may see or change the task and its content, what classification applies, and how emergency access is authorised and reviewed.

1. Who may see the task, its inputs and its outputs, and does visibility follow role assignment on the task? access
2. What confidentiality classification applies to the task, and does it differ from that of its attachments? security
3. How is emergency or break-glass access authorised, recorded and afterwards reviewed? exception

Personal data, retention period and erasure

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.

1. Which task fields can carry personal data about performers or subjects, and are they minimised? privacy
2. How long are the task record, its history and its attachments retained after closure, and under whose authority? retention
3. Is deletion logical or physical, and what tombstone remains for audit after erasure? retention
4. How does a legal hold or investigation suspend a scheduled deletion, and who lifts it? exception

Alignment crosswalks and conformance evidence

Which external vocabularies the model is aligned to, which fields and states survive a round trip, and what evidence any conformance claim rests on.

1. Which external task vocabularies is this model aligned to, and at which versions? interoperability
2. Which fields and states survive a round trip to each aligned vocabulary without loss? validation
3. What evidence supports a conformance claim, and where is alignment only partial? evidence

Concurrency, idempotency and ordering on exchange

How competing updates, duplicate requests and out-of-order status delivery are detected and resolved between systems.

1. How are concurrent updates to the same task detected and resolved: sequence number, revision token, or last writer wins? constraint
2. How are duplicate create or transition requests recognised and made idempotent? process
3. How is out-of-order delivery of status updates detected and corrected? temporal
4. What happens when an update arrives for a task that has already reached a terminal state? exception