# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-25T13:05:28Z", "synthesisSha256": "41f21cb666ec94fe0779203bd7f201fc8e1dc873cf33dc5fdd50e9c176324e20", "providers": [ "Claude", "Grok" ] }, "metaModel": { "id": "WM-ACT-008", "registryId": "vr.wm-act-008", "name": "Plan / Schedule", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "aggregate", "family": "World Models", "category": "Activities and processes", "industry": [ "Cross-industry" ], "domain": [ "ACT.PLN" ], "tags": [ "plan", "schedule", "act.pln" ], "status": "research draft" }, "canonicalUrl": "https://ver.cy/models/wm-act-008-plan-schedule/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-act-008", "model": { "registry_id": "vr.wm-act-008", "model_id": "WM-ACT-008", "name": "Plan / Schedule", "entry_kind": "aggregate", "purpose": "Represent intentions bound to time: what an agent intends to do, how firmly, when, in what order, under which commitments, and how the intention was later revised or realized.", "scope_statement": "This model is the composite root for a plan: an identified, versioned statement of intention held by an agent, together with the planned actions it contains, their binding to instants, intervals, deadlines and recurrence patterns, the ordering and date constraints among them, the commitments that make some intentions binding on third parties, and the baselines, change records, progress and realization links that let intention be compared with what happened. It is deliberately independent of storage and interface: iCalendar, JSCalendar, a Gantt tool file, a Git-tracked Markdown plan or a MongoDB document are projections of the same semantics. It does not own agent identity, act records, process definitions or cost measurement.", "in_scope": [ "Plan identity, classification, intent strength, version and supersession", "Planned actions with preconditions, expected effects and effort estimates", "Binding of intended actions to instants, intervals, deadlines, durations and recurrence patterns, including time zone and floating-time semantics", "Ordering dependencies, lag, date constraints, and the dates, float and critical path derived from them", "Resource and participant assignment, availability and contention", "Commitments binding an agent to a beneficiary, with consequences, remedies and release", "Baselines, change logs, progress actuals, variance, realization links and plan closure", "Disclosure level, access grants, provenance and retention of plan and schedule records" ], "out_of_scope": [ "Completed acts and their observations, owned by the act/action model", "Standing process or workflow definitions, which are types rather than dated intentions", "Agent identity, roles and organizational structure", "Cost estimates, budgets and earned-value measurement", "Calendar transport, storage and synchronization protocols (CalDAV, JMAP, iTIP bindings) as engineering surfaces", "Motion planning and robot trajectory generation", "Contract formation and enforcement beyond binding an intention to a beneficiary" ], "boundary_notes": [ { "neighbor": "WM-ACT-006 Task", "distinction": "A task is an assignable unit of work with its own lifecycle and assignee; it references the plan that authorizes it. The plan is versioned independently, so a task state change does not revise the plan. JSCalendar keeps Event and Task as distinct object types for the same reason.", "source_refs": [ "SRC-003", "SRC-010" ] }, { "neighbor": "Act / Action model (legacy world.actAction, K2)", "distinction": "An act is a completed occurrence with observation evidence; a planned action is an intention that may never occur. PROV models this as an Activity that used a Plan, keeping plan and activity as separate entities rather than states of one thing.", "source_refs": [ "SRC-007" ] }, { "neighbor": "Process & Workflow model (legacy world.processAndWorkflow, K3)", "distinction": "A process definition is a reusable type with no dates; a plan is a dated instance of intention that may instantiate such a definition. Recurrence rules belong here, process step definitions do not.", "source_refs": [ "SRC-007", "SRC-015" ] }, { "neighbor": "Project model (legacy world.project, K5)", "distinction": "A project is an endeavour with governance, funding and deliverables; its integrated schedule and baselines are bound from this model rather than redefined. GAO treats schedule assessment and cost estimating as linked but separate bodies of guidance.", "source_refs": [ "SRC-012" ] }, { "neighbor": "Calendar service and free/busy interface", "distinction": "A calendar is a container and access surface. Agenda, Gantt and busy-only views are projections of plan semantics; disclosure class and transparency are modelled here, the serving protocol is not.", "source_refs": [ "SRC-001", "SRC-002" ] }, { "neighbor": "Obligation / contract model", "distinction": "Only the binding of an intention to a named beneficiary is in scope, aligned to an ODRL Duty within an Agreement. Contract formation, consideration and enforcement remain external.", "source_refs": [ "SRC-009" ] }, { "neighbor": "Time zone reference data", "distinction": "Zone identifiers and their rules are referenced from the IANA database and never copied into the model; only the identifier and the database release in force are recorded.", "source_refs": [ "SRC-006", "SRC-005" ] } ] }, "sources": [ { "id": "SRC-001", "title": "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc5545.html", "version_or_date": "September 2009, Standards Track (obsoletes RFC 2445)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Normative source for schedule entry components, STATUS values, DTSTART time forms (UTC, TZID local, floating, date-only), RRULE, RDATE, EXDATE, RECURRENCE-ID with RANGE, RELATED-TO, SEQUENCE, TRANSP, CLASS, PRIORITY, PERCENT-COMPLETE and VFREEBUSY." }, { "id": "SRC-002", "title": "RFC 5546: iCalendar Transport-Independent Interoperability Protocol (iTIP)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://datatracker.ietf.org/doc/html/rfc5546", "version_or_date": "December 2009, Proposed Standard", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Normative source for Organizer/Attendee authority, PARTSTAT response states, COUNTER and DECLINECOUNTER negotiation, and conflict resolution by UID then SEQUENCE then DTSTAMP." }, { "id": "SRC-003", "title": "RFC 8984: JSCalendar: A JSON Representation of Calendar Data", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc8984.html", "version_or_date": "July 2021, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Normative source for Event/Task/Group typing, mandatory uid and updated, sequence, start/duration/due/estimatedDuration, timeZone and floating LocalDateTime, recurrenceRules and recurrenceOverrides, participants, progress, privacy and freeBusyStatus; mandates RFC 3339 form for UTC timestamps." }, { "id": "SRC-004", "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": "July 2002, Proposed Standard (updated by RFC 9557)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Normative timestamp profile of ISO 8601: mandatory fields, explicit numeric offset or Z, seconds including leap-second value 60, and the distinct meaning of -00:00 for unknown local offset." }, { "id": "SRC-005", "title": "RFC 9557: Date and Time on the Internet: Timestamps with Additional Information", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9557.html", "version_or_date": "April 2024, Standards Track", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines IXDTF bracketed suffix tags so an IANA time zone name travels with an RFC 3339 timestamp, redefines Z as 'UTC known, local offset unknown', and specifies handling when a stored offset conflicts with a critical time zone tag." }, { "id": "SRC-006", "title": "Time Zone Database (tz / zoneinfo)", "organization": "Internet Assigned Numbers Authority (IANA)", "url": "https://www.iana.org/time-zones", "version_or_date": "Release 2026c, 8 July 2026", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Authoritative registry of time zone identifiers and historical and future offset and daylight-saving rules; release 2026c records Alberta moving to permanent -06 and Morocco to permanent +00, demonstrating that stored future local times can be invalidated by a data release." }, { "id": "SRC-007", "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-25T00:00:00Z", "relevance": "Normative treatment of prov:Plan as the plan an agent intended to follow, exposed through prov:qualifiedAssociation and prov:hadPlan, plus wasAssociatedWith, wasGeneratedBy, wasDerivedFrom and wasAttributedTo for plan provenance and the plan-to-activity link." }, { "id": "SRC-008", "title": "Time Ontology in OWL", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/owl-time/", "version_or_date": "W3C Candidate Recommendation Draft, 15 November 2022", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Formal vocabulary for Instant, Interval, ProperInterval, Duration, DateTimeDescription, temporal reference systems via hasTRS, Allen interval relations for ordering, and inXSDDateTimeStamp where the time zone field is mandatory. Not yet a Recommendation, so cited as alignment only." }, { "id": "SRC-009", "title": "ODRL Information Model 2.2", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/odrl-model/", "version_or_date": "W3C Recommendation, 15 February 2018", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Normative model for Duty and Obligation, Agreement between assigner and assignee, constraints as conditions on a rule, consequence for unfulfilled duties and remedy for infringed prohibitions; used to align commitment terms rather than inventing an obligation vocabulary." }, { "id": "SRC-010", "title": "FHIR ValueSet: RequestIntent", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/valueset-request-intent.html", "version_or_date": "FHIR R5 v5.0.0, 26 March 2023", "source_type": "classifier", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Published gradient of intentional authority: proposal (no authorization), plan (intention without authorizing others), directive, order and its order sub-kinds, and option; supplies an evidenced classifier for how firmly an intention binds." }, { "id": "SRC-011", "title": "FHIR Data Types (Timing)", "organization": "Health Level Seven International (HL7)", "url": "https://www.hl7.org/fhir/datatypes.html", "version_or_date": "FHIR R5 v5.0.0", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "An independent, non-iCalendar recurrence grammar (repeat with bounds, count, duration, frequency, period, dayOfWeek, timeOfDay, when, offset) used as a counterexample showing that recurrence models are not isomorphic and round-tripping is lossy." }, { "id": "SRC-012", "title": "GAO Schedule Assessment Guide: Best Practices for Project Schedules (GAO-16-89G)", "organization": "U.S. Government Accountability Office", "url": "https://www.gao.gov/products/gao-16-89g", "version_or_date": "GAO-16-89G, published 22 December 2015", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Public-authority statement that a reliable schedule is comprehensive, well-constructed, credible and controlled, expressed as ten best practices: capturing all activities, sequencing all activities, assigning resources, establishing durations, horizontal and vertical traceability, a valid critical path, reasonable total float, schedule risk analysis, updating with actual progress and logic, and maintaining a baseline schedule." }, { "id": "SRC-013", "title": "General Records Schedule 5.1: Common Office Records", "organization": "U.S. National Archives and Records Administration (NARA)", "url": "https://www.archives.gov/files/records-mgmt/grs/grs05-1.pdf", "version_or_date": "GRS 5.1, Transmittal No. 28 (July 2017) and subsequent transmittals", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Evidence that calendars and schedules of daily activities are scheduled records with authorized disposition: GRS 5.1 covers those of non-high-level officials, while high-level officials' records are addressed under GRS 6.1, establishing that retention of schedule data is role-dependent, not uniform." }, { "id": "SRC-014", "title": "Schedule (schema.org type)", "organization": "Schema.org Community Group", "url": "https://schema.org/Schedule", "version_or_date": "Live vocabulary, accessed 25 August 2026", "source_type": "schema", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "A third recurrence grammar (repeatFrequency, repeatCount, byDay, byMonth, byMonthDay, byMonthWeek, scheduleTimezone, exceptDate, duration) attached to Event via eventSchedule; used for the public-publication projection and to evidence divergence between recurrence vocabularies." }, { "id": "SRC-015", "title": "PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains", "organization": "Journal of Artificial Intelligence Research (Fox and Long)", "url": "https://arxiv.org/abs/1106.4561", "version_or_date": "JAIR Volume 20 (2003), arXiv posting 2011", "source_type": "scientific", "primary_source": true, "authority_tier": 3, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Reference semantics for machine planning: durative actions with duration constraints and conditions annotated at-start, over-all and at-end, plus preconditions and effects, grounding the planned-action structure used by autonomous planning agents." }, { "id": "SRC-016", "title": "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar)", "organization": "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-25T00:00:00Z", "relevance": "Primary calendaring object specification; aligned for calendar component, recurrence, free-busy, classification, attendee and identity properties. Recurrence expansion ambiguities are recorded as conflicts, not hidden." }, { "id": "SRC-017", "title": "RFC 9253: Support for iCalendar Relationships", "organization": "IETF", "url": "https://datatracker.ietf.org/doc/html/rfc9253", "version_or_date": "RFC 9253, August 2022", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Primary source for project-style temporal relations on calendar components: precedence types, GAP lead and lag, REFID grouping and LINK." }, { "id": "SRC-018", "title": "PROV-O: The PROV Ontology", "organization": "W3C", "url": "https://www.w3.org/TR/2013/REC-prov-o-20130430/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines Plan as an entity and the association hadPlan; aligned for attribution, revision, generation and invalidation of plan versions." }, { "id": "SRC-019", "title": "PROV-DM: The PROV Data Model", "organization": "W3C", "url": "https://www.w3.org/TR/2013/REC-prov-dm-20130430/", "version_or_date": "W3C Recommendation 30 April 2013", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Defines Plan as actions or steps intended by agents to achieve goals but leaves step structure to extensions; aligned for plan-as-entity, revision, generation and invalidation." }, { "id": "SRC-020", "title": "Time Ontology in OWL", "organization": "W3C and OGC", "url": "https://www.w3.org/TR/2022/CRD-owl-time-20221115/", "version_or_date": "W3C Candidate Recommendation Draft 15 November 2022", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Primary temporal topology vocabulary and the source of non-Gregorian TRS support beyond CALSCALE; aligned for Instant, ProperInterval, duration and Allen interval relations." }, { "id": "SRC-021", "title": "The P-PLAN Ontology", "organization": "Ontology Engineering Group, Universidad Politecnica de Madrid, and Information Sciences Institute, University of Southern California", "url": "https://www.opmw.org/model/p-plan/", "version_or_date": "Release 17 September 2013, revision 1.1", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Primary scientific extension that structures plans into Steps and Variables and links them to execution traces; aligned for isPreceededBy, correspondsToStep and correspondsToVariable." }, { "id": "SRC-022", "title": "HL7 FHIR CarePlan (Release 4)", "organization": "HL7 International", "url": "https://hl7.org/fhir/R4/careplan.html", "version_or_date": "FHIR R4 v4.0.1", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Primary instance-level care-intention resource; aligned for status and intent strength, partOf, basedOn, replaces and activity references. PlanDefinition remains out of scope." }, { "id": "SRC-023", "title": "ISO 21502:2020 Project, programme and portfolio management - Guidance on project management", "organization": "ISO", "url": "https://www.iso.org/standard/74947.html", "version_or_date": "ISO 21502:2020", "source_type": "standard", "primary_source": false, "authority_tier": 2, "accessed_at": "2026-08-25T00:00:00Z", "relevance": "Catalogue-level guidance treating schedule as structuring work, estimating durations, sequencing activities and maintaining a credible schedule baseline. Full text is paywalled, so baseline naming is an alignment with an evidence gap." } ], "structure": { "bundles": [ { "id": "b-plan-identity-and-authority", "name": "Plan Identity and Authority", "description": "What one plan is, how firmly it is intended, how its revisions are ordered, and who may change it.", "rationale": "Calendaring standards make a globally unique identifier and a modification timestamp mandatory and resolve replica conflicts by identifier, revision counter and timestamp; FHIR publishes an evidenced gradient of intentional authority. Identity and authority must therefore be settled before any temporal or content claim can be relied on.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003", "SRC-010" ], "layers": [ { "id": "l-identity-and-classification", "name": "Identity and Classification", "description": "The stable handle for a plan, its boundary against neighbours, and the class and strength of intention it asserts.", "source_refs": [ "SRC-003", "SRC-010", "SRC-007" ], "findings": [ { "id": "f-plan-identity-and-boundary", "name": "Plan identity and boundary", "description": "Establishes the immutable handle for one plan instance and what falls inside its envelope rather than in a referenced plan, task or project.", "source_refs": [ "SRC-001", "SRC-003", "SRC-007" ], "questions": [ { "id": "q-plan-authoritative-id", "text": "Which identifier is the authoritative, immutable handle for this plan, and which system issued it?", "kind": "identity", "answer_data": [ "Master-system identifier value", "Issuing system reference", "Identifier scheme or namespace", "Locally-minted flag" ] }, { "id": "q-plan-envelope", "text": "What distinguishes this plan from the adjacent plans, tasks and projects it references?", "kind": "definition", "answer_data": [ "Boundary statement", "Excluded neighbour references", "Rationale for separate identity" ] }, { "id": "q-plan-horizon", "text": "What planning horizon and time granularity does the plan claim to cover?", "kind": "temporal", "answer_data": [ "Horizon start and end", "Granularity unit", "Coverage caveat" ] }, { "id": "q-plan-membership", "text": "Which planned actions and schedule entries are constituent parts rather than merely referenced?", "kind": "composition", "answer_data": [ "Member references with part or reference role", "Containment rule" ] } ], "data_elements": [ { "id": "de-plan-identifier", "name": "planIdentifier", "description": "Authoritative immutable identifier for the plan, stable across revisions.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-001" ] }, { "id": "de-plan-name", "name": "planName", "description": "Human-readable name; never used as an identifier.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-planning-horizon", "name": "planningHorizon", "description": "Interval the plan intends to cover, with granularity.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "de-plan-member-ref", "name": "planMemberRef", "description": "Reference to a constituent planned action, entry or sub-plan, with part or reference role.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] } ], "artifacts": [ { "id": "art-plan-record", "name": "Plan record", "description": "The canonical object carrying plan identity, boundary, membership and horizon, from which all projections are derived.", "media_or_form": [ "structured object in any serialization", "iCalendar VCALENDAR containing VEVENT and VTODO components", "JSCalendar Group object", "human-readable plan document" ], "serial": false, "identity_strategy": "Authoritative master-system plan identifier; otherwise a governed globally unique identifier or IRI; otherwise a UUID or ULID minted by the adopting Dimension and marked as locally minted.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-plan-type-and-intent-mode", "name": "Plan type and intent mode", "description": "Classifies the kind of plan and the degree of authority its intention carries, which governs what an agent may act on unaided.", "source_refs": [ "SRC-010", "SRC-003", "SRC-015" ], "questions": [ { "id": "q-intent-mode", "text": "What degree of authority does this plan assert: proposal, plan, directive or order?", "kind": "classification", "answer_data": [ "Intent mode code", "Value set reference", "Authorizing statement" ] }, { "id": "q-plan-kind", "text": "Which plan kind applies, such as project schedule, operational routine, agent action plan or service plan?", "kind": "definition", "answer_data": [ "Plan kind code", "Domain profile reference" ] }, { "id": "q-actionable-without-approval", "text": "Which parties may act on this plan without a further approval step?", "kind": "authority", "answer_data": [ "Authorized actor references", "Approval-required flag", "Escalation path" ] }, { "id": "q-priority-scale", "text": "On what scale is priority or urgency expressed, and what does each level oblige?", "kind": "measurement", "answer_data": [ "Priority value", "Scale definition and direction", "Obligation per level" ] } ], "data_elements": [ { "id": "de-intent-mode", "name": "intentMode", "description": "Degree of intentional authority, aligned to the FHIR RequestIntent gradient.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-010" ] }, { "id": "de-plan-kind", "name": "planKind", "description": "Classifier for the type of plan.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-003" ] }, { "id": "de-plan-priority", "name": "planPriority", "description": "Priority or urgency on a declared scale; iCalendar uses 0-9 with 0 undefined.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-actionable-by-ref", "name": "actionableByRef", "description": "Agents permitted to execute against the plan without further authorization.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "art-intent-mode-value-set", "name": "Intent mode value set", "description": "Published controlled vocabulary of intent modes and plan kinds, with the obligation attached to each level.", "media_or_form": [ "code list or value set", "SKOS concept scheme", "tabular vocabulary export" ], "serial": false, "identity_strategy": "Governed value set IRI in the owner package namespace, with each concept carrying a stable code and a mapping to the external gradient it aligns to.", "source_refs": [ "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "l-versioning-ownership-and-authority", "name": "Versioning, Ownership and Authority", "description": "How revisions are ordered and reconciled, who owns the plan, and what authorization made it current.", "source_refs": [ "SRC-002", "SRC-003", "SRC-007", "SRC-012" ], "findings": [ { "id": "f-plan-version-and-supersession", "name": "Plan version and supersession", "description": "How successive revisions of one plan are counted, timestamped, reconciled between replicas and retired.", "source_refs": [ "SRC-002", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-sequence-increment-rule", "text": "Which changes require the revision counter to increment, and which do not?", "kind": "constraint", "answer_data": [ "Material field list", "Counter increment rule", "Exempt field list" ] }, { "id": "q-replica-conflict", "text": "When two replicas hold the same plan identifier, which revision wins and by what tiebreak?", "kind": "interoperability", "answer_data": [ "Precedence order: identifier, counter, modification timestamp", "Escalation rule for exact ties" ] }, { "id": "q-supersession-state", "text": "How is a superseded revision marked, and does it remain retrievable?", "kind": "lifecycle", "answer_data": [ "Revision state code", "Supersedes and superseded-by references", "Retrievability policy" ] }, { "id": "q-modification-vs-receipt", "text": "Which timestamp records the modification event as opposed to receipt of that modification?", "kind": "temporal", "answer_data": [ "Modification timestamp", "Ingestion timestamp", "Clock source" ] } ], "data_elements": [ { "id": "de-sequence-number", "name": "sequenceNumber", "description": "Monotonic revision counter incremented on material change; default zero.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-001" ] }, { "id": "de-updated-at", "name": "updatedAt", "description": "Time the revision was made, RFC 3339 with seconds and explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-004" ] }, { "id": "de-ingested-at", "name": "ingestedAt", "description": "Time this system received or observed the revision, recorded when it differs from modification time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-supersedes-ref", "name": "supersedesRef", "description": "Reference to the revision this one replaces.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-revision-state", "name": "revisionState", "description": "Whether the revision is current, superseded or withdrawn.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-plan-revision-history", "name": "Plan revision history", "description": "Append-only ordered record of plan revisions with counters, timestamps and supersession links.", "media_or_form": [ "append-only log", "version-controlled document series", "event stream" ], "serial": true, "identity_strategy": "Plan identifier plus zero-padded monotonic revision counter assigned by the owning system; counters are never reused and the timestamp is an attribute, not part of the identifier.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-ownership-authority-and-approval", "name": "Ownership, write authority and approval", "description": "Who is accountable for the plan, who holds write authority over the master copy, and what evidences approval.", "source_refs": [ "SRC-002", "SRC-007", "SRC-012", "SRC-009" ], "questions": [ { "id": "q-plan-owner", "text": "Which agent is accountable for this plan and its schedule entries?", "kind": "ownership", "answer_data": [ "Owner agent reference", "Accountability statement", "Effective from timestamp" ] }, { "id": "q-master-write-authority", "text": "Which single role holds write authority over the master copy, and how is that authority transferred?", "kind": "authority", "answer_data": [ "Organizer or scheduler reference", "Transfer procedure", "Transfer record" ] }, { "id": "q-approval-evidence", "text": "What evidence records that the plan was approved, by whom and against which revision?", "kind": "evidence", "answer_data": [ "Approver reference", "Approval timestamp", "Approved revision counter", "Approval artifact reference" ] }, { "id": "q-authority-delegation", "text": "Under what conditions may write or approval authority be delegated, and is the delegation recorded on the plan?", "kind": "access", "answer_data": [ "Delegation grant", "Scope and expiry", "Delegator and delegate references" ] } ], "data_elements": [ { "id": "de-owner-agent-ref", "name": "ownerAgentRef", "description": "Accountable owner of the plan.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-organizer-ref", "name": "organizerRef", "description": "Role holding write authority over the master object, per the iTIP Organizer model.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-approval-record", "name": "approvalRecord", "description": "Approver, timestamp, approved revision and basis of approval.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-delegation-grant", "name": "delegationGrant", "description": "Scoped, time-bounded delegation of write or approval authority.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-002" ] } ], "artifacts": [ { "id": "art-plan-approval-record", "name": "Plan approval record", "description": "Signed or attributed record binding an approver to a specific plan revision, used as evidence for authority claims.", "media_or_form": [ "signed approval record", "workflow decision entry", "countersigned document" ], "serial": false, "identity_strategy": "Plan identifier plus approved revision counter plus approver identifier; the approval timestamp is an attribute of the record.", "source_refs": [ "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-intention-content", "name": "Intention Content", "description": "What is intended: goals, planned actions, and the conditions and uncertainties the intention rests on.", "rationale": "PROV treats a plan as the set of steps an agent intended to follow, PDDL2.1 gives durative actions preconditions and temporally annotated effects, and GAO requires that a schedule capture every activity needed to meet the objective. Content must therefore be modelled independently of any date binding.", "source_refs": [ "SRC-007", "SRC-015", "SRC-012" ], "layers": [ { "id": "l-goals-and-planned-actions", "name": "Goals and Planned Actions", "description": "The intended end state and the individual actions meant to bring it about.", "source_refs": [ "SRC-007", "SRC-015", "SRC-012" ], "findings": [ { "id": "f-goal-and-success-criteria", "name": "Goal and success criteria", "description": "The end state the plan serves and the measurable test by which fulfilment is judged.", "source_refs": [ "SRC-007", "SRC-012", "SRC-015" ], "questions": [ { "id": "q-goal-statement", "text": "What end state or objective does the plan intend to bring about?", "kind": "definition", "answer_data": [ "Goal statement", "Scope of effect", "Beneficiary of the outcome" ] }, { "id": "q-success-measure", "text": "By which measurable criterion is the goal judged achieved rather than merely attempted?", "kind": "measurement", "answer_data": [ "Criterion expression", "Measurement unit and threshold", "Evaluation point" ] }, { "id": "q-goal-decomposition", "text": "How does the goal decompose into sub-goals and planned actions?", "kind": "composition", "answer_data": [ "Parent goal reference", "Child goal references", "Decomposition rule" ] }, { "id": "q-goal-tradeoff", "text": "What happens when two goals in the same plan cannot both be satisfied?", "kind": "exception", "answer_data": [ "Precedence rank", "Tradeoff rule", "Escalation owner" ] } ], "data_elements": [ { "id": "de-goal-statement", "name": "goalStatement", "description": "Declarative statement of the intended end state.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-success-criterion", "name": "successCriterion", "description": "Measurable condition establishing achievement, with unit, threshold and evaluation point.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-goal-parent-ref", "name": "goalParentRef", "description": "Parent goal in a decomposition hierarchy.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-goal-precedence-rank", "name": "goalPrecedenceRank", "description": "Rank used to resolve conflicts between goals.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-goal-specification", "name": "Goal specification", "description": "Statement of objectives, decomposition and success criteria against which the plan's fulfilment is assessed.", "media_or_form": [ "structured goal object", "objectives document", "planner goal formula" ], "serial": false, "identity_strategy": "Plan identifier plus goal identifier assigned by the owner package; goal identifiers are stable across plan revisions so criteria can be compared over time.", "source_refs": [ "SRC-007", "SRC-015" ] } ], "inline_only_rationale": null }, { "id": "f-planned-action-specification", "name": "Planned action specification", "description": "One intended action: its type and object, the conditions required to start it, the effects expected, and whether it is instantaneous or durative.", "source_refs": [ "SRC-015", "SRC-007", "SRC-001", "SRC-003" ], "questions": [ { "id": "q-action-type-and-object", "text": "Which action type and target object does the planned action denote?", "kind": "definition", "answer_data": [ "Action type code", "Target object reference", "Parameter bindings" ] }, { "id": "q-action-preconditions", "text": "Which conditions must hold for the planned action to be executable?", "kind": "requirement", "answer_data": [ "Precondition expression", "Condition timing: at start or over all", "Checking responsibility" ] }, { "id": "q-action-effects", "text": "Which state changes does the planned action expect to produce?", "kind": "state", "answer_data": [ "Expected effect expression", "Effect timing: at start or at end", "Affected entity references" ] }, { "id": "q-action-durativity", "text": "Is the action instantaneous or durative, and are its conditions checked at start, throughout, or at end?", "kind": "temporal", "answer_data": [ "Durativity flag", "Condition annotation per clause", "Duration constraint" ] }, { "id": "q-action-prerealization-states", "text": "Which lifecycle states may a planned action occupy before it is realized?", "kind": "lifecycle", "answer_data": [ "State code list", "Allowed transitions", "Terminal pre-realization states" ] } ], "data_elements": [ { "id": "de-action-type", "name": "actionType", "description": "Classifier for the intended action.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "de-action-object-ref", "name": "actionObjectRef", "description": "Entity the action is intended to affect.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-action-precondition", "name": "actionPrecondition", "description": "Condition expression with its timing annotation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-action-expected-effect", "name": "actionExpectedEffect", "description": "Expected state change with its timing annotation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-action-status", "name": "actionStatus", "description": "Pre-realization lifecycle state, aligned to task status vocabularies such as needs-action, in-process, completed and cancelled.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-estimated-effort", "name": "estimatedEffort", "description": "Expected resource effort, distinct from elapsed duration.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] } ], "artifacts": [ { "id": "art-planned-action-definition", "name": "Planned action definition", "description": "Definition of one intended action with parameters, preconditions, expected effects and durativity.", "media_or_form": [ "structured action object", "PDDL durative-action declaration", "iCalendar VTODO component", "JSCalendar Task object" ], "serial": false, "identity_strategy": "Plan identifier plus planned-action identifier issued by the master system; a specific occurrence of a recurring action is identified by that identifier plus its recurrence identifier, never by its date.", "source_refs": [ "SRC-015", "SRC-003" ] } ], "inline_only_rationale": null } ] }, { "id": "l-assumptions-and-uncertainty", "name": "Assumptions and Uncertainty", "description": "Conditions the plan relies on but does not control, and the modelled uncertainty in its durations and logic.", "source_refs": [ "SRC-012", "SRC-015" ], "findings": [ { "id": "f-assumption-and-precondition-register", "name": "Assumption register", "description": "External conditions the plan takes for granted, who watches them, and what their failure invalidates.", "source_refs": [ "SRC-012", "SRC-015", "SRC-007" ], "questions": [ { "id": "q-assumption-statement", "text": "Which external condition does the plan take for granted without controlling it?", "kind": "definition", "answer_data": [ "Assumption statement", "Controlling party if any", "Basis for believing it" ] }, { "id": "q-assumption-monitor", "text": "Who is accountable for monitoring each assumption, and on what cadence?", "kind": "ownership", "answer_data": [ "Monitoring agent reference", "Review cadence", "Last reviewed timestamp" ] }, { "id": "q-assumption-invalidation", "text": "Which observable signal invalidates the assumption, and what re-planning does it trigger?", "kind": "event", "answer_data": [ "Signal definition", "Threshold", "Triggered response" ] }, { "id": "q-assumption-sensitivity", "text": "How much of the plan fails if this assumption fails?", "kind": "measurement", "answer_data": [ "Sensitivity rating", "Dependent item references", "Estimated impact" ] } ], "data_elements": [ { "id": "de-assumption-statement", "name": "assumptionStatement", "description": "The condition relied upon.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-assumption-signal", "name": "assumptionMonitoringSignal", "description": "Observable signal indicating the assumption is failing.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-assumption-sensitivity", "name": "assumptionSensitivity", "description": "Rated impact of the assumption failing.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-assumption-dependent-ref", "name": "assumptionDependentRef", "description": "Plan items that fail if the assumption fails.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-assumption-state", "name": "assumptionState", "description": "Whether the assumption is holding, at risk or invalidated.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-assumption-register", "name": "Assumption register", "description": "Maintained list of assumptions with owners, monitoring signals, sensitivity and current state.", "media_or_form": [ "register table", "structured collection", "review minute extract" ], "serial": false, "identity_strategy": "Plan identifier plus assumption identifier issued by the owner package; entries persist across revisions so state changes are traceable.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "f-schedule-risk-and-contingency", "name": "Schedule risk and contingency", "description": "Uncertainty in durations and logic, the analysis run against it, and the reserve held to absorb it.", "source_refs": [ "SRC-012" ], "questions": [ { "id": "q-duration-distribution", "text": "Which duration estimates carry a distribution rather than a single deterministic value?", "kind": "measurement", "answer_data": [ "Optimistic, most likely and pessimistic values", "Distribution type", "Basis of estimate" ] }, { "id": "q-risk-analysis-run", "text": "Has a schedule risk analysis been run, against which plan revision, and at what confidence level is the committed date set?", "kind": "validation", "answer_data": [ "Analysis run reference", "Analysed revision counter", "Confidence percentile", "Resulting date" ] }, { "id": "q-contingency-reserve", "text": "Where is schedule reserve held, and who may authorize consuming it?", "kind": "constraint", "answer_data": [ "Reserve location in the network", "Reserve duration", "Consumption authority" ] }, { "id": "q-risk-drivers", "text": "Which activities drive the greatest schedule risk?", "kind": "relationship", "answer_data": [ "Ranked driver activity references", "Sensitivity measure", "Correlation assumptions" ] } ], "data_elements": [ { "id": "de-duration-estimate-range", "name": "durationEstimateRange", "description": "Three-point or distributional duration estimate.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-confidence-level", "name": "confidenceLevel", "description": "Percentile at which a committed date is asserted.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-reserve-duration", "name": "reserveDuration", "description": "Schedule reserve held against uncertainty.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-risk-driver-ref", "name": "riskDriverRef", "description": "Activities ranked as principal risk drivers.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-schedule-risk-analysis", "name": "Schedule risk analysis report", "description": "Record of a risk analysis run: inputs, distributions, resulting confidence curve, driver ranking and the revision analysed.", "media_or_form": [ "analysis report", "simulation output dataset", "risk register extract" ], "serial": true, "identity_strategy": "Plan identifier plus analysed revision counter plus zero-padded run sequence; the run timestamp is an attribute, not the identifier.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-temporal-binding", "name": "Temporal Binding", "description": "Binding intentions to instants, intervals, deadlines, durations and repeating patterns, with correct time zone semantics.", "rationale": "This is the distinguishing concern of the model. iCalendar and JSCalendar define three mutually irreducible time forms and a rule-plus-override recurrence design; RFC 3339 and RFC 9557 define the timestamp profile and how a zone name travels with an offset; the IANA database shows that future local times are invalidated by data releases.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-005", "SRC-006" ], "layers": [ { "id": "l-time-anchors-zones-and-duration", "name": "Time Anchors, Zones and Duration", "description": "How an entry is anchored on a timeline, in which time form, and what its duration means.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-005", "SRC-006", "SRC-008" ], "findings": [ { "id": "f-schedule-entry-time-binding", "name": "Schedule entry time binding", "description": "The anchoring of a planned action to a point, an interval, a deadline, or a start plus duration.", "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-008", "SRC-011" ], "questions": [ { "id": "q-anchor-form", "text": "Is the entry anchored as an instant, a start plus duration, a start plus end, or a deadline only?", "kind": "temporal", "answer_data": [ "Anchor form code", "Start value", "End or duration or due value" ] }, { "id": "q-timestamp-profile", "text": "In which serialization profile and precision are the entry's absolute times expressed?", "kind": "constraint", "answer_data": [ "Timestamp profile reference", "Seconds precision", "Offset or Z designator", "Leap-second handling" ] }, { "id": "q-date-only-binding", "text": "Is the entry a date-only all-day binding or a time-of-day binding?", "kind": "classification", "answer_data": [ "Date-only flag", "Local day boundary rule" ] }, { "id": "q-entry-place", "text": "Where is the entry expected to take place, and does that place determine its local time?", "kind": "spatial", "answer_data": [ "Location reference or text", "Coordinates if known", "Whether location drives the time zone" ] } ], "data_elements": [ { "id": "de-entry-start", "name": "entryStart", "description": "Start instant, RFC 3339 with seconds and explicit offset or Z when absolute.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "de-entry-end", "name": "entryEnd", "description": "End instant, mutually exclusive with a stated duration.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-entry-duration", "name": "entryDuration", "description": "Length of the entry when an end is not stated.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-entry-due", "name": "entryDue", "description": "Deadline for a task-style entry with no fixed start.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-date-only-flag", "name": "dateOnlyFlag", "description": "Marks an all-day binding with no time of day.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-entry-location-ref", "name": "entryLocationRef", "description": "Place at which the entry is expected to occur.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-schedule-entry", "name": "Schedule entry", "description": "The time binding of a planned action, carrying anchor form, times, place and its relation to the intention it times.", "media_or_form": [ "structured entry object", "iCalendar VEVENT or VTODO component", "JSCalendar Event or Task object", "calendar row in a tabular export" ], "serial": false, "identity_strategy": "Entry identifier from the master calendar system; otherwise a globally unique identifier stable across revisions. A start date or time is never the identifier.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-time-zone-and-floating-time", "name": "Time zone and floating-time integrity", "description": "Which of the three time forms an entry uses, and how future local times survive time zone rule changes.", "source_refs": [ "SRC-001", "SRC-003", "SRC-005", "SRC-006", "SRC-004" ], "questions": [ { "id": "q-time-form", "text": "Is the entry stored as UTC, as local time with a named zone, or as floating local time?", "kind": "classification", "answer_data": [ "Time form code", "Zone identifier when applicable", "Justification for floating form" ] }, { "id": "q-tzdb-release", "text": "Which time zone database release was in force when the entry was created, and is that release recorded?", "kind": "provenance", "answer_data": [ "Database release identifier", "Recording policy", "Recomputation trigger" ] }, { "id": "q-zone-rule-change", "text": "What happens to a future entry when its zone's offset or daylight-saving rule changes?", "kind": "exception", "answer_data": [ "Recomputation rule", "Notification obligation", "Affected entry list" ] }, { "id": "q-offset-zone-disagreement", "text": "If a stored offset disagrees with the named zone, which one governs?", "kind": "validation", "answer_data": [ "Precedence rule", "Criticality marking of the zone tag", "Error handling behaviour" ] } ], "data_elements": [ { "id": "de-time-form", "name": "timeForm", "description": "One of UTC, zoned local time, or floating local time.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-time-zone-id", "name": "timeZoneIdentifier", "description": "IANA time zone identifier applicable to a zoned local time.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-005" ] }, { "id": "de-tzdb-release", "name": "timeZoneDatabaseRelease", "description": "Release of the time zone database in force when times were computed.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] }, { "id": "de-utc-offset", "name": "utcOffset", "description": "Explicit numeric offset accompanying an absolute timestamp.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-005" ] } ], "artifacts": [ { "id": "art-time-zone-policy", "name": "Time zone binding policy", "description": "The owner package's declared rules on which time form to use per entry class, whether zone tags are critical, and how zone data releases trigger recomputation.", "media_or_form": [ "policy document", "machine-readable configuration", "conformance profile" ], "serial": false, "identity_strategy": "Owner package namespace IRI plus policy identifier and version label; the effective-from timestamp is an attribute of the policy version.", "source_refs": [ "SRC-005", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "f-duration-effort-and-working-calendar", "name": "Duration, effort and working calendar", "description": "Whether a stated duration means elapsed time, working time or resource effort, and which calendar converts between them.", "source_refs": [ "SRC-012", "SRC-003", "SRC-011", "SRC-008" ], "questions": [ { "id": "q-duration-kind", "text": "Does the stated duration mean elapsed time, working time, or resource effort?", "kind": "definition", "answer_data": [ "Duration kind code", "Conversion rule", "Declared default" ] }, { "id": "q-working-calendar", "text": "Which working calendar, including non-working days and shift hours, applies to this entry?", "kind": "composition", "answer_data": [ "Calendar reference", "Working day pattern", "Holiday set and locale" ] }, { "id": "q-duration-units", "text": "In which units are durations expressed, and how are partial units rounded?", "kind": "measurement", "answer_data": [ "Unit code", "Rounding rule", "Minimum granularity" ] }, { "id": "q-calendar-precedence", "text": "Which calendar governs when the resource calendar and the activity calendar disagree?", "kind": "exception", "answer_data": [ "Precedence rule", "Override record", "Responsible role" ] } ], "data_elements": [ { "id": "de-duration-kind", "name": "durationKind", "description": "Elapsed, working or effort interpretation of a duration value.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-working-calendar-ref", "name": "workingCalendarRef", "description": "Calendar defining working days, shift hours and non-working periods.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-effort-quantity", "name": "effortQuantity", "description": "Resource effort with unit, distinct from elapsed duration.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-duration-unit", "name": "durationUnit", "description": "Unit in which durations are stated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [ { "id": "art-working-calendar", "name": "Working calendar definition", "description": "Named calendar of working days, shift hours, holidays and exceptions used to convert between elapsed, working and effort durations.", "media_or_form": [ "calendar definition object", "holiday and shift table", "project tool calendar export" ], "serial": false, "identity_strategy": "Owner package namespace plus calendar identifier and version label; locale and holiday jurisdiction are recorded as attributes.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "l-recurrence-and-exceptions", "name": "Recurrence and Exceptions", "description": "Generative patterns for repeating intentions and the individual occurrences that deviate from them.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-014" ], "findings": [ { "id": "f-recurrence-rule-specification", "name": "Recurrence rule specification", "description": "The pattern that generates repeated occurrences, its grammar, anchor and termination.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-014" ], "questions": [ { "id": "q-recurrence-grammar", "text": "In which recurrence grammar is the pattern expressed, and is it losslessly convertible to the others in use?", "kind": "interoperability", "answer_data": [ "Grammar identifier", "Convertibility matrix", "Known lossy constructs" ] }, { "id": "q-recurrence-terms", "text": "Which frequency, interval, by-part and termination terms define the pattern?", "kind": "constraint", "answer_data": [ "Frequency code", "Interval value", "By-part values", "Until or count" ] }, { "id": "q-expansion-anchor", "text": "Which start value anchors expansion, and in which zone is expansion performed?", "kind": "temporal", "answer_data": [ "Anchor start value", "Expansion zone", "Week start setting" ] }, { "id": "q-expansion-horizon", "text": "Is the series bounded by count, by an end date, or unbounded, and how far should a consumer expand it?", "kind": "process", "answer_data": [ "Boundedness code", "Horizon policy", "Maximum occurrences returned" ] } ], "data_elements": [ { "id": "de-recurrence-grammar", "name": "recurrenceGrammar", "description": "Identifier of the grammar in which the pattern is expressed.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-011", "SRC-014" ] }, { "id": "de-recurrence-frequency", "name": "recurrenceFrequency", "description": "Base repetition frequency.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "de-recurrence-interval", "name": "recurrenceInterval", "description": "Number of frequency units between occurrences.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-recurrence-by-part", "name": "recurrenceByPart", "description": "Refinement parts such as by-day, by-month, by-month-day or by-set-position.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-014" ] }, { "id": "de-recurrence-until", "name": "recurrenceUntil", "description": "Terminating instant of the series.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-recurrence-count", "name": "recurrenceCount", "description": "Terminating occurrence count of the series.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-011" ] } ], "artifacts": [ { "id": "art-recurrence-rule", "name": "Recurrence rule", "description": "The stored generative pattern; the rule plus its overrides, not the expanded occurrence list, is the canonical form.", "media_or_form": [ "recurrence rule string", "structured recurrence object", "repeat structure in a domain data type" ], "serial": false, "identity_strategy": "Series identifier of the owning entry plus rule position; the rule has no independent business identifier and is never identified by a generated date.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-occurrence-override-and-exception", "name": "Occurrence override and exception", "description": "Individual occurrences that differ from the series or are removed from it, and how they survive rule changes.", "source_refs": [ "SRC-001", "SRC-003", "SRC-002" ], "questions": [ { "id": "q-occurrence-identity", "text": "How is a single occurrence identified independently of the series it belongs to?", "kind": "identity", "answer_data": [ "Series identifier", "Recurrence identifier value", "Identifier stability rule" ] }, { "id": "q-override-range", "text": "Does a change apply to one occurrence only or to that occurrence and all later ones?", "kind": "composition", "answer_data": [ "Range flag", "Affected occurrence set", "Resulting split series" ] }, { "id": "q-occurrence-exclusion", "text": "How are cancelled or excluded occurrences recorded so that expansion does not regenerate them?", "kind": "exception", "answer_data": [ "Exclusion date list", "Cancellation status per occurrence", "Tombstone retention period" ] }, { "id": "q-detached-occurrence-drift", "text": "When the series rule changes, what becomes of previously detached overrides?", "kind": "validation", "answer_data": [ "Reconciliation rule", "Orphaned override handling", "Operator notification" ] } ], "data_elements": [ { "id": "de-recurrence-id", "name": "recurrenceIdentifier", "description": "Value identifying one occurrence within a series.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-override-range", "name": "overrideRange", "description": "Whether the override applies to a single occurrence or to it and all future occurrences.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-excluded-date", "name": "excludedDate", "description": "Occurrence removed from the generated series.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-added-date", "name": "addedDate", "description": "Occurrence added outside the rule.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-override-patch", "name": "overridePatch", "description": "Field-scoped differences applied to a specific occurrence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "art-occurrence-override-set", "name": "Occurrence override set", "description": "The collection of per-occurrence patches, additions and exclusions that qualify a recurrence rule.", "media_or_form": [ "override map keyed by recurrence identifier", "detached component set", "exception date list" ], "serial": false, "identity_strategy": "Series identifier plus recurrence identifier for each member; membership keys are never the display date of an occurrence.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-network-feasibility-and-integrity", "name": "Network, Feasibility and Integrity", "description": "Ordering between intended items, imposed date constraints, the dates derived from them, resource feasibility and whether the result is fit to rely on.", "rationale": "GAO's ten best practices require that all activities be captured and logically sequenced, that resources and durations be assigned, that the schedule be traceable horizontally and vertically, that the critical path be valid and total float reasonable. These are structural obligations, distinct from the content of any single intention.", "source_refs": [ "SRC-012", "SRC-008", "SRC-015" ], "layers": [ { "id": "l-dependency-and-constraint-network", "name": "Dependency and Constraint Network", "description": "Logical ordering between planned items, externally imposed date constraints, and the checks that decide whether the network is sound.", "source_refs": [ "SRC-012", "SRC-008", "SRC-001" ], "findings": [ { "id": "f-ordering-dependency-and-lag", "name": "Ordering dependency and lag", "description": "The directed relations that sequence planned items, their type, lag and justification.", "source_refs": [ "SRC-012", "SRC-008", "SRC-001" ], "questions": [ { "id": "q-dependency-type", "text": "Which ordering relation holds between predecessor and successor: finish-to-start, start-to-start, finish-to-finish or start-to-finish?", "kind": "relationship", "answer_data": [ "Dependency type code", "Predecessor reference", "Successor reference" ] }, { "id": "q-dependency-lag", "text": "What lag or lead applies, in which duration kind, and what justifies it?", "kind": "measurement", "answer_data": [ "Lag value and sign", "Duration kind", "Calendar used to apply the lag" ] }, { "id": "q-dependency-rationale", "text": "What physical or contractual reason justifies the dependency rather than mere convenience?", "kind": "evidence", "answer_data": [ "Rationale statement", "Evidence reference", "Reviewer and review date" ] }, { "id": "q-external-dependency", "text": "Which dependencies cross the plan boundary to another party's plan?", "kind": "interoperability", "answer_data": [ "External plan reference", "Counterparty agent", "Agreed handover point", "Notification obligation" ] } ], "data_elements": [ { "id": "de-predecessor-ref", "name": "predecessorRef", "description": "Preceding planned item in an ordering relation.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-successor-ref", "name": "successorRef", "description": "Following planned item in an ordering relation.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-dependency-type", "name": "dependencyType", "description": "Ordering relation type between the two items.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-008" ] }, { "id": "de-lag-duration", "name": "lagDuration", "description": "Signed lag or lead applied to the relation.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-dependency-scope", "name": "dependencyScope", "description": "Whether the dependency is internal to the plan or crosses to an external party.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-dependency-network", "name": "Dependency network", "description": "The directed acyclic set of ordering relations with types, lags and rationale, from which schedule dates are computed.", "media_or_form": [ "edge list or graph structure", "project schedule logic export", "network diagram" ], "serial": false, "identity_strategy": "Plan identifier plus revision counter for the network as a whole; each edge is identified by predecessor identifier, successor identifier and dependency type.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "f-date-constraint-and-flexibility", "name": "Date constraint and scheduling flexibility", "description": "Externally imposed date constraints on an entry and how far the entry may move without breaching them.", "source_refs": [ "SRC-012", "SRC-001", "SRC-003" ], "questions": [ { "id": "q-constraint-type", "text": "Which date constraint is imposed on this entry, and who imposed it?", "kind": "constraint", "answer_data": [ "Constraint type code", "Constraint date value", "Imposing party reference" ] }, { "id": "q-entry-flexibility", "text": "How flexible is the entry: fixed, movable within a window, or freely schedulable?", "kind": "classification", "answer_data": [ "Flexibility class", "Permitted movement window", "Approval needed to move" ] }, { "id": "q-constraint-versus-logic", "text": "When a hard constraint conflicts with network logic, which is honoured and how is the conflict surfaced?", "kind": "exception", "answer_data": [ "Precedence rule", "Conflict marker", "Notification target" ] }, { "id": "q-deadline-authority", "text": "Is the deadline self-imposed, contractual or regulatory?", "kind": "authority", "answer_data": [ "Deadline basis code", "Governing instrument reference", "Consequence of breach" ] } ], "data_elements": [ { "id": "de-constraint-type", "name": "dateConstraintType", "description": "Type of imposed date constraint, such as start-no-earlier-than or finish-no-later-than.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-constraint-date", "name": "dateConstraintValue", "description": "The constraining date or instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "de-flexibility-class", "name": "flexibilityClass", "description": "How far the entry may move without approval.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-constraint-authority", "name": "dateConstraintBasis", "description": "Whether the constraint is self-imposed, contractual or regulatory.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [], "inline_only_rationale": "Date constraints and flexibility are attributes of the schedule entry itself, not a separable deliverable. Both iCalendar and JSCalendar express them as properties of the calendar component, and materializing a separate constraint artifact would create a second place where the same date is asserted, which is precisely the duplication that GAO's traceability practice warns against. They are therefore inline data validated together with the entry, and the governing instrument behind a contractual or regulatory deadline is referenced rather than copied." }, { "id": "f-schedule-integrity-and-quality", "name": "Schedule integrity and quality assessment", "description": "Structural checks that decide whether a schedule is complete, well-constructed and credible enough to be relied on.", "source_refs": [ "SRC-012" ], "questions": [ { "id": "q-activity-completeness", "text": "Does the schedule capture every activity needed to meet the objective, including work performed by other parties?", "kind": "quality", "answer_data": [ "Coverage assessment", "Omitted scope list", "Breakdown structure reference" ] }, { "id": "q-logic-defects", "text": "Which activities have missing predecessors or successors, negative lag, or excessive use of hard constraints?", "kind": "validation", "answer_data": [ "Open-end count", "Negative lag count", "Constrained activity count", "Defect list with references" ] }, { "id": "q-traceability", "text": "Can the schedule be traced horizontally across dependent activities and vertically to its summary levels?", "kind": "evidence", "answer_data": [ "Horizontal traceability result", "Vertical traceability result", "Sampled evidence references" ] }, { "id": "q-float-reasonableness", "text": "Which health metrics are computed, at what thresholds, and against which scheduling run?", "kind": "measurement", "answer_data": [ "Metric names and values", "Threshold set", "Scheduling run reference", "Pass or fail per metric" ] } ], "data_elements": [ { "id": "de-integrity-check-result", "name": "integrityCheckResult", "description": "Named check with its threshold, computed value and outcome.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-open-end-count", "name": "openEndCount", "description": "Number of activities lacking a predecessor or successor.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-traceability-status", "name": "traceabilityStatus", "description": "Result of horizontal and vertical traceability verification.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-assessment-observed-at", "name": "assessmentObservedAt", "description": "Time the assessment was performed, distinct from the plan revision's modification time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-012" ] } ], "artifacts": [ { "id": "art-schedule-health-assessment", "name": "Schedule health assessment", "description": "Evidence record of integrity and quality checks against a named plan revision, usable as a gate on baseline approval.", "media_or_form": [ "assessment report", "metric result set", "audit finding record" ], "serial": true, "identity_strategy": "Plan identifier plus assessed revision counter plus zero-padded assessment sequence; the assessment timestamp is an attribute of the record.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "f-plan-hierarchy-and-relationship-integrity", "name": "Precedence network and hierarchical composition", "description": "RFC 9253 extends RELATED-TO with temporal RELTYPE values FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH and STARTTOSTART, plus GAP for lag (positive) or lead (negative) duration, and FIRST, NEXT, DEPENDS-ON, PARENT, CHILD and SIBLING. P-Plan isPreceededBy is a transitive step ordering without lag types. OWL-Time intervalBefore, intervalMeets, intervalOverlaps and related Allen relations describe interval topology but are not project-management lag. FHIR CarePlan.partOf, basedOn and replaces relate plan instances. REFID groups components without adding meaning. These relation families must be stored distinctly; isPreceededBy is not equivalent to FINISHTOSTART with lag.", "source_refs": [ "SRC-017", "SRC-020", "SRC-021", "SRC-022" ], "inline_only_rationale": null, "data_elements": [ { "id": "f-plan-hierarchy-and-relationship-integrity-data01", "name": "predecessor_id", "description": "Planned item that constrains another.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-data02", "name": "successor_id", "description": "Planned item being constrained.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-021" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-data03", "name": "reltype", "description": "finishtostart, finishtofinish, starttofinish, starttostart, depends-on, parent, child, sibling, first, next, part-of, based-on, replaces.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017", "SRC-022" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-data04", "name": "gap", "description": "Lead (negative) or lag (positive) between predecessor and successor.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-data05", "name": "group_refid", "description": "Shared grouping key with no additional semantics.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-017" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-data06", "name": "link_uri", "description": "RFC 9253 LINK to an external related resource.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017" ] } ], "artifacts": [ { "id": "f-plan-hierarchy-and-relationship-integrity-artifact01", "name": "Dependency record", "description": "Typed relationship between planned items, including precedence type, gap and optional grouping key.", "media_or_form": [ "iCalendar RELATED-TO with RELTYPE and GAP", "RFC 9253 LINK and REFID properties", "P-Plan isPreceededBy assertion" ], "serial": false, "identity_strategy": "Identified by predecessor identifier, successor identifier and relation type; relation families are stored distinctly rather than collapsed together.", "source_refs": [ "SRC-017", "SRC-020", "SRC-021", "SRC-022" ] } ], "questions": [ { "id": "f-plan-hierarchy-and-relationship-integrity-q01", "text": "What ordering constraint holds between these planned items, including precedence type and lead or lag gap?", "kind": "relationship", "answer_data": [ "predecessor_id (string)", "successor_id (string)", "reltype (enum)", "gap (signed-duration)" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-q02", "text": "Is this plan or item part of, based on, replacing, parent of or child of another plan, and what grouping REFID if any associates peers?", "kind": "composition", "answer_data": [ "part_of_plan_id (string)", "based_on_plan_id (string)", "replaces_plan_id (string)", "reltype (enum)", "group_refid (string)" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-q03", "text": "Independently of project lag, which Allen interval relation holds between the scheduled intervals of the two items?", "kind": "temporal", "answer_data": [ "allen_relation (enum)", "interval_meets (boolean)" ] }, { "id": "f-plan-hierarchy-and-relationship-integrity-q04", "text": "Does this relationship currently dangle because the target was deleted or cancelled, as RFC 9253 warns for FIRST, NEXT and temporal links?", "kind": "evidence", "answer_data": [ "target_missing (boolean)", "target_status (enum)" ] } ] } ] }, { "id": "l-computation-and-resources", "name": "Computation and Resources", "description": "Dates derived from logic, durations and constraints, and the resources whose availability makes them feasible.", "source_refs": [ "SRC-012", "SRC-015", "SRC-003" ], "findings": [ { "id": "f-critical-path-and-float", "name": "Critical path and float computation", "description": "Separates asserted inputs from computed outputs and records the run that produced the dates, float and critical path.", "source_refs": [ "SRC-012", "SRC-015", "SRC-007" ], "questions": [ { "id": "q-asserted-versus-derived", "text": "Which dates are asserted inputs and which are computed outputs of a scheduling run?", "kind": "provenance", "answer_data": [ "Per-field derivation flag", "Computation run reference", "Input revision counter" ] }, { "id": "q-critical-path-validity", "text": "Which continuous path of activities determines the finish date, and how was its validity checked?", "kind": "validation", "answer_data": [ "Ordered path activity references", "Validation method", "Anomalies found" ] }, { "id": "q-float-values", "text": "What total float and free float does each activity carry, and what threshold counts as unreasonable?", "kind": "measurement", "answer_data": [ "Total float value", "Free float value", "Threshold and unit", "Outlier activity references" ] }, { "id": "q-recomputation-trigger", "text": "What triggers recomputation, and is the previous computed result retained?", "kind": "process", "answer_data": [ "Trigger condition list", "Retention policy for prior runs", "Run cadence" ] } ], "data_elements": [ { "id": "de-computed-early-start", "name": "computedEarlyStart", "description": "Earliest start derived by forward pass, flagged as derived.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-computed-late-finish", "name": "computedLateFinish", "description": "Latest finish derived by backward pass, flagged as derived.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-total-float", "name": "totalFloat", "description": "Permissible delay before the project finish is affected.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-critical-flag", "name": "criticalFlag", "description": "Whether the activity lies on the driving path.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-computation-run-ref", "name": "computationRunRef", "description": "Reference to the scheduling run that produced the derived values.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] } ], "artifacts": [ { "id": "art-scheduling-run-result", "name": "Scheduling run result", "description": "Immutable output of one scheduling computation: derived dates, float, critical path and the exact inputs and settings used.", "media_or_form": [ "computation result set", "schedule calculation log", "tool run export" ], "serial": true, "identity_strategy": "Plan identifier plus input revision counter plus zero-padded run sequence issued by the computing system; the run timestamp and engine version are attributes.", "source_refs": [ "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "f-resource-assignment-and-contention", "name": "Resource assignment and contention", "description": "Which agents and resources are assigned at what allocation, their availability, and where they are over-committed.", "source_refs": [ "SRC-012", "SRC-003", "SRC-001" ], "questions": [ { "id": "q-resource-assignment", "text": "Which agent or resource is assigned to the planned action, in which role and at what allocation?", "kind": "relationship", "answer_data": [ "Assignee reference", "Assignment role", "Allocation units", "Effective period" ] }, { "id": "q-resource-availability", "text": "What availability calendar limits the assigned resource?", "kind": "state", "answer_data": [ "Availability window set", "Calendar reference", "Exception periods" ] }, { "id": "q-over-allocation", "text": "Where is the same resource committed to overlapping entries, and how is that resolved?", "kind": "exception", "answer_data": [ "Overlap detection result", "Resolution action", "Deciding role" ] }, { "id": "q-unresourced-activities", "text": "Which activities carry a duration but no assigned resource, and is that deliberate?", "kind": "quality", "answer_data": [ "Unresourced activity references", "Justification", "Remediation owner" ] } ], "data_elements": [ { "id": "de-assignee-ref", "name": "assigneeRef", "description": "Agent or resource assigned to the planned action.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-assignment-role", "name": "assignmentRole", "description": "Role in which the resource is assigned.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-allocation-units", "name": "allocationUnits", "description": "Proportion of the resource's capacity committed.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-availability-window", "name": "availabilityWindow", "description": "Interval in which the resource is available.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "art-resource-assignment-set", "name": "Resource assignment set", "description": "The assignments and allocations for a plan revision, with detected contention, used to test feasibility.", "media_or_form": [ "assignment table", "resource histogram export", "structured assignment collection" ], "serial": false, "identity_strategy": "Plan identifier plus revision counter; each assignment is identified by planned-action identifier plus assignee identifier plus role.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "b-commitment-and-coordination", "name": "Commitment and Coordination", "description": "Intentions that bind an agent to another party, and the negotiation by which times and participation are agreed.", "rationale": "ODRL supplies a normative model of duties within an agreement between assigner and assignee, with consequences and remedies; iTIP supplies normative participation states, counter-proposals and organizer authority. Together they show that binding and negotiation are distinct from mere intention.", "source_refs": [ "SRC-009", "SRC-002", "SRC-001" ], "layers": [ { "id": "l-commitment-and-obligation", "name": "Commitment and Obligation", "description": "What is promised to whom, on what basis, and what follows if it is not delivered.", "source_refs": [ "SRC-009", "SRC-010", "SRC-002" ], "findings": [ { "id": "f-commitment-parties-and-terms", "name": "Commitment parties and terms", "description": "The subset of intentions that bind an agent toward a named beneficiary, with terms and qualifying conditions.", "source_refs": [ "SRC-009", "SRC-010", "SRC-002" ], "questions": [ { "id": "q-commitment-parties", "text": "Which party issues the commitment and which party is its beneficiary?", "kind": "ownership", "answer_data": [ "Assigner reference", "Assignee or beneficiary reference", "Third-party arbiter if any" ] }, { "id": "q-commitment-terms", "text": "What exactly is promised, by when, and under which qualifying conditions?", "kind": "requirement", "answer_data": [ "Promised action", "Deadline or interval", "Constraint expressions", "Referenced planned action" ] }, { "id": "q-commitment-basis", "text": "Is the commitment informal, contractual or regulatory, and what evidence establishes it?", "kind": "classification", "answer_data": [ "Basis code", "Governing instrument reference", "Establishing evidence" ] }, { "id": "q-commitment-verification", "text": "Who is entitled to verify the commitment's existence and terms?", "kind": "access", "answer_data": [ "Verifier references", "Disclosure scope", "Verification interface" ] } ], "data_elements": [ { "id": "de-commitment-assigner", "name": "commitmentAssignerRef", "description": "Party that issues the commitment.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-commitment-assignee", "name": "commitmentAssigneeRef", "description": "Beneficiary of the commitment.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-promised-action", "name": "promisedAction", "description": "The action promised, with its constraints and referenced planned action.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] }, { "id": "de-commitment-basis", "name": "commitmentBasis", "description": "Whether the commitment is informal, contractual or regulatory.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "de-commitment-state", "name": "commitmentState", "description": "Current state of the commitment, such as offered, active, fulfilled, breached or released.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "art-commitment-record", "name": "Commitment record", "description": "Record binding an intention to a beneficiary, carrying parties, terms, conditions and current state.", "media_or_form": [ "structured commitment object", "policy expression in an agreement vocabulary", "countersigned undertaking" ], "serial": false, "identity_strategy": "Master-system commitment identifier where one exists; otherwise a governed identifier in the owner package namespace, referencing the plan identifier and the planned action it binds.", "source_refs": [ "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "f-remedy-consequence-and-release", "name": "Remedy, consequence and release", "description": "What follows non-fulfilment of a commitment, and how commitments are honoured, released or transferred.", "source_refs": [ "SRC-009", "SRC-002", "SRC-012" ], "questions": [ { "id": "q-consequence-duty", "text": "Which additional duty is triggered when the commitment is not fulfilled?", "kind": "constraint", "answer_data": [ "Consequence duty definition", "Trigger condition", "Duty bearer reference" ] }, { "id": "q-breach-evaluation", "text": "Which observable event constitutes non-fulfilment, and at what moment is it evaluated?", "kind": "event", "answer_data": [ "Breach criterion", "Evaluation instant", "Observing party" ] }, { "id": "q-commitment-release", "text": "How is a commitment released, renegotiated or transferred, and whose consent is required?", "kind": "lifecycle", "answer_data": [ "Release procedure", "Consenting parties", "Resulting state and successor commitment" ] }, { "id": "q-fulfilment-evidence", "text": "What evidence closes the commitment as honoured?", "kind": "evidence", "answer_data": [ "Evidence references", "Accepting party", "Acceptance timestamp" ] } ], "data_elements": [ { "id": "de-consequence-duty", "name": "consequenceDuty", "description": "Duty that arises when the primary duty is unfulfilled.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-breach-evaluated-at", "name": "breachEvaluatedAt", "description": "Instant at which non-fulfilment is assessed.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "de-release-reason", "name": "releaseReason", "description": "Controlled reason for release, renegotiation or transfer.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-fulfilment-evidence-ref", "name": "fulfilmentEvidenceRef", "description": "Evidence supporting closure as honoured.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "art-commitment-settlement", "name": "Commitment settlement record", "description": "Record of how a commitment ended: honoured with evidence, breached with consequence applied, released or transferred with consent.", "media_or_form": [ "settlement record", "dispute or exception log entry", "transfer instrument" ], "serial": true, "identity_strategy": "Commitment identifier plus zero-padded settlement sequence; the settlement timestamp and deciding party are attributes.", "source_refs": [ "SRC-009" ] } ], "inline_only_rationale": null } ] }, { "id": "l-participation-and-negotiation", "name": "Participation and Negotiation", "description": "Who is invited, what they answered, how clashes are detected and how times are renegotiated.", "source_refs": [ "SRC-002", "SRC-001", "SRC-003" ], "findings": [ { "id": "f-participant-role-and-response", "name": "Participant role and response state", "description": "Roles participants hold on an entry, their current response, and how delegation is represented.", "source_refs": [ "SRC-002", "SRC-001", "SRC-003" ], "questions": [ { "id": "q-participant-role", "text": "In which role does each participant appear on the entry?", "kind": "classification", "answer_data": [ "Role code", "Required or optional flag", "Role source vocabulary" ] }, { "id": "q-participation-status", "text": "What is each participant's current response state, and when was it last updated?", "kind": "state", "answer_data": [ "Participation status code", "Status update timestamp", "Updating agent" ] }, { "id": "q-reply-expected", "text": "Is a reply expected from this participant, and by when?", "kind": "process", "answer_data": [ "Reply expected flag", "Reply deadline", "Reminder policy" ] }, { "id": "q-participant-delegation", "text": "When a participant delegates, how are delegator and delegate linked on the entry?", "kind": "relationship", "answer_data": [ "Delegated-to reference", "Delegated-from reference", "Whether the delegator remains listed" ] } ], "data_elements": [ { "id": "de-participant-ref", "name": "participantRef", "description": "Agent invited to or involved in the entry.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-participation-role", "name": "participationRole", "description": "Role such as chair, required, optional or informational.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-participation-status", "name": "participationStatus", "description": "Response state such as needs-action, accepted, declined, tentative or delegated.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-reply-expected", "name": "replyExpected", "description": "Whether the organizer expects a reply from this participant.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-delegated-to-ref", "name": "delegatedToRef", "description": "Agent to whom participation was delegated.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "art-participant-roster", "name": "Participant roster", "description": "The set of participants on an entry with roles, response states, reply expectations and delegation links.", "media_or_form": [ "participant collection", "attendee property set in a calendar component", "roster table" ], "serial": false, "identity_strategy": "Entry identifier plus participant agent identifier; response state is versioned by the entry's revision counter and the status update timestamp.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-conflict-detection-and-rescheduling", "name": "Conflict detection and rescheduling", "description": "Whether an entry consumes availability, how clashes are found, and how alternative times are proposed and recorded.", "source_refs": [ "SRC-001", "SRC-002", "SRC-003" ], "questions": [ { "id": "q-availability-consumption", "text": "Does this entry consume the participant's availability or leave them free?", "kind": "definition", "answer_data": [ "Transparency or free-busy status code", "Effect on availability computation" ] }, { "id": "q-conflict-detection", "text": "How are overlapping commitments detected across separate calendars and plans?", "kind": "process", "answer_data": [ "Detection scope", "Overlap rule", "Detected conflict set" ] }, { "id": "q-counter-proposal", "text": "How is an alternative time proposed, accepted or declined?", "kind": "decision", "answer_data": [ "Proposed alternative values", "Proposing party", "Decision outcome and decider" ] }, { "id": "q-reschedule-provenance", "text": "When an entry moves, what records the previous time and the reason?", "kind": "provenance", "answer_data": [ "Previous start and end", "Reason code", "Deciding agent", "Decision and application timestamps" ] } ], "data_elements": [ { "id": "de-availability-effect", "name": "availabilityEffect", "description": "Whether the entry marks the participant busy or free.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-conflict-result", "name": "conflictDetectionResult", "description": "Detected overlap with the conflicting entry references.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-proposed-alternative", "name": "proposedAlternative", "description": "Counter-proposed time and its proposing party.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-reschedule-reason", "name": "rescheduleReason", "description": "Controlled reason for moving an entry.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-free-busy-projection", "name": "Free/busy projection", "description": "Availability-only view over a bounded horizon, disclosing busy intervals without entry content, used for conflict detection across parties.", "media_or_form": [ "free/busy component over a stated interval", "availability response payload", "busy-interval table" ], "serial": false, "identity_strategy": "Subject agent identifier plus the requested interval and generation timestamp; the projection is derived and is never a system of record.", "source_refs": [ "SRC-001", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "f-scheduling-method-and-message-sequencing", "name": "Scheduling methods and message sequencing", "description": "iTIP methods are PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER and DECLINECOUNTER. Organizer may send PUBLISH, REQUEST, ADD, CANCEL and DECLINECOUNTER; Attendee may send REPLY, REFRESH, COUNTER and a delegation REQUEST. Correlation keys are UID, RECURRENCE-ID, SEQUENCE and DTSTAMP: higher SEQUENCE obsoletes lower for the same UID and recurrence id; matching SEQUENCE ties break on later DTSTAMP. SEQUENCE MUST increment when Organizer changes DTSTART, DTEND, DURATION, DUE, RRULE, RDATE, EXDATE or STATUS. JSCalendar sequence and method (lowercase iTIP method) carry the same semantics. Out-of-order replies must be discarded using persisted last SEQUENCE and DTSTAMP per attendee.", "source_refs": [ "SRC-002", "SRC-003" ], "inline_only_rationale": null, "data_elements": [ { "id": "f-scheduling-method-and-message-sequencing-data01", "name": "method", "description": "publish, request, reply, add, cancel, refresh, counter, declinecounter.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "f-scheduling-method-and-message-sequencing-data02", "name": "sequence", "description": "Organizer revision number, starting at 0.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "f-scheduling-method-and-message-sequencing-data03", "name": "stamp_time", "description": "DTSTAMP or JSCalendar updated used as sequencing tie-breaker.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "f-scheduling-method-and-message-sequencing-data04", "name": "originator_role", "description": "organizer or attendee.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "f-scheduling-method-and-message-sequencing-data05", "name": "request_status", "description": "iTIP REQUEST-STATUS machine-readable result.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "f-scheduling-method-and-message-sequencing-artifact01", "name": "Scheduling message", "description": "One iTIP-style method payload correlated by UID, recurrence id, sequence and stamp time.", "media_or_form": [ "iTIP method payload (PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER)", "JSCalendar object carrying method and sequence" ], "serial": true, "identity_strategy": "Correlated by UID plus recurrence identifier plus SEQUENCE, with the later stamp time breaking equal-sequence ties; a higher sequence obsoletes a lower one for the same pair.", "source_refs": [ "SRC-002", "SRC-003" ] } ], "questions": [ { "id": "f-scheduling-method-and-message-sequencing-q01", "text": "Which scheduling method is being applied, who may send it, and is this a new object or a revision of an existing UID?", "kind": "process", "answer_data": [ "method (enum)", "originator_role (enum)", "is_new_uid (boolean)" ] }, { "id": "f-scheduling-method-and-message-sequencing-q02", "text": "What SEQUENCE and stamp time identify this revision, and does it obsolete a previously stored component with the same UID and recurrence id?", "kind": "lifecycle", "answer_data": [ "sequence (integer)", "stamp_time (rfc3339-date-time)", "obsoletes_sequence (integer)" ] }, { "id": "f-scheduling-method-and-message-sequencing-q03", "text": "If a reply arrives with a lower sequence or earlier stamp than the last persisted attendee response, should it be discarded?", "kind": "evidence", "answer_data": [ "last_persisted_sequence (integer)", "last_persisted_stamp (rfc3339-date-time)", "discard (boolean)" ] }, { "id": "f-scheduling-method-and-message-sequencing-q04", "text": "What spoofing, unauthorized organizer-replacement or flood controls apply to this scheduling message, as warned in iTIP security considerations?", "kind": "access", "answer_data": [ "authenticated_originator (boolean)", "organizer_replacement_authorized (boolean)" ] } ] } ] } ] }, { "id": "b-revision-execution-and-governance", "name": "Revision, Execution and Governance", "description": "Baselines and change control, progress and realization, closure, provenance, disclosure, retention and exchange.", "rationale": "GAO requires a maintained baseline and updates using actual progress and logic; PROV supplies attribution and derivation; NARA shows that schedule records carry authorized disposition; the calendaring standards define the disclosure and exchange primitives. Divergence between intention and outcome is the payload of this bundle.", "source_refs": [ "SRC-012", "SRC-007", "SRC-013", "SRC-001" ], "layers": [ { "id": "l-baseline-and-change-control", "name": "Baseline and Change Control", "description": "Frozen reference versions and the controlled record of what changed and why.", "source_refs": [ "SRC-012", "SRC-007", "SRC-003" ], "findings": [ { "id": "f-baseline-snapshot-and-approval", "name": "Baseline snapshot and approval", "description": "Immutable frozen versions of a plan against which later performance and variance are measured.", "source_refs": [ "SRC-012", "SRC-007" ], "questions": [ { "id": "q-baseline-scope", "text": "Which elements are frozen in the baseline and which remain live?", "kind": "composition", "answer_data": [ "Frozen element list", "Live element list", "Scope statement" ] }, { "id": "q-baseline-approval-authority", "text": "Who approved the baseline, and under what rule may the plan be re-baselined?", "kind": "authority", "answer_data": [ "Approver reference", "Re-baselining rule", "Threshold triggering re-baseline" ] }, { "id": "q-baseline-currency", "text": "How are multiple concurrent baselines distinguished, and which is current?", "kind": "identity", "answer_data": [ "Baseline identifiers", "Current baseline marker", "Purpose of each baseline" ] }, { "id": "q-baseline-tamper-evidence", "text": "How is it proven that a stored baseline has not been altered since freezing?", "kind": "security", "answer_data": [ "Content digest", "Digest algorithm", "Verification procedure" ] } ], "data_elements": [ { "id": "de-baseline-identifier", "name": "baselineIdentifier", "description": "Identifier of a frozen plan snapshot.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-012" ] }, { "id": "de-baseline-frozen-at", "name": "baselineFrozenAt", "description": "Instant the snapshot was frozen, RFC 3339 with seconds and explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-012" ] }, { "id": "de-baseline-approver-ref", "name": "baselineApproverRef", "description": "Agent that approved the baseline.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-007" ] }, { "id": "de-baseline-scope", "name": "baselineScope", "description": "Which parts of the plan the baseline covers.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-baseline-digest", "name": "baselineDigest", "description": "Content digest over the canonical form of the frozen snapshot.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-baseline-snapshot", "name": "Baseline snapshot", "description": "Immutable frozen copy of a plan revision with its digest and approval, held as the comparison reference for variance.", "media_or_form": [ "immutable snapshot object", "tagged version in a version-controlled store", "archived schedule file" ], "serial": true, "identity_strategy": "Plan identifier plus zero-padded baseline sequence issued by the owning system; the freeze timestamp, approver and digest are attributes, never the identifier.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "f-change-log-and-reason-codes", "name": "Change log and reason codes", "description": "The controlled record of what changed in a plan, why, on whose authority and at which distinct times.", "source_refs": [ "SRC-012", "SRC-002", "SRC-007", "SRC-004" ], "questions": [ { "id": "q-change-granularity", "text": "At what granularity is a change recorded: whole plan, entry, or individual field?", "kind": "composition", "answer_data": [ "Granularity rule", "Changed element references", "Before and after values" ] }, { "id": "q-change-reason-code", "text": "Which controlled reason code explains the change, distinguishing correction of an error from genuine re-planning?", "kind": "classification", "answer_data": [ "Reason code", "Reason code vocabulary reference", "Free-text justification" ] }, { "id": "q-change-authorization", "text": "Who authorized the change, and was downstream notification required?", "kind": "authority", "answer_data": [ "Authorizing agent", "Authorization basis", "Notified party references" ] }, { "id": "q-change-time-separation", "text": "Which timestamps record when the change was decided, applied and observed by consumers?", "kind": "temporal", "answer_data": [ "Decision timestamp", "Application timestamp", "Observation or ingestion timestamp" ] } ], "data_elements": [ { "id": "de-change-entry", "name": "changeEntry", "description": "One recorded change with target element, before and after values.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-change-reason-code", "name": "changeReasonCode", "description": "Controlled reason for the change.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-changed-by-ref", "name": "changedByRef", "description": "Agent that made or authorized the change.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-change-decided-at", "name": "changeDecidedAt", "description": "Time the change was decided.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-change-applied-at", "name": "changeAppliedAt", "description": "Time the change was applied to the record.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-003" ] }, { "id": "de-change-observed-at", "name": "changeObservedAt", "description": "Time a consumer received or observed the change, recorded when it differs from application time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-002" ] } ], "artifacts": [ { "id": "art-plan-change-log", "name": "Plan change log", "description": "Append-only sequence of change entries with reason codes, authorities and separated decision, application and observation times.", "media_or_form": [ "append-only change log", "commit history in a version-controlled store", "change register" ], "serial": true, "identity_strategy": "Plan identifier plus zero-padded change sequence assigned by the owning system; sequences are never reused and timestamps remain attributes.", "source_refs": [ "SRC-012", "SRC-007" ] } ], "inline_only_rationale": null } ] }, { "id": "l-progress-realization-and-closure", "name": "Progress, Realization and Closure", "description": "Recorded actuals against plan, the acts that realized intentions, and the terminal states of a plan.", "source_refs": [ "SRC-012", "SRC-007", "SRC-001", "SRC-003" ], "findings": [ { "id": "f-progress-actuals-and-variance", "name": "Progress actuals and variance", "description": "Progress recorded against the plan as of a stated status date, and the variance computed against baseline.", "source_refs": [ "SRC-012", "SRC-001", "SRC-003" ], "questions": [ { "id": "q-progress-method", "text": "How is progress expressed, and is the measurement method declared rather than assumed?", "kind": "measurement", "answer_data": [ "Progress value", "Method code such as percent complete or remaining duration", "Declared method definition" ] }, { "id": "q-actual-dates", "text": "Which actual start and finish dates are recorded, and are dates later than the status date rejected?", "kind": "temporal", "answer_data": [ "Actual start", "Actual finish", "Status date", "Future-actual validation rule" ] }, { "id": "q-variance-computation", "text": "What variance against the baseline is computed, and at which level of the plan?", "kind": "validation", "answer_data": [ "Variance value and unit", "Baseline reference", "Aggregation level" ] }, { "id": "q-status-date-validity", "text": "As of which status date is the progress statement valid, and who asserted it?", "kind": "provenance", "answer_data": [ "Status date", "Asserting agent", "Assertion timestamp" ] } ], "data_elements": [ { "id": "de-percent-complete", "name": "percentComplete", "description": "Completion proportion under the declared method.", "value_kind": "number", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-actual-start", "name": "actualStart", "description": "Recorded actual start instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "de-actual-finish", "name": "actualFinish", "description": "Recorded actual finish instant.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "de-remaining-duration", "name": "remainingDuration", "description": "Duration still required to complete.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-status-date", "name": "statusDate", "description": "Instant as of which the progress statement is valid.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-004" ] }, { "id": "de-baseline-variance", "name": "baselineVariance", "description": "Difference between actual or forecast and baseline dates.", "value_kind": "quantity", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "art-progress-update-record", "name": "Progress update record", "description": "Periodic record of actuals, remaining work and variance as of a status date, stored alongside rather than overwriting the baseline.", "media_or_form": [ "status update record", "schedule update export", "progress report" ], "serial": true, "identity_strategy": "Plan identifier plus zero-padded update sequence; the status date and asserting agent are attributes, and the status date is never used as the identifier.", "source_refs": [ "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "f-realization-and-fulfilment-link", "name": "Realization and fulfilment link", "description": "How intentions are linked to the acts that fulfilled them, including partial, substituted and unplanned outcomes.", "source_refs": [ "SRC-007", "SRC-001", "SRC-010" ], "questions": [ { "id": "q-realizing-acts", "text": "Which recorded acts realize this planned action, and is the correspondence one-to-one?", "kind": "relationship", "answer_data": [ "Realizing act references", "Cardinality of the correspondence", "Matching rule" ] }, { "id": "q-partial-fulfilment", "text": "How is partial or substituted fulfilment represented without overwriting the original intention?", "kind": "state", "answer_data": [ "Fulfilment degree code", "Substitution note", "Preserved original intention reference" ] }, { "id": "q-plan-followed", "text": "How is this plan recorded as the plan an executing agent actually followed?", "kind": "provenance", "answer_data": [ "Association between activity and agent", "Plan reference on that association", "Recording timestamp" ] }, { "id": "q-unplanned-acts", "text": "How are acts that occurred with no corresponding intention represented?", "kind": "exception", "answer_data": [ "Unplanned act references", "Retrospective attachment policy", "Reviewer decision" ] } ], "data_elements": [ { "id": "de-realized-by-act-ref", "name": "realizedByActRef", "description": "Recorded act that realized the planned action.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-fulfilment-degree", "name": "fulfilmentDegree", "description": "Whether the intention was fully, partly, or not fulfilled, or was substituted.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-010" ] }, { "id": "de-followed-plan-ref", "name": "followedPlanRef", "description": "Reference recording that an executing activity followed this plan.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-substitution-note", "name": "substitutionNote", "description": "Explanation where a different act satisfied the intention.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "art-realization-link-set", "name": "Realization link set", "description": "The many-to-many links between planned actions and the acts that realized them, with fulfilment degree and matching rationale.", "media_or_form": [ "link set or association collection", "provenance graph fragment", "reconciliation report" ], "serial": false, "identity_strategy": "Planned-action identifier plus act identifier plus link role; occurrence-level links additionally carry the recurrence identifier so a single occurrence can be matched.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "f-closure-and-abandonment", "name": "Closure and abandonment", "description": "Terminal states of a plan, the authority and reason for ending it, and the treatment of residual obligations.", "source_refs": [ "SRC-001", "SRC-003", "SRC-012", "SRC-009" ], "questions": [ { "id": "q-terminal-states", "text": "Which terminal states may a plan reach, and how are they distinguished from one another?", "kind": "lifecycle", "answer_data": [ "Terminal state code list", "Definition per state", "Allowed transitions into each" ] }, { "id": "q-abandonment-reason", "text": "What reason and authority are recorded when a plan is dropped before completion?", "kind": "decision", "answer_data": [ "Closure reason code", "Deciding agent", "Decision evidence reference" ] }, { "id": "q-residual-obligations", "text": "What happens to open commitments and future occurrences when the plan closes?", "kind": "exception", "answer_data": [ "Residual commitment references", "Cancellation or transfer action", "Notified counterparties" ] }, { "id": "q-post-closure-edit", "text": "May a closed plan be edited, and if not, how are subsequent corrections expressed?", "kind": "constraint", "answer_data": [ "Edit prohibition rule", "Correction mechanism", "Successor plan reference" ] } ], "data_elements": [ { "id": "de-plan-state", "name": "planState", "description": "Lifecycle state of the plan, including terminal states such as completed, superseded, cancelled or abandoned.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-plan-closed-at", "name": "planClosedAt", "description": "Instant the plan reached its terminal state.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] }, { "id": "de-closure-reason", "name": "closureReason", "description": "Controlled reason for closure or abandonment.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-residual-commitment-ref", "name": "residualCommitmentRef", "description": "Commitments still open at closure and their disposition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [ { "id": "art-plan-closure-record", "name": "Plan closure record", "description": "Record of the terminal state, reason, deciding authority and the disposition of residual commitments and future occurrences.", "media_or_form": [ "closure record", "cancellation notice to counterparties", "archival transfer note" ], "serial": false, "identity_strategy": "Plan identifier plus final revision counter; the closure timestamp and deciding agent are attributes of the record.", "source_refs": [ "SRC-001", "SRC-012" ] } ], "inline_only_rationale": null } ] }, { "id": "l-provenance-access-and-exchange", "name": "Provenance, Access and Exchange", "description": "Where a plan came from, who may see what, how long it is kept, and how it maps to external vocabularies.", "source_refs": [ "SRC-007", "SRC-013", "SRC-001", "SRC-003", "SRC-011", "SRC-014" ], "findings": [ { "id": "f-plan-provenance-and-attribution", "name": "Plan provenance and attribution", "description": "The agent and activity that produced a plan version, and the prior plans, templates or forecasts it derives from.", "source_refs": [ "SRC-007", "SRC-004", "SRC-015" ], "questions": [ { "id": "q-plan-attribution", "text": "Which agent, human or software, generated this plan version, and under which activity?", "kind": "provenance", "answer_data": [ "Attributed agent reference", "Generating activity reference", "Generation timestamp" ] }, { "id": "q-plan-derivation", "text": "From which prior plan, template or forecast is this plan derived?", "kind": "relationship", "answer_data": [ "Derived-from references", "Derivation kind", "Transformation description" ] }, { "id": "q-planning-agent-type", "text": "Is the planning agent autonomous software, and are its identity and version recorded?", "kind": "classification", "answer_data": [ "Agent type code", "Software name and version", "Operating human principal" ] }, { "id": "q-plan-trigger", "text": "Which upstream instruction or request caused the plan to be created?", "kind": "authority", "answer_data": [ "Triggering request reference", "Requesting agent", "Received timestamp" ] } ], "data_elements": [ { "id": "de-attributed-agent-ref", "name": "attributedAgentRef", "description": "Agent to which the plan version is attributed.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-generating-activity-ref", "name": "generatingActivityRef", "description": "Activity that generated the plan version.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-derived-from-ref", "name": "derivedFromRef", "description": "Prior plan, template or forecast the plan derives from.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-generated-at", "name": "generatedAt", "description": "Time the plan version was generated, RFC 3339 with seconds and explicit offset or Z.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-004", "SRC-007" ] }, { "id": "de-software-agent-version", "name": "softwareAgentVersion", "description": "Name and version of a software planning agent.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-007", "SRC-015" ] } ], "artifacts": [ { "id": "art-plan-provenance-graph", "name": "Plan provenance graph", "description": "Graph of attribution, generation, association and derivation relations connecting plan versions, planning agents and executing activities.", "media_or_form": [ "provenance graph serialization", "provenance bundle", "lineage table" ], "serial": false, "identity_strategy": "Plan identifier plus revision counter identifies the described entity; the graph itself carries a governed IRI in the owner package namespace.", "source_refs": [ "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "f-disclosure-access-and-retention", "name": "Disclosure, access and retention", "description": "The level of detail each audience may see, the grants that permit it, and how long plan records are kept before authorized disposition.", "source_refs": [ "SRC-001", "SRC-003", "SRC-013", "SRC-009" ], "questions": [ { "id": "q-disclosure-level", "text": "At which level of detail is the entry shared: full content, busy-only, or hidden entirely?", "kind": "privacy", "answer_data": [ "Disclosure class code", "Audience scope", "Redacted field list" ] }, { "id": "q-access-grant-scope", "text": "Which grants let a non-owner read or write the plan, and do they apply per entry or per plan?", "kind": "access", "answer_data": [ "Grantee references", "Permitted operations", "Grant scope and expiry" ] }, { "id": "q-retention-period", "text": "How long are plan, schedule and commitment records retained after closure, and under whose records schedule?", "kind": "retention", "answer_data": [ "Retention rule reference", "Retention trigger and period", "Authorizing schedule and role dependency" ] }, { "id": "q-deletion-tombstone", "text": "When an entry is deleted, what marker remains so that replicas do not resurrect it?", "kind": "exception", "answer_data": [ "Tombstone marker", "Tombstone retention window", "Replication reconciliation rule" ] }, { "id": "q-sensitive-fields", "text": "Which fields may reveal sensitive location, health or negotiation information and must be redacted in projections?", "kind": "security", "answer_data": [ "Sensitive field list", "Redaction rule per projection", "Approving role" ] } ], "data_elements": [ { "id": "de-disclosure-class", "name": "disclosureClass", "description": "Access classification of the entry, such as public, private or confidential.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-access-grant", "name": "accessGrant", "description": "Grant of read or write permission to a named agent with scope and expiry.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "de-retention-rule-ref", "name": "retentionRuleRef", "description": "Reference to the authorized records schedule item governing disposition.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-disposition-action", "name": "dispositionAction", "description": "Authorized action taken at end of retention, such as destroy or transfer.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-tombstone-marker", "name": "tombstoneMarker", "description": "Record that an entry or occurrence was deleted, retained for the replication horizon.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001", "SRC-002" ] } ], "artifacts": [ { "id": "art-disclosure-retention-policy", "name": "Disclosure and retention policy", "description": "The owner package's binding statement of disclosure classes per audience, access grant rules, retention periods and authorized disposition actions.", "media_or_form": [ "policy document", "machine-readable access and retention rules", "records schedule mapping table" ], "serial": false, "identity_strategy": "Owner package namespace IRI plus policy identifier and version label, cross-referencing the external records schedule item that authorizes each disposition.", "source_refs": [ "SRC-013", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "f-interoperability-and-exchange-alignment", "name": "Interoperability and exchange alignment", "description": "Mappings to external calendaring and planning vocabularies, the losses in each direction, and what any conformance claim rests on.", "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-014", "SRC-002", "SRC-015" ], "questions": [ { "id": "q-alignment-targets", "text": "To which external vocabularies does this model map, and which elements are lossy in each direction?", "kind": "interoperability", "answer_data": [ "Target vocabulary identifiers and versions", "Element-level mapping table", "Lossy construct list per direction" ] }, { "id": "q-round-trip-preservation", "text": "Does an export and re-import round trip preserve identity, revision counter and occurrence overrides?", "kind": "validation", "answer_data": [ "Round-trip test result", "Preserved and lost element lists", "Test fixture reference" ] }, { "id": "q-conformance-basis", "text": "What evidence supports a conformance claim, as distinct from a mere alignment?", "kind": "evidence", "answer_data": [ "Claim statement", "Test evidence reference", "Scope and exclusions of the claim" ] }, { "id": "q-local-extension-carriage", "text": "How are locally required fields carried without breaking a receiving implementation?", "kind": "constraint", "answer_data": [ "Extension namespace", "Ignore-unknown rule", "Criticality marking convention" ] } ], "data_elements": [ { "id": "de-alignment-target", "name": "alignmentTarget", "description": "External vocabulary the model aligns to, with version.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-011", "SRC-014" ] }, { "id": "de-mapping-rule", "name": "mappingRule", "description": "Element-level mapping with direction and loss annotation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-014" ] }, { "id": "de-round-trip-lossy-flag", "name": "roundTripLossyFlag", "description": "Whether the mapping is lossy in at least one direction.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "de-extension-namespace", "name": "extensionNamespace", "description": "Namespace under which local extension fields are carried.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-005" ] } ], "artifacts": [ { "id": "art-alignment-mapping-table", "name": "Alignment and mapping table", "description": "Element-level mapping between this model and each external vocabulary, annotated with direction, loss and round-trip test evidence.", "media_or_form": [ "mapping table", "crosswalk specification", "conformance test report" ], "serial": false, "identity_strategy": "Owner package namespace plus mapping identifier, target vocabulary identifier and target version; each mapping version is pinned to the model revision it was tested against.", "source_refs": [ "SRC-001", "SRC-011", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "fn-draft-and-classify-plan", "name": "Draft and classify a plan", "description": "Create a plan with an authoritative identifier, an owner, a declared intent mode and a horizon, and record who produced it.", "inputs": [ "Goal statement", "Owner agent reference", "Candidate intent mode and plan kind", "Planning horizon" ], "outputs": [ "Plan record in draft state", "Intent mode and plan kind assignment", "Provenance attribution to the planning agent" ], "preconditions": [ "Owner agent resolvable in an agent model", "Identifier source declared as master system, governed identifier or locally minted" ], "effects": [ "Plan exists with revision counter zero", "Generation time and attributed agent recorded", "Actionability follows from intent mode, not from existence of the record" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-010" ] }, { "id": "fn-bind-entry-to-time", "name": "Bind a planned action to time", "description": "Create a schedule entry that anchors a planned action to an instant, interval, duration or deadline in a declared time form.", "inputs": [ "Planned action reference", "Anchor form and time values", "Time form and time zone identifier where applicable" ], "outputs": [ "Schedule entry with recorded time form", "Recorded time zone database release" ], "preconditions": [ "Planned action exists", "Time zone identifier resolves in the referenced database release", "Absolute values expressed with seconds and an explicit offset or Z" ], "effects": [ "Entry bound and revision counter incremented", "Floating times preserved as floating rather than coerced to an offset" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-004", "SRC-005", "SRC-006" ] }, { "id": "fn-expand-recurrence", "name": "Expand a recurrence into occurrences", "description": "Generate the ordered occurrence set for a bounded horizon by applying the rule, then the additions, then the exclusions and overrides.", "inputs": [ "Recurrence rule", "Anchor start and expansion zone", "Overrides, additions and exclusions", "Requested horizon" ], "outputs": [ "Ordered occurrence set keyed by recurrence identifier", "Flags on occurrences affected by an offset or daylight-saving transition" ], "preconditions": [ "Anchor start and grammar declared", "Week start setting known where by-week parts are used" ], "effects": [ "Occurrences produced as a projection only, never persisted as the system of record", "Excluded occurrences are not regenerated" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-011", "SRC-014" ] }, { "id": "fn-compute-network-schedule", "name": "Compute the network schedule", "description": "Derive early and late dates, total and free float and the driving path from durations, dependencies, date constraints and working calendars.", "inputs": [ "Activities with durations and duration kinds", "Dependencies with types and lags", "Date constraints", "Working calendars" ], "outputs": [ "Derived early and late dates", "Total and free float per activity", "Driving path activity sequence", "Immutable computation run record" ], "preconditions": [ "Network is acyclic", "Every activity has a duration and, except start and finish milestones, a predecessor and a successor" ], "effects": [ "Derived dates flagged as computed rather than asserted", "Prior run retained for comparison" ], "source_refs": [ "SRC-012", "SRC-015" ] }, { "id": "fn-assess-schedule-integrity", "name": "Assess schedule integrity", "description": "Run structural and credibility checks against a plan revision and record the result as evidence.", "inputs": [ "Plan revision", "Threshold set", "Latest computation run" ], "outputs": [ "Health assessment with defect list", "Horizontal and vertical traceability result", "Pass or fail per metric" ], "preconditions": [ "A computation run exists for the revision under assessment" ], "effects": [ "Assessment recorded as evidence with its own observation timestamp", "May block baseline approval where a required check fails" ], "source_refs": [ "SRC-012" ] }, { "id": "fn-record-commitment", "name": "Record a commitment", "description": "Bind an intention to a named beneficiary with terms, qualifying conditions and the consequence of non-fulfilment.", "inputs": [ "Assigner and beneficiary references", "Referenced planned action", "Terms, constraints and consequence duty", "Commitment basis" ], "outputs": [ "Commitment record in active state", "Verification entitlement for the beneficiary" ], "preconditions": [ "Both parties resolvable", "The underlying planned action exists and is not already closed" ], "effects": [ "Subsequent changes to the committed terms require beneficiary notification and a change-log entry", "Breach evaluation point established" ], "source_refs": [ "SRC-009", "SRC-002", "SRC-010" ] }, { "id": "fn-reconcile-participant-responses", "name": "Reconcile participant responses", "description": "Apply inbound replies and counter-proposals to an entry and resolve competing revisions deterministically.", "inputs": [ "Entry identifier", "Inbound replies and counter-proposals", "Current revision counter and modification timestamp" ], "outputs": [ "Updated participant roster and response states", "Accepted or declined counter-proposal outcome" ], "preconditions": [ "The applying agent holds write authority over the master object", "Inbound items carry the entry identifier and a revision counter" ], "effects": [ "Competing revisions resolved by identifier, then revision counter, then modification timestamp", "A later timestamp with a lower counter never wins" ], "source_refs": [ "SRC-002", "SRC-001", "SRC-003" ] }, { "id": "fn-freeze-baseline", "name": "Freeze a baseline", "description": "Capture an immutable, digested snapshot of a plan revision as the reference for later variance measurement.", "inputs": [ "Plan revision", "Approver reference", "Baseline scope" ], "outputs": [ "Immutable baseline snapshot with content digest", "Approval record" ], "preconditions": [ "Approver holds approval authority", "An integrity assessment exists for the revision" ], "effects": [ "Snapshot stored append-only and never edited in place", "Variance computation against this baseline enabled" ], "source_refs": [ "SRC-012", "SRC-007" ] }, { "id": "fn-apply-plan-change", "name": "Apply a plan change", "description": "Apply a field-scoped patch under optimistic concurrency, with a controlled reason and separated decision, application and observation times.", "inputs": [ "Field-scoped patch", "Expected revision counter", "Reason code and authorizing agent" ], "outputs": [ "New plan revision", "Change-log entry", "Notifications to affected beneficiaries and participants" ], "preconditions": [ "Expected revision counter matches the current counter", "Reason code drawn from the registered vocabulary" ], "effects": [ "Counter incremented for material fields only", "Committed terms not altered without beneficiary notification", "Decision, application and observation times recorded separately" ], "source_refs": [ "SRC-012", "SRC-002", "SRC-003", "SRC-004" ] }, { "id": "fn-record-progress-and-realization", "name": "Record progress and realization", "description": "Record actuals as of a status date, compute variance against the baseline and link realizing acts to the intentions they fulfilled.", "inputs": [ "Status date", "Actual dates, percent complete or remaining duration", "Realizing act references" ], "outputs": [ "Progress record", "Variance against the named baseline", "Realization links with fulfilment degree" ], "preconditions": [ "A baseline exists where variance is requested", "No actual date is later than the status date" ], "effects": [ "Actuals stored alongside the baseline, which is never overwritten", "Divergence between intention and outcome preserved as data" ], "source_refs": [ "SRC-012", "SRC-007", "SRC-001" ] }, { "id": "fn-project-disclosure-view", "name": "Project a disclosure-limited view", "description": "Produce an agenda, network or busy-only projection for a requester at the disclosure level they are granted.", "inputs": [ "Requesting agent", "Requested scope and horizon", "Resolved access grants and disclosure classes" ], "outputs": [ "Agenda, network or free/busy projection", "Redaction record for withheld fields" ], "preconditions": [ "Access decision resolved with deny-by-default applied", "Requested horizon bounded" ], "effects": [ "Sensitive fields redacted per projection rule", "Reads of full-detail entries by non-owners logged with actor, scope, purpose and timestamp" ], "source_refs": [ "SRC-001", "SRC-003", "SRC-002" ] }, { "id": "fn-close-and-dispose", "name": "Close a plan and apply disposition", "description": "Move a plan to a terminal state, settle residual commitments and future occurrences, and apply authorized retention disposition.", "inputs": [ "Plan reference", "Terminal state and closure reason", "Applicable retention rule" ], "outputs": [ "Closure record", "Cancellation or transfer notices", "Disposition action record or continued retention" ], "preconditions": [ "Open commitments resolved, transferred or explicitly acknowledged as residual", "No legal hold in force" ], "effects": [ "Plan sealed against further edits; corrections expressed as a successor plan", "Future occurrences cancelled with tombstones retained for the replication horizon", "Disposition logged with the authorizing records schedule item" ], "source_refs": [ "SRC-013", "SRC-001", "SRC-009", "SRC-012" ] }, { "id": "fn-split-this-and-future", "name": "Split this-and-future", "description": "Truncate a recurring master at the previous occurrence and create a new master for future occurrences, linking the objects with first and next relations.", "inputs": [ "Recurring master item", "Split point" ], "outputs": [ "Truncated original master and a new master covering future occurrences" ], "preconditions": [ "The item is a recurring master with occurrences after the split point" ], "effects": [ "Original series truncated at the previous occurrence", "New master created with its own identity and linked by first and next relations" ], "source_refs": [ "SRC-003" ] } ], "composition": [ { "target": "WM-ACT-006 Task", "relation": "REFERENCE", "purpose": "A task references the plan or schedule that authorizes it, while the plan remains independently versioned so a task state change does not revise the plan. JSCalendar keeps Task and Event as separate object types for the same reason, and the FHIR intent gradient shows that a plan does not by itself authorize another party to act.", "required": false, "source_refs": [ "SRC-003", "SRC-010" ] }, { "target": "Act / Action model (legacy world.actAction, K2)", "relation": "REFERENCE", "purpose": "Recorded acts realize planned actions. PROV models this as an Activity associated with an Agent that had a Plan, so the realization link is a reference between two independently identified entities rather than a state change on one.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "Process & Workflow model (legacy world.processAndWorkflow, K3)", "relation": "REFERENCE", "purpose": "Recurring operational schedules instantiate a standing process definition. The definition is a reusable type carrying steps and conditions; the dated intention, recurrence rule and overrides stay in this model.", "required": false, "source_refs": [ "SRC-007", "SRC-015" ] }, { "target": "Project model (legacy world.project, K5)", "relation": "REFERENCE", "purpose": "A project binds its integrated schedule, baselines and variance from this model instead of redefining them, consistent with GAO treating the reliable schedule as an artifact assessed within, but distinct from, programme management.", "required": false, "source_refs": [ "SRC-012" ] }, { "target": "Person and Organization agent models", "relation": "REFERENCE", "purpose": "Planning agents, owners, organizers, participants, assigners and beneficiaries are references to agent records. Agent identity, contact data and organizational structure are never duplicated on the plan.", "required": true, "source_refs": [ "SRC-007", "SRC-009" ] }, { "target": "W3C PROV-O", "relation": "ALIGN", "purpose": "prov:Plan, prov:hadPlan, prov:qualifiedAssociation, prov:wasGeneratedBy, prov:wasDerivedFrom and prov:wasAttributedTo anchor plan provenance and the plan-to-activity link. Alignment only; no conformance is claimed without a validated mapping.", "required": false, "source_refs": [ "SRC-007" ] }, { "target": "IETF RFC 5545 iCalendar and RFC 8984 JSCalendar", "relation": "ALIGN", "purpose": "Schedule entry anchoring, time forms, recurrence and overrides, participant roles, status vocabularies, priority and disclosure class align to these standards. Both are alignments, not conformance claims, until a round-trip test is recorded.", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "IETF RFC 5546 iTIP", "relation": "ALIGN", "purpose": "Organizer write authority, participation status values, counter-proposal negotiation and the identifier-then-counter-then-timestamp conflict rule are adopted from iTIP rather than reinvented.", "required": false, "source_refs": [ "SRC-002" ] }, { "target": "W3C ODRL Information Model 2.2", "relation": "ALIGN", "purpose": "Commitment structure aligns to Agreement, Duty and Obligation between assigner and assignee, with constraints as qualifying conditions and consequence as the duty arising on non-fulfilment.", "required": false, "source_refs": [ "SRC-009" ] }, { "target": "W3C Time Ontology in OWL", "relation": "ALIGN", "purpose": "Instant, Interval, Duration, temporal reference systems and Allen relations give a formal reading of entries and ordering. Cited as alignment with reduced weight because it remains a Candidate Recommendation Draft rather than a Recommendation.", "required": false, "source_refs": [ "SRC-008" ] }, { "target": "IANA Time Zone Database", "relation": "REFERENCE", "purpose": "Time zone identifiers and their rules are referenced by identifier and release, never copied into the model, so that a database release can trigger recomputation of stored future local times.", "required": true, "source_refs": [ "SRC-006", "SRC-005" ] }, { "target": "HL7 FHIR RequestIntent and Timing", "relation": "ALIGN", "purpose": "Supplies the evidenced intent-mode gradient and an independent recurrence grammar used for cross-domain mapping and for demonstrating that recurrence vocabularies are not isomorphic.", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "target": "schema.org Schedule and Event", "relation": "ALIGN", "purpose": "Projection target for publishing recurring intentions publicly, with eventSchedule attaching a repeat pattern to an event rather than enumerating occurrences.", "required": false, "source_refs": [ "SRC-014" ] }, { "target": "PDDL2.1 durative-action semantics", "relation": "ALIGN", "purpose": "Machine planner output maps onto planned actions with duration constraints and conditions annotated at-start, over-all and at-end; the finer annotation is preserved locally because calendar components cannot express it.", "required": false, "source_refs": [ "SRC-015" ] }, { "target": "Dimension ownership, access and audit service models", "relation": "MIX-IN", "purpose": "Access decisions, grant management and audit trails are inherited from the Dimension's service models. This model carries only the disclosure class and transparency of an entry and a reference to the retention rule that authorizes disposition.", "required": true, "source_refs": [ "SRC-001", "SRC-003", "SRC-013" ] }, { "target": "Records retention schedule authority", "relation": "REFERENCE", "purpose": "Retention and disposition of plan and calendar records are governed by an external, role-dependent records schedule, as shown by schedules that treat calendars of ordinary and senior officials under different authorities.", "required": false, "source_refs": [ "SRC-013" ] }, { "target": "Cost estimating and earned value model", "relation": "REFERENCE", "purpose": "Cost baselines, budgets and earned value are deliberately excluded and referenced instead; GAO treats schedule assessment and cost estimating as linked but separate bodies of guidance.", "required": false, "source_refs": [ "SRC-012" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name one accountable owner package for WM-ACT-008 and register its namespace before any plan instance is created; the owner package declares which external system is the authoritative master for plan and entry identifiers.", "Publish the value sets the package uses for intent mode, plan kind, dependency type, change reason, closure reason and disclosure class, or reference a registered external value set for each.", "Declare the canonical recurrence grammar, the expansion time zone policy, the week start setting and the time zone database release policy, including what triggers recomputation of stored future local times.", "Declare the retention rules and authorizing records schedule that apply to plans, schedule entries, commitments and their audit logs, distinguishing roles whose schedules differ." ], "namespace_guidance": "Use a stable, resolvable namespace under the adopting Dimension, for example /world-model/act/plan-schedule/, with sub-paths for value sets, mapping tables and policies. Never mint local terms inside the iCalendar, JSCalendar, FHIR or schema.org namespaces. Local extension fields travel in a distinctly named namespace so a receiving implementation can ignore what it does not understand, and are marked critical only when ignoring them would produce a wrong time.", "registry_links": [ "Vercy registry entry vr.wm-act-008, record plane world-model, navigation path NAV.ACT.PLN", "IANA Time Zone Database releases, referenced by release identifier", "IANA iCalendar property, parameter and value registries established by RFC 5545", "The owner package's published value sets and alignment mapping tables" ] }, "canon_and_patch": { "canonicalization_rules": [ "Normalize every absolute timestamp to RFC 3339 with explicit seconds and an explicit numeric offset or Z before hashing or comparison; never normalize a floating local time to an offset, because floating time is a deliberate semantic choice rather than a missing value.", "Keep the IANA time zone identifier alongside any offset, and where the projection permits use the bracketed suffix form so offset and zone travel together and a conflict between them is detectable.", "Do not expand recurrence rules during canonicalization. The rule plus its additions, exclusions and overrides is the canonical form; an expanded occurrence list is a projection with a stated horizon.", "Order collections deterministically before serialization: participants by agent identifier, dependencies by predecessor then successor then type, overrides by recurrence identifier, and change entries by sequence.", "Distinguish asserted from derived fields in the canonical form so a computed date never becomes indistinguishable from an input date after a round trip." ], "patch_rules": [ "Patches are field-scoped and must carry the target plan or entry identifier, the expected current revision counter and a registered reason code; a counter mismatch is rejected rather than merged.", "Any patch touching start, end, duration, due, recurrence rule, overall status, intent mode or participant set increments the revision counter; annotation, description and cosmetic changes do not.", "Occurrence-level patches must state whether they apply to a single occurrence or to that occurrence and all later ones, and must key on the recurrence identifier rather than a display date.", "Baselines are immutable. A correction is expressed as a new baseline plus a change-log entry referencing the superseded one, never as an in-place edit.", "Patches that alter committed terms require the beneficiary notification record to be present before the patch is accepted." ], "compatibility_rules": [ "Adding optional elements or new codes to an open value set is backward compatible; changing the meaning of an intent mode, dependency type, status or disclosure class is breaking and requires a new model version.", "Unknown extension fields must be preserved across a round trip and must not block validation, unless they are explicitly marked critical, in which case processing stops.", "Conflicting revisions of the same identifier are resolved by highest revision counter, then latest modification timestamp; an exact tie is escalated to a human decision and never silently merged.", "A projection may omit fields but may not invent them; a busy-only view is a valid projection, a view that infers a time zone the record does not carry is not." ] }, "artifact_rules": { "identity_priority": [ "Authoritative master-system identifier issued by the system of record for the plan or entry, recorded together with the identity of the issuing system.", "Governed global identifier or IRI from a registered namespace, such as a globally unique calendar object identifier that is stable across revisions, or a registry IRI.", "UUID or ULID minted by the adopting Dimension where neither of the above exists, explicitly flagged as locally minted so downstream systems do not mistake it for an authoritative key.", "A date, a start time, a title or a position in a recurrence series is never an identifier. One occurrence of a recurring intention is identified by the series identifier plus its recurrence identifier." ], "timestamp_rule": "All absolute time values use RFC 3339 with explicit seconds and an explicit numeric UTC offset or the Z designator. Event time, meaning when the planned or actual occurrence is or was set, is recorded separately from observation or ingestion time, meaning when this system learned of it, and separately again from decision time on change records, whenever those differ. Zoned local entries additionally carry an IANA time zone identifier and the database release in force. Floating local times deliberately carry no offset and must be flagged as floating rather than coerced into one; the -00:00 offset means the instant is known in UTC but the local offset is not, and must not be treated as equivalent to Z.", "serial_naming_rule": "Serial artifacts, namely revision histories, baseline snapshots, change logs, progress updates, scheduling runs, risk analyses, health assessments and settlement records, are named --. Sequences are assigned by the owning system, never reused, and never derived from a date; freeze, run and status timestamps are stored as attributes of the record.", "integrity_rule": "Every artifact carries a content digest computed over its canonical form together with the identifier and revision counter of the plan state it describes. Baselines, change logs, progress records and audit entries are append-only; a later correction is a new entry that references the superseded one, so that the divergence between what was intended and what was recorded stays inspectable." }, "policies": [ "Intent mode governs actionability: an agent must not execute against a plan whose intent mode is proposal or option without a recorded authorization step, because a plan expresses intention without authorizing another party to act.", "Divergence is data, not error. The intention as baselined is never overwritten by what happened; actuals, variance and realization links are stored alongside it.", "No conformance claim to an external standard is published without recorded round-trip test evidence; without that evidence the relationship is documented as an alignment.", "Committed terms are not silently altered. Any change to a commitment or to a committed date requires beneficiary notification and a change-log entry with a registered reason code.", "Derived values are labelled as derived. Computed dates, float and critical-path membership carry a reference to the scheduling run that produced them and are invalidated when their inputs change.", "Deletion is recorded, not performed silently. Cancelled occurrences and deleted entries leave a tombstone for the replication horizon so replicas do not resurrect them.", "The planning agent owns plans, schedule entries and commitments; beneficiaries may verify commitments made to them but cannot mutate the master object except via REPLY, COUNTER or delegated REQUEST.", "Cancelled, revoked or invalidated plans are retained for audit of commitments and of intention-versus-act divergence unless a documented purge policy and legal basis apply.", "Free-busy and other reduced projections MUST NOT leak summary, description, attendees or assumption content.", "External standard alignments are recorded as ALIGN; no interchange round-trip is claimed as conformant without a stored expansion profile and mapping evidence." ], "crud": { "read": [ "Read the current plan revision by authoritative identifier; every read returns the revision counter and modification timestamp so a caller can detect staleness.", "Read a projection such as agenda, network or busy-only with the disclosure class enforced per entry and redactions recorded.", "Read an expanded occurrence series for an explicitly bounded horizon; the expansion is labelled as derived and is never returned as the system of record.", "Read a baseline, scheduling run, assessment or change-log entry by its serial identifier for evidence and audit purposes." ], "create": [ "Create a plan only with an owner, a declared intent mode and a resolvable identifier; the creating agent and generation time are recorded as provenance.", "Create a schedule entry only against an existing planned action or goal; orphan entries are rejected.", "Create a commitment only where both parties resolve and the underlying intention exists and is open.", "Create serial evidence records, such as baselines and assessments, as append-only artifacts with content digests." ], "update": [ "Update through field-scoped patches carrying the expected revision counter; mismatched counters are rejected rather than merged.", "Update a recurring series through either a series-level patch or an occurrence-level override, with the range of effect stated explicitly.", "Update participation state only from the participant or their delegate, and update master-object content only from the write-authority holder.", "Update that moves a committed entry requires a registered reason code and a beneficiary notification record." ], "delete": [ "Delete an occurrence by recording an exclusion or cancellation rather than removing it, so expansion does not regenerate it.", "Delete an entry or plan only where a retention rule authorizes disposition and no legal hold is in force; the disposition action, authorizing rule and time are logged.", "Retain a tombstone for at least the replication horizon after any deletion, then dispose of it under the same authority.", "Never delete baselines, change logs or audit entries for convenience; they are disposed of only under an authorized records schedule." ] }, "roles": [ { "name": "Plan Owner", "responsibilities": [ "Accountable for the content, currency and truthfulness of the plan", "Approves baselines, closure and re-baselining", "Grants and revokes access to the plan and its entries" ] }, { "name": "Scheduler (write-authority holder)", "responsibilities": [ "Holds write authority over the master plan object and transfers it explicitly", "Maintains network logic, durations, calendars and constraints", "Runs scheduling computations and preserves prior run results" ] }, { "name": "Participant", "responsibilities": [ "Responds to invitations and maintains an accurate participation state", "Reports actual progress on assigned planned actions as of a stated status date", "Delegates participation explicitly, with delegator and delegate both recorded" ] }, { "name": "Commitment Beneficiary", "responsibilities": [ "Verifies the existence, terms and fulfilment state of commitments made to them", "Receives notification of any change to committed terms", "Accepts or disputes fulfilment evidence; holds no edit rights over the plan" ] }, { "name": "Assurance Reviewer", "responsibilities": [ "Runs integrity and quality assessments against named plan revisions", "Records findings as evidence with their own observation timestamps", "May block baseline approval where a required check fails" ] }, { "name": "Records Custodian", "responsibilities": [ "Applies retention rules and authorized disposition actions", "Maintains tombstones, legal holds and the disposition audit log", "Ensures baselines, change logs and audit entries remain append-only until disposition" ] } ], "access": { "default_rule": "Deny by default. A non-owner sees nothing until a grant resolves; external parties default to busy-only disclosure with no entry content, and each grant states its scope, permitted operations and expiry.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Commitment beneficiaries may read the terms and fulfilment state of commitments made to them even without plan-level access.", "Assurance reviewers may read structure, logic, dates and health metrics across a plan while sensitive entry content remains redacted.", "A legal hold overrides scheduled disposition and freezes deletion, including tombstone disposal, until the hold is released.", "Break-glass access for safety-of-life or emergency coordination may be granted out of band and must be logged as an exceptional access event with a recorded justification and a mandatory post-hoc review.", "Free/busy disclosure may be granted to a wider audience than entry content, because availability can be published without revealing intention.", "Beneficiary verification of a named commitment without exposing unrelated plan content.", "Break-glass clinical or safety read of a CarePlan-aligned instance, always audited.", "Legal hold preventing cancel-to-purge of a commitment or baseline.", "Public CLASS or JSCalendar public items readable at the published detail level." ], "audit_requirements": [ "Log every read of a full-detail entry by a non-owner with actor, scope, purpose and an RFC 3339 timestamp carrying seconds and an explicit offset or Z.", "Log every disclosure-class change, access grant, delegation and revocation, with the authorizing agent.", "Log every disposition action with the retention rule that authorized it and the records custodian who applied it.", "Log every break-glass access separately and route it for post-hoc review.", "Log every change to committed terms together with the beneficiary notification record.", "Record who read which projection at what time, including free-busy reads.", "Record every SEQUENCE increment, method, cancel, revoke, baseline freeze and this-and-future split with event time and ingestion time.", "Record access exceptions with acting agent, justification and expiry." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner or maintainer", "Model version and registry identifier", "Identity policy URL", "Time and time zone policy URL", "Retention and disposition policy URL" ], "read_order": [ "AGENTS.md, to obtain the model name, type and the four resolvable URLs", "Specification URL, for scope, boundaries, bundles, layers, findings and value sets", "Storage type URL, for the canonical form, serialization projection and canonicalization rules", "Interface URL, for read and patch operations, concurrency by revision counter and disclosure enforcement", "Processes URL, for planning, scheduling computation, baseline, change control, closure and retention procedures", "Registry entry vr.wm-act-008, for composition links to sibling and referenced models" ] } }, "coverage": { "claim": "The merged model covers plan identity, intent strength and authority; planned content, goals and assumptions; temporal binding with time-zone, floating-time, duration and recurrence semantics; the dependency network, date constraints, integrity checks and derived dates; commitment, participation and (newly imported) iTIP scheduling-message sequencing; and baseline, change control, progress, realization, provenance, disclosure and retention. Every retained node carries at least one primary-source reference from the accepting pack. No universal completeness is claimed: non-Gregorian recurrence (RFC 7529), availability components (RFC 7953), hierarchical/constraint-based planning, cost and earned value, and non-US retention law are explicitly outside scope or unverified.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Mandatory globally unique identifier and revision counter come from RFC 8984 and RFC 5545; occurrence identity uses series identifier plus recurrence identifier, never a date. Identity priority puts the authoritative master-system identifier first." }, { "dimension": "lifecycle", "status": "covered", "notes": "Pre-realization states from iCalendar VEVENT and VTODO status vocabularies, intent-mode gradient from FHIR RequestIntent, commitment states from ODRL, and terminal plan states with closure reason and residual obligation handling." }, { "dimension": "relationships", "status": "covered", "notes": "Ordering dependencies with type and lag grounded in GAO practice, Allen relations from OWL-Time as a formal reading, participant and delegation links from iTIP, and many-to-many realization links via PROV." }, { "dimension": "temporal", "status": "covered", "notes": "Three time forms, RFC 3339 profile with seconds and explicit offset, RFC 9557 zone tags, IANA release tracking, duration kinds and working calendars, recurrence rules with overrides and exclusions. This is the deepest layer of the model." }, { "dimension": "provenance", "status": "covered", "notes": "PROV-O attribution, generation, association with hadPlan and derivation; asserted versus derived date flagging; separated decision, application and observation timestamps." }, { "dimension": "ownership", "status": "covered", "notes": "Owner accountability distinguished from iTIP organizer write authority and from approval authority; delegation recorded explicitly; beneficiary rights modelled without edit rights." }, { "dimension": "validation", "status": "covered", "notes": "GAO ten best practices drive the integrity finding: activity completeness, logic defects, horizontal and vertical traceability, valid critical path, reasonable total float, schedule risk analysis. Round-trip tests gate any conformance claim." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with the four required scopes, disclosure class from iCalendar CLASS and JSCalendar privacy, free/busy as a distinct disclosure level, five named exceptions including legal hold and logged break-glass." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Grounded on NARA GRS 5.1, which schedules calendars and daily activity schedules of non-high-level officials while senior officials' records fall under a different authority, evidencing role-dependent retention. Deletion is tombstoned so replicas do not resurrect occurrences." }, { "dimension": "interoperability", "status": "covered", "notes": "Alignments to iCalendar, JSCalendar, iTIP, FHIR Timing, schema.org Schedule and PDDL2.1, with an explicit finding on lossy mapping, round-trip preservation and extension carriage. Alignments are never presented as conformance." }, { "dimension": "spatial", "status": "covered", "notes": "Location and coordinates on entries per RFC 5545, plus the question of whether location determines the applicable time zone. Deliberately thin: place semantics belong to a location sibling model." }, { "dimension": "measurement", "status": "covered", "notes": "Float, variance, effort, allocation units, progress method declaration, confidence percentile and health metric thresholds, each with a declared unit or scale." }, { "dimension": "security", "status": "covered", "notes": "Baseline tamper-evidence via content digest, append-only evidence records, sensitive-field redaction in projections, and audit obligations on exceptional access." }, { "dimension": "authority and bindingness", "status": "covered", "notes": "FHIR RequestIntent supplies an evidenced authority gradient and ODRL supplies duty, consequence and remedy, which together separate what is merely intended from what is binding." }, { "dimension": "cost and earned value", "status": "not-applicable", "notes": "Deliberately excluded and delegated to a finance sibling model; only schedule variance is retained. GAO treats cost estimating as a separate body of guidance." }, { "dimension": "robotics and motion planning", "status": "not-applicable", "notes": "The registry records a robotics factor of zero for this model; trajectory and motion planning belong to a robotics model." }, { "dimension": "cross-jurisdiction retention law", "status": "gap", "notes": "Only one national records authority was fetchable in this pass. GDPR storage-limitation text could not be retrieved from EUR-Lex, so no European statutory retention basis is cited and the retention layer rests on a single jurisdiction plus generic policy structure." }, { "dimension": "hierarchical and constraint-based planning", "status": "gap", "notes": "Hierarchical task network decomposition and simple temporal networks with uncertainty are not modelled; only PDDL2.1 durative-action semantics are aligned. Agents doing hierarchical planning will need an extension." } ], "known_omissions": [ "Cost baselines, budgets and earned value management are excluded; ANSI/EIA-748 and ISO 21508 could not be fetched in this pass and are not cited.", "ISO catalogue pages, including the ISO 8601 parts and ISO 21502, returned HTTP 403 to the fetcher. ISO alignment is asserted only indirectly, through RFC 3339 which is an explicit profile of ISO 8601.", "The GAO ten best practices were confirmed from the GAO product page and indexed text of GAO-16-89G; the full PDF text was not machine-extracted, so individual practice wording should be verified against the source document before quotation.", "The exact NARA GRS 5.1 item number and disposition wording for calendars were not machine-extracted because the PDF returned as binary; only the coverage statement was confirmed from indexed text.", "Hierarchical task networks, simple temporal networks with uncertainty, and constraint-based temporal planning are out of scope.", "Capacity planning, shift rostering, labour-law working-time limits and collective agreement constraints are not modelled.", "Cron and systemd timer expressions are noted as further non-isomorphic recurrence grammars but are not mapped.", "Alarms, reminders and notification scheduling are treated as a projection concern and are not given their own finding.", "Non-Gregorian calendar systems are referenced through the OWL-Time temporal reference system concept but are not modelled in detail.", "RFC 7953 VAVAILABILITY working-availability components were not fetched and are not modelled beyond free-busy.", "VALARM and JSCalendar alerts are notification mechanics, not modelled as first-class findings.", "RFC 7529 non-Gregorian recurrence is represented only through JSCalendar rscale and skip, not as a standalone fetched source.", "PMBOK schedule-baseline and earned-value formulae were not used as primary text because the full PMI guides are paywalled and the PMI library fetch was blocked.", "ISO 21502 full text is paywalled; schedule-baseline language is catalogue-level alignment only.", "Critical-chain buffers, resource leveling, MRP and ISA-95 operations schedules lack primary support here.", "PDDL, HTN and other automated-planning operator models are omitted.", "Shift rostering, crew pairing, court and legislative calendars and military OPORD formats are omitted as specialised siblings.", "CalDAV, iMIP and JSCalendar sharing protocols are interfaces, not included as semantics." ], "conflicts": [ "Recurrence grammars are not isomorphic. iCalendar RRULE, FHIR Timing.repeat and schema.org Schedule express overlapping but non-equivalent patterns: by-set-position has no FHIR counterpart, and the FHIR 'when' and 'offset' pair has no iCalendar counterpart. Round-tripping is lossy in at least one direction and must be tested rather than assumed.", "RFC 3339 originally treated 'Z' as indicating that UTC is the preferred reference point; RFC 9557 redefines 'Z' as meaning the UTC time is known but the local offset is unknown. Implementations differ, so the zone must be carried explicitly rather than inferred from 'Z'.", "Storing future local times as UTC is stable under clock arithmetic but becomes wrong when a jurisdiction changes its offset or daylight-saving rule; storing local time with a zone identifier is correct but leaves the absolute instant undetermined until expansion. RFC 5545 permits all three forms and does not adjudicate between them.", "iTIP grants the Organizer sole write authority over the master object, whereas project scheduling practice assumes a scheduler-maintained integrated schedule fed by contributor updates. The two authority models must be reconciled explicitly in any deployment that spans both.", "FHIR RequestIntent treats 'plan' as an intention that does not authorize others to act, while an ODRL Agreement creates mutual obligation. Intent mode alone therefore never establishes a commitment, and the two must be modelled separately.", "PDDL2.1 annotates conditions and effects as at-start, over-all and at-end, which is finer-grained than a calendar component's start and end. Planner output cannot be represented losslessly as calendar entries.", "OWL-Time interval relations are qualitative while critical path dependencies with lag are quantitative and calendar-dependent. The 'meets' relation is not equivalent to a finish-to-start dependency with zero lag once a working calendar interrupts the timeline.", "GAO expects a maintained baseline with controlled change, while calendaring standards have no baseline concept at all and treat the current object as the only truth. The baseline layer is therefore supported by the public-authority source alone.", "iCalendar recurrence expansion is documented by RFC 8984 as ambiguous across implementations; JSCalendar restates the algorithm and is the preferred expansion profile when both apply.", "iCalendar SEQUENCE is an organizer revision counter and is not a named ISO or PMI schedule baseline.", "P-Plan isPreceededBy is transitive and untyped; RFC 9253 distinguishes four precedence types plus GAP. Treating them as identical is incorrect.", "FHIR CarePlan.intent proposal is not the same as iCalendar STATUS TENTATIVE.", "OWL-Time discusses leap seconds in ISO 8601; JSCalendar and iCalendar duration arithmetic MUST NOT consider leap seconds.", "iCalendar DTEND for DATE values is exclusive; some project-scheduling tools treat finish dates as inclusive.", "iCalendar default CLASS is PUBLIC; many enterprise calendars assume private. This model does not default to public.", "PROV Plan has no recurrence, free-busy or attendee model; calendar objects have no hadPlan association. Union is alignment, not a single type." ], "regional_assumptions": [ "Time zone rules follow the IANA database. Release 2026c alone records Alberta moving to a permanent -06 offset and Morocco to a permanent +00 offset, which invalidates previously computed future local times for those regions.", "The Gregorian calendar is assumed by default. Non-Gregorian calendars require an explicit temporal reference system, and iCalendar recurrence is defined on the Gregorian calendar only.", "Working calendars, public holidays and weekend definitions are locale-specific, including jurisdictions where the weekend is not Saturday and Sunday, and must be supplied rather than inferred.", "Week numbering and the first day of the week vary; by-week-number recurrence results change with the week-start setting, so it must be recorded rather than defaulted silently.", "The cited retention authority applies to United States federal records only. Other jurisdictions require their own records schedule, and no European statutory basis is cited in this pass.", "Business-hours and response-time assumptions embedded in commitments are jurisdiction and sector specific and must be stated explicitly in the commitment terms.", "Default calendar scale is Gregorian (iCalendar CALSCALE, JSCalendar rscale default).", "Default week start is Monday in JSCalendar firstDayOfWeek default mo; US deployments often use Sunday and MUST store WKST explicitly.", "Time zone interpretation assumes IANA TZDB regional rules, which change; stored zone identifiers must not be replaced by a single numeric offset.", "FHIR CarePlan R4 status and intent vocabularies are used; R5 differences are not modelled.", "Working weeks, holidays and prayer-time calendars are not assumed; they appear only if encoded as recurrence exceptions or free-busy." ], "adversarial_checks": [ "Tested the claim that a plan is just a set of calendar entries. Counterexample: a plan may fix goals, ordering and effort with no dates at all, and PROV treats a plan as a set of intended steps without temporal binding. The model therefore permits planned actions with no schedule entry, and temporal binding is a separate bundle rather than a required attribute.", "Tested the claim that one intention maps to one act. Counterexample: a recurring intention produces many acts, and one act can satisfy several intentions at once. Realization is therefore modelled as a many-to-many link set with a fulfilment degree, not as a status flag on the intention.", "Tested the claim that the latest update wins. Counterexample from iTIP: resolution is by identifier, then revision counter, then modification timestamp, so a message with a later timestamp but a lower counter must lose. The concurrency rules encode this order explicitly rather than relying on timestamp recency.", "Tested the claim that a date identifies an occurrence. Counterexample: after a daylight-saving transition or a detached override, two occurrences can share a local date, and an occurrence can be moved off its generating date entirely. Occurrence identity therefore uses the series identifier plus the recurrence identifier.", "Tested the claim that floating time is a defect to be normalized away. Both RFC 5545 and RFC 8984 retain it deliberately for wall-clock recurrences such as a daily alarm that should fire at the same local time wherever the user is. The canonicalization rules therefore preserve floating time rather than coercing it to an offset.", "Rejected a proposed 'Calendar' bundle. Calendars are containers and access surfaces served by protocols such as CalDAV and JMAP; they carry no intention semantics that the entry, disclosure and projection findings do not already carry, so adding the bundle would have imported interface concerns into a format-neutral model.", "Rejected a proposed 'Cost and earned value' layer. GAO treats cost estimating as separate guidance, and including it would have duplicated a finance sibling model. Only schedule variance is retained.", "Tested whether the commitment bundle duplicates an obligation or contract sibling. It retains only the binding of an intention to a named beneficiary, aligned to an ODRL Duty within an Agreement, and excludes contract formation, consideration and enforcement, so the overlap is a reference rather than a duplication.", "Tested whether 'baseline' could be reduced to an ordinary revision. It cannot: a revision is a point in a mutable history, whereas a baseline is an approved, digested, immutable comparison reference that survives re-planning. The two are modelled as distinct artifacts with different mutability rules.", "Checked that completed acts are not stored here and that correspondsToStep is a reference to the act sibling.", "Checked that standing process definitions and FHIR PlanDefinition remain out of scope.", "Checked that UID plus recurrence id is not collapsed into a date used as an identifier.", "Checked that SEQUENCE is not silently treated as a named baseline.", "Checked that free-busy projections cannot be used to reconstruct summary or attendee lists.", "Checked that resource CUTYPE rooms are participation classifications, not a duplicate resource model.", "Checked that ISO 21502 and PMI claims are marked secondary or omitted rather than presented as fetched normative text." ] }, "researchAdjudication": { "boundaryDecision": { "entry_kind": "aggregate", "status": "accepted", "rationale": "Both providers independently classify WM-ACT-008 as an aggregate and both draw the same composite root: a versioned statement of intention that owns its planned actions, schedule entries, recurrence sets, commitments and baselines, while referencing rather than owning agent identity, completed acts, standing process definitions, project governance and resource master data. Claude's boundary_notes additionally name the sibling world models (WM-ACT-006 Task, Act/Action, Process & Workflow, Project) with source-backed distinctions, so the aggregate envelope is fixed before any node is accepted. Calendar transport and sharing protocols are interface surfaces in both packs and stay out." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude as base", "rationale": "Claude draws boundaries against named sibling world models (Task, Act/Action, Process & Workflow, Project, calendar service, obligation model, tz reference data) with source refs per neighbour, and its out-of-scope list is decision-grade. Grok's boundary_notes are mostly non-conformance disclaimers about external standards, which fixes the model's relationship to specifications but not its edges against siblings. Size was not the deciding factor." }, { "concept": "Entry kind", "disposition": "aggregate, accepted", "rationale": "Both providers independently return aggregate and describe the same composite root owning planned actions, schedule entries, commitments and baselines while referencing siblings. No reclassification or split is warranted." }, { "concept": "iTIP scheduling methods and message sequencing", "disposition": "accepted as addition to l-participation-and-negotiation", "rationale": "Materially missing from base: method vocabulary, sender authorization per method, correlation-key ordering with out-of-order discard, and message-level security. Tier-1 evidence in RFC 5546 and RFC 8984; fits an existing layer without inventing one." }, { "concept": "Plan hierarchy and typed relationship integrity (RFC 9253)", "disposition": "accepted as scoped addition to l-dependency-and-constraint-network", "rationale": "Plan-to-plan composition and replacement, the RELTYPE/GAP/REFID carriage registry and dangling-link detection have no home in the base, and RFC 9253 is absent from the base source set. Admitted with an explicit deduplication instruction so precedence types and lag stay in f-ordering-dependency-and-lag." }, { "concept": "This-and-future split operation", "disposition": "accepted as fn-split-this-and-future", "rationale": "It creates a new master identity rather than patching one, which no base function performs; base only poses the override-range question. Backed by RFC 8984." }, { "concept": "Grok binding-commitment finding", "disposition": "rejected as duplicative", "rationale": "Base f-commitment-parties-and-terms plus f-remedy-consequence-and-release already carry parties, terms, basis, consequence and release with ODRL grounding, and delegation is covered by f-participant-role-and-response. Importing it would create a second place where commitment terms are asserted." }, { "concept": "Grok timezone-freebusy finding", "disposition": "rejected; DST-gap resolution rule deferred", "rationale": "Base splits the same material across f-time-zone-and-floating-time and the free/busy artifact under f-conflict-detection-and-rescheduling, and transparency is covered by q-availability-consumption. The one genuinely finer point, resolving a local time that falls inside a DST discontinuity by using the pre-transition offset, is a question-level nuance inside an existing finding, not a new node." }, { "concept": "Grok baseline-sequence finding", "disposition": "rejected as duplicative", "rationale": "Base f-baseline-snapshot-and-approval already covers scope, approval authority, currency and tamper-evidence, and both packs already record SEQUENCE-is-not-a-baseline as a conflict. The only unique operational content, the series split, is captured by the accepted function instead." }, { "concept": "Grok plan-status-intent finding", "disposition": "rejected as duplicative, status vocabulary folded", "rationale": "Base f-plan-type-and-intent-mode owns the authority gradient and carries art-intent-mode-value-set; non-terminal lifecycle status is reachable through f-plan-version-and-supersession and f-closure-and-abandonment. FHIR CarePlan.status codes belong in the existing value-set artifact, not a parallel finding." }, { "concept": "Grok organizer-attendee finding", "disposition": "rejected as duplicative", "rationale": "Base f-participant-role-and-response covers role, response state, reply expectation and delegation. CUTYPE room/resource classification and SENT-BY are attribute-level detail that belongs inside that finding rather than as a competing node." }, { "concept": "Resource assignment and contention", "disposition": "retained from base, scoped", "rationale": "Grok excludes resource catalogues and leveling outright; base keeps assignment, availability and over-allocation. Retained because assignment is a property of the intention, but scoped so no resource master data, skill catalogue or leveling algorithm enters the model, which reconciles the two packs without losing the contention question." }, { "concept": "PDDL2.1 alignment", "disposition": "retained as durative-action semantics only", "rationale": "Base cites PDDL2.1 for at-start, over-all and at-end condition semantics; grok excludes planner search, HTN methods and solver traces. Both are compatible: the alignment stays, automated planning machinery stays out, and the known lossiness against calendar start/end is already recorded as a conflict." }, { "concept": "Cost, budget and earned value", "disposition": "excluded, both packs agree", "rationale": "Base delegates to a finance sibling and grok lacks primary support; only schedule variance is retained. GAO treats cost estimating as separate guidance, so exclusion is source-consistent rather than a coverage gap." }, { "concept": "Calendar transport and sharing protocols", "disposition": "excluded; service/interface layers merged", "rationale": "CalDAV, iMIP, JMAP and iTIP bindings are interface surfaces in both packs. Disclosure class, projection level and message semantics are modelled; the serving protocol is not, consistent with merging service layers rather than admitting an interface bundle." }, { "concept": "ISO 21502 as a baseline authority", "disposition": "not imported", "rationale": "Grok's SRC-010 is flagged non-primary, paywalled and cited at catalogue level only. Importing it would attach a normative-looking citation to the baseline layer that the evidence pack cannot support; the base already grounds baselines on GAO plus PROV." }, { "concept": "Non-Gregorian calendar scale (rscale and skip)", "disposition": "deferred, not added", "rationale": "Grok reaches it only indirectly through JSCalendar and did not fetch RFC 7529; base lists it as a known omission behind the OWL-Time TRS concept. Neither pack has standalone evidence, so it goes to deferred research rather than into structure." } ], "publicationHolds": [ "Source and live-version verification is incomplete: every one of the 15 base sources plus the two newly imported grok sources (RFC 9253, P-Plan 1.1) must have its URL resolved and its version pin confirmed before publication, with particular attention to the IANA tz database release claim (2026c, 8 July 2026) and the schema.org Schedule entry, which is a live vocabulary pinned only by an access date.", "GAO-16-89G was confirmed from the product page and indexed text only; the full PDF was not machine-extracted. f-schedule-integrity-and-quality and the ten-best-practices framing must not be published with quoted or enumerated practice wording until verified against the source document.", "NARA GRS 5.1 item number and disposition wording were not machine-extracted because the PDF returned as binary. The retention questions may be published only as structure; no specific GRS item citation may be asserted until the wording is verified.", "Multi-profile validation is not complete. The merged model was exercised against calendaring, project-scheduling and care-intention profiles; it must also be validated against an autonomous software-agent planning profile and at least one non-US records-retention profile before release, since the retention layer currently rests on a single jurisdiction.", "ISO 21502 must not appear anywhere in the published draft as a normative baseline authority; it is paywalled and available at catalogue level only in the grok pack and was deliberately not imported as a source." ], "deferredResearch": [ "RFC 7529 (rscale and skip) as a fetched primary source for non-Gregorian recurrence, which both packs reach only indirectly through JSCalendar or the OWL-Time temporal reference system concept.", "RFC 7953 VAVAILABILITY against the base f-duration-effort-and-working-calendar finding, to determine whether availability components subsume, conflict with, or complement the working-calendar model; grok records it as an explicit omission.", "A non-US retention authority (EU storage-limitation text and at least one non-US national records schedule) to close the single-jurisdiction gap the base itself flags in its retention checklist.", "Hierarchical task network decomposition and simple temporal networks with uncertainty, to decide whether they are an extension point on f-planned-action-specification or a separate sibling model.", "ANSI/EIA-748 and ISO 21508 for the baseline and earned-value boundary, which both packs could only assert at catalogue level or exclude for lack of fetchable text.", "The iTIP organizer-sole-write model versus a scheduler-maintained integrated schedule fed by contributor updates: both authority models are recorded as a conflict but no reconciliation rule is evidenced, and the newly imported scheduling-message finding makes it operationally live." ] }, "statistics": { "sources": 23, "bundles": 6, "layers": 13, "findings": 32, "questions": 130, "artifacts": 31, "functions": 13 } }