# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-24T13:58:52Z", "synthesisSha256": "c40ee2cfdd3d412465f17c753ef83f9dd0f12bc6266f715f7d4925c8ca095bb1", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-REC-009", "registryId": "vr.wm-rec-009", "name": "Application / Request Record", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Information and virtual systems", "industry": [ "Cross-industry" ], "domain": [ "INF.REC.APP" ], "tags": [ "application", "request", "record", "inf.rec.app" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-rec-009-application-request-record/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-rec-009", "model": { "registry_id": "vr.wm-rec-009", "model_id": "WM-REC-009", "name": "Application / Request Record", "entry_kind": "entity", "purpose": "Provide the format-neutral context an agent needs to understand, create, inspect and operate a record of a request submitted by a party to a responsible body, from intent-to-submit through receipt, admissibility screening and handover into a case, service or fulfilment lifecycle.", "scope_statement": "The subject is the request-as-record: the identified, captured, evidentially reliable object created when a party asks a competent body to act (apply for authorisation, benefit, registration, court filing, information access, or a standard service request). Scope runs from the submission act to the disposition point at which a case is opened, the request is fulfilled, or the request is rejected/withdrawn/closed, plus the record's whole retention and disposal life. It covers identity, typing, parties and representation, declared content, evidence, completeness and validation, submission channel and receipt, integrity and non-repudiation, status and change, statutory clocks, routing, legal basis, fees, applicant rights, privacy, access, retention, exchange, provenance, measurement and exception handling. It deliberately excludes the substantive adjudication that follows.", "in_scope": [ "Identification, typing and classification of the request and its correlation identifiers across submitting, receiving and downstream systems", "Applicant, beneficiary, representative and delegation roles, and the identity-assurance context of the submission act", "Declared form content, attached and referenced evidence, and evidence retrieved from authoritative sources on the applicant's explicit request", "Completeness/admissibility screening, technical validation and deficiency notification", "Submission channel, receipt acknowledgement, and the distinct submission, receipt, registration and ingestion timestamps", "Signature, seal, fixity and capture of the request as an authentic, reliable record", "Request status model, amendment, supplementation, withdrawal and supersession", "Statutory and service time limits, tolling, extension, tacit-approval and estimated completion dates", "Routing to the competent body, processing track and priority, and handover into a case or fulfilment activity", "Legal basis and collection authority, fees and payment conditionality", "Applicant rights: reasons for rejection, redress routes, and data-subject rights over the request's personal data", "Access control, confidentiality, retention, disposition and legal hold over the request record", "Exchange packaging, standards alignment, provenance, performance measurement and exception handling" ], "out_of_scope": [ "Substantive adjudication, deliberation and the reasoning of the deciding body (WM-POL-017 Administrative case)", "The decision, authorisation, permit, benefit award or refusal issued as the case output (separate outcome-record model)", "Catalogue-level description of the public service itself: its requirements, channels, costs and outputs as published (CPSV-AP-aligned public-service model)", "Master data for natural persons and organisations beyond the roles they play in this request (party/agent model)", "Issuance, revocation and assurance-level certification of identity means and credentials (identity/trust-service model)", "Payment execution, settlement, refund and accounting (payment model)", "Content models and preservation of the evidence documents themselves beyond their reference, integrity and sufficiency (document/evidence record model)", "Generic record semantics inherited from the parent record model (WM-REC-007)", "Complaints, appeals and reviews against a decision, which are distinct triggering records", "Incidents and unplanned service interruptions, which are a different trigger class from standard service requests", "Case workload planning, resourcing and staff performance management" ], "boundary_notes": [ { "neighbor": "WM-REC-007 (parent record model)", "distinction": "This model specialises the generic record; it does not restate base record semantics. The record characteristics of authenticity, reliability, integrity and usability, and the general metadata/entity framework, are inherited rather than redefined here.", "source_refs": [ "SRC-014", "SRC-013" ] }, { "neighbor": "WM-POL-017 (Administrative case)", "distinction": "The application is the trigger and the durable evidence that a request was made; the case is the proceeding it opens. The boundary is the disposition event: once a case reference exists, case-internal steps, deliberation and outcome belong to WM-POL-017. A request may also close without ever opening a case.", "source_refs": [ "SRC-018", "SRC-006", "SRC-003" ] }, { "neighbor": "Public service description (CPSV-AP)", "distinction": "CPSV-AP models the service, its Requirements, Evidence types, Channels, Costs, Rules and Outputs at catalogue level. This model instantiates them for one concrete request; it must not duplicate the catalogue definitions but must cite them.", "source_refs": [ "SRC-001" ] }, { "neighbor": "Outcome / decision record", "distinction": "Grant, refusal, authorisation or fulfilment result is a separate record with its own identity, effective dates and appeal window. This model holds only the reference and the disposition code.", "source_refs": [ "SRC-003", "SRC-001" ] }, { "neighbor": "Incident record (service management)", "distinction": "A service request is a pre-defined, pre-approved ask for a standard service; an incident is an unplanned interruption or quality reduction. Standards treat them as separate resolution flows and they must not share one lifecycle model.", "source_refs": [ "SRC-004", "SRC-005" ] }, { "neighbor": "Evidence / attachment document record", "distinction": "Attachments are referenced entities with their own identity, integrity and retention. This model records what evidence a requirement demands, whether it was supplied or fetched, and whether it was judged sufficient, not the document's internal content model.", "source_refs": [ "SRC-001", "SRC-017", "SRC-002" ] }, { "neighbor": "Identity and trust-service model", "distinction": "Assurance levels, credential issuance and trust lists are governed elsewhere. This model records only the authentication context asserted at submission time and its evidential weight.", "source_refs": [ "SRC-002", "SRC-017" ] }, { "neighbor": "Data-subject rights request (privacy request)", "distinction": "A right-of-access or erasure request is itself an instance of this model, but the controller's substantive compliance workflow and the rights framework belong to a privacy-governance model. Only the request-handling surface is modelled here.", "source_refs": [ "SRC-010", "SRC-011" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Core Public Service Vocabulary Application Profile (CPSV-AP) 3.2.0", "organization": "SEMIC / European Commission", "url": "https://semiceu.github.io/CPSV-AP/releases/3.2.0/", "version_or_date": "3.2.0, released 2024-05-06", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:05:00Z", "relevance": "Normative EU application profile defining Public Service, Requirement, Evidence, Channel, Cost, Rule, Output, Participation, Agent and Event. Supplies the catalogue-side vocabulary that an individual request instantiates, and fixes the Evidence-proves-Requirement relation used for completeness screening." }, { "id": "SRC-002", "title": "Regulation (EU) 2018/1724 establishing a single digital gateway", "organization": "European Union (text as published by The National Archives, legislation.gov.uk)", "url": "https://www.legislation.gov.uk/eur/2018/1724/contents", "version_or_date": "Regulation of 2 October 2018; consolidated text accessed 2026-08-24", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:07:00Z", "relevance": "Article 6 (procedures to be offered fully online), Article 13 (cross-border access to online procedures) and Article 14 (technical system for cross-border automated exchange of evidence and the once-only principle, including explicit request and preview) ground the online-submission, evidence-sourcing and cross-border findings. Caveat: this is a national mirror of the EU act, not the OJ original." }, { "id": "SRC-003", "title": "Directive 2006/123/EC on services in the internal market, Article 13 (Authorisation procedures)", "organization": "European Union (text as published by The National Archives, legislation.gov.uk)", "url": "https://www.legislation.gov.uk/eudr/2006/123/article/13", "version_or_date": "Directive of 12 December 2006; Article 13 text accessed 2026-08-24", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:09:00Z", "relevance": "The strongest normative source for application-handling duties: prompt acknowledgement of receipt stating the processing period, available means of redress and any tacit-authorisation effect; fixed and pre-published time limits with one justified extension; prompt notification of missing documents and of any effect on the clock; prompt reasoned rejection. Caveat: national mirror text." }, { "id": "SRC-004", "title": "FHIR ServiceRequest resource, FHIR Release 5", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/servicerequest.html", "version_or_date": "FHIR v5.0.0 (R5), accessed 2026-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:11:00Z", "relevance": "A mature, independently governed model of 'a record of a request for service': identifier assigned by orderer/receiver/fulfiller, status, intent (proposal|plan|directive|order), priority, category, code, subject, requester, performer, occurrence, authoredOn, supportingInfo. Validates separating request identity, intent and status, and separating requester from beneficiary." }, { "id": "SRC-005", "title": "FHIR Task resource, FHIR Release 5", "organization": "HL7 International", "url": "https://hl7.org/fhir/R5/task.html", "version_or_date": "FHIR v5.0.0 (R5), accessed 2026-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:12:00Z", "relevance": "Supplies an evidenced request-fulfilment state set (draft, requested, received, accepted, rejected, ready, cancelled, in-progress, on-hold, failed, completed, entered-in-error), the distinction between technical status and businessStatus, statusReason, restriction, input and output. Directly grounds the status model and the entered-in-error correction path." }, { "id": "SRC-006", "title": "Electronic Court Filing Version 5.0, Committee Specification 01", "organization": "OASIS LegalXML Electronic Court Filing TC", "url": "https://docs.oasis-open.org/legalxml-courtfiling/ecf/v5.0/ecf-v5.0.html", "version_or_date": "Committee Specification 01, 18 April 2019", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:14:00Z", "relevance": "A concrete, normative submission-intake specification: FilingMessage with lead and connected documents, ReviewFiling then accepted/rejected clerk review, RecordDocketing and NotifyDocketingComplete, a persistent filing tracking identifier usable for status query after docketing, filer and participant roles, and optional payment messages. Grounds receipt, review, routing and handover findings." }, { "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-24T09:16:00Z", "relevance": "Entity/Activity/Agent with wasGeneratedBy, wasDerivedFrom, wasAttributedTo, wasAssociatedWith, actedOnBehalfOf, startedAtTime, endedAtTime and the qualified pattern (Generation, Derivation, Delegation, Bundle). Grounds chain-of-custody, representation-as-delegation and supersession-as-derivation without inventing bespoke provenance vocabulary." }, { "id": "SRC-008", "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": "Proposed Standard, July 2002 (updated by RFC 9557)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:18:00Z", "relevance": "Mandates a full date-time with seconds and an explicit UTC offset ('Z' or +hh:mm), giving a sortable, unambiguous timestamp form. Normative basis for the model's timestamp rule and for distinguishing submission, receipt, registration and ingestion instants across time zones." }, { "id": "SRC-009", "title": "RFC 9562: Universally Unique IDentifiers (UUIDs)", "organization": "Internet Engineering Task Force (IETF)", "url": "https://www.rfc-editor.org/rfc/rfc9562.html", "version_or_date": "Standards Track, May 2024 (obsoletes RFC 4122)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:19:00Z", "relevance": "Defines UUIDv4 and the time-ordered UUIDv7, states that global uniqueness cannot be guaranteed without a shared scheme, and cautions against name-based identifiers as primary keys in favour of time-based surrogate keys. Supports the third tier of the identity priority rule." }, { "id": "SRC-010", "title": "Guidelines 01/2022 on data subject rights - Right of access, Version 2.1", "organization": "European Data Protection Board (EDPB)", "url": "https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en", "version_or_date": "Version 2.1, adopted 17 April 2023", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:21:00Z", "relevance": "Authoritative interpretation that a request needs no particular form or channel, that requester identification must be proportionate and not a barrier, and that the one-month deadline runs from receipt with a conditional two-month extension. Grounds the channel-neutrality, identification-proportionality and clock findings for rights-based requests." }, { "id": "SRC-011", "title": "Regulation (EU) 2016/679 (GDPR) Article 12 as assimilated in UK law", "organization": "The National Archives (legislation.gov.uk)", "url": "https://www.legislation.gov.uk/eur/2016/679/article/12", "version_or_date": "Assimilated text accessed 2026-08-24, reflecting UK amendments in force", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:22:00Z", "relevance": "Transparency and request-handling modalities: response without undue delay, electronic reply when the request was electronic, reasonable fee or refusal only for manifestly unfounded or excessive requests with the burden on the controller, and additional identifying information where identity is reasonably doubted. Recorded as a UK-divergent variant, not as the EU text." }, { "id": "SRC-012", "title": "5 U.S. Code § 552 - Public information; agency rules, opinions, orders, records, and proceedings", "organization": "Cornell Law School Legal Information Institute (publishing the United States Code)", "url": "https://www.law.cornell.edu/uscode/text/5/552", "version_or_date": "Current US Code text accessed 2026-08-24", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-24T09:24:00Z", "relevance": "A counterexample jurisdiction with explicit intake mechanics: 20-working-day determination running from receipt by the proper component (no later than ten days after initial receipt), tolling only to seek clarification or resolve fees, a ten-working-day unusual-circumstances extension with expected completion date, expedited processing decided within ten days, and a statutory duty to assign an individualised tracking number for requests taking longer than ten days plus status and estimated completion date. Used as secondary because LII republishes rather than promulgates." }, { "id": "SRC-013", "title": "ISO 23081-2:2021 Information and documentation - Metadata for managing records - Part 2: Conceptual and implementation issues", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/81600.html", "version_or_date": "Edition 2, published August 2021", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:26:00Z", "relevance": "Framework for records metadata built on the record / agent / business / mandate / relationship entity view, aimed at standardised description of records and their contextual entities, fixed points of aggregation for interoperability, and reuse of metadata over time and across applications. Grounds the separation of request metadata from party, mandate and process metadata. Caveat: normative text is paywalled; only the public abstract and scope were read." }, { "id": "SRC-014", "title": "ISO 15489-1:2016 Information and documentation - Records management - Part 1: Concepts and principles", "organization": "International Organization for Standardization (ISO)", "url": "https://www.iso.org/standard/62542.html", "version_or_date": "Edition 2, published April 2016", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:27:00Z", "relevance": "Establishes that records are authoritative evidence of business only while they retain authenticity, reliability, integrity and usability, and frames appraisal, records controls and the create/capture/control processes. Grounds capture, fixity, disposition-authority and usability requirements. Caveat: the ISO catalogue page returned HTTP 403 to automated retrieval and the normative text is paywalled; only the widely republished characteristic set and scope are relied on." }, { "id": "SRC-015", "title": "MoReq2010 Modular Requirements for Records Systems", "organization": "DLM Forum Foundation", "url": "https://moreq.info/", "version_or_date": "MoReq2010 v1.1, launched May 2011; site accessed 2026-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:29:00Z", "relevance": "Service-based records-system specification in which every entity carries metadata, an event history and an access control list, records sit in aggregations, and retention rules are inherited from a classification. Grounds the event-history, access-control-list and disposition-scheduling findings as system-independent requirements rather than product features." }, { "id": "SRC-016", "title": "NIEMOpen - National Information Exchange Model", "organization": "OASIS Open Project (NIEMOpen); sponsors include DHS S&T and FBI CJIS", "url": "https://niemopen.org/", "version_or_date": "NIEM 6 current generation; site accessed 2026-08-24", "source_type": "standard", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:31:00Z", "relevance": "A governed common vocabulary with domain content, Message Exchange Packages, Naming and Design Rules and multiple serialisations (XML, JSON). Evidence that exchange packaging and naming rules are a distinct concern from the semantic record, supporting the format-neutrality principle." }, { "id": "SRC-017", "title": "Verifiable Credentials Data Model v2.0", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vc-data-model-2.0/", "version_or_date": "W3C Recommendation, 15 May 2025", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:33:00Z", "relevance": "issuer, credentialSubject, validFrom/validUntil, credentialStatus, credentialSchema, evidence and proof, plus verifiable presentations supporting selective disclosure. Grounds evidence provenance, validity windows, revocation checking at the time of reliance, and data-minimising evidence attachment." }, { "id": "SRC-018", "title": "Case Management Model and Notation (CMMN) Version 1.1", "organization": "Object Management Group (OMG)", "url": "https://www.omg.org/spec/CMMN/1.1/About-CMMN", "version_or_date": "Version 1.1, formally adopted December 2016", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:35:00Z", "relevance": "A common meta-model and notation for modelling a Case and exchanging Case models. Defines the neighbouring concept precisely enough to fix the boundary between the triggering request record and the case it opens, and shows that case content is modelled separately from the intake artefact." }, { "id": "SRC-019", "title": "GOV.UK Service Manual - Service Standard", "organization": "Government Digital Service, UK Government", "url": "https://www.gov.uk/service-manual/service-standard", "version_or_date": "14-point standard, accessed 2026-08-24", "source_type": "public-authority", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:37:00Z", "relevance": "Public-authority requirements that shape request intake: solve a whole problem, provide a joined-up experience across all channels, make sure everyone can use the service, protect users' privacy, define what success looks like and publish performance data, and use open standards and common patterns. Grounds the channel-equity and performance-measurement findings." }, { "id": "SRC-020", "title": "Core Criterion and Core Evidence Vocabulary (CCCEV) 2.1.0", "organization": "European Commission SEMIC", "url": "https://semiceu.github.io/CCCEV/releases/2.1.0/", "version_or_date": "2.1.0 (SEMIC Recommendation 2024-05-06)", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:12:00Z", "relevance": "Defines Requirement, Criterion, Constraint, Evidence, Evidence Type, agents that create/issue/provide evidence, confidentiality, validity period and supported values used to assess an application." }, { "id": "SRC-021", "title": "HL7 FHIR R5 Resource ServiceRequest", "organization": "HL7 International", "url": "https://www.hl7.org/fhir/servicerequest.html", "version_or_date": "FHIR R5 5.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:15:00Z", "relevance": "Normative healthcare and general service-request instance: identifiers, requisition, status, intent, priority, code, subject, authoredOn, requester, performer, reason, supporting information, replacement and grouping." }, { "id": "SRC-022", "title": "HL7 FHIR R5 Request pattern", "organization": "HL7 International", "url": "https://www.hl7.org/fhir/request.html", "version_or_date": "FHIR R5 5.0.0", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:18:00Z", "relevance": "Cross-resource request pattern distinguishing proposal/plan/order, authorisation status versus fulfilment, occurrence, reported-versus-primary, insurance, deliver-to and do-not-perform." }, { "id": "SRC-023", "title": "ISO 15489-1:2016 Information and documentation — Records management — Part 1: Concepts and principles", "organization": "ISO/TC 46/SC 11", "url": "https://committee.iso.org/sites/tc46sc11/home/projects/published/iso-15489-records-management.html", "version_or_date": "ISO 15489-1:2016", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:25:00Z", "relevance": "Global records-management principles for creating, capturing and managing records in any format, including metadata, assigned responsibilities, business context and processes that make an application evidential." }, { "id": "SRC-024", "title": "Case Management Model and Notation (CMMN) Version 1.1", "organization": "Object Management Group", "url": "https://www.omg.org/spec/CMMN/1.1/PDF", "version_or_date": "formal/2016-12-01", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:30:00Z", "relevance": "Defines Case, CaseFile, CaseFileItem, roles, case inputs/outputs and CaseFileItem lifecycle, the case-side composition of an application entering a case." }, { "id": "SRC-025", "title": "Regulation (EU) 2016/679 Article 5 — Principles relating to processing of personal data", "organization": "European Union", "url": "https://gdpr-info.eu/art-5-gdpr/", "version_or_date": "Regulation (EU) 2016/679, Article 5 (consolidated article text)", "source_type": "legislation", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T14:35:00Z", "relevance": "Lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity/confidentiality and accountability for personal data typically present on applications." }, { "id": "SRC-026", "title": "Regulation (EU) 2018/1724 Article 14 — Technical system for the cross-border automated exchange of evidence and application of the once-only principle", "organization": "European Union / legislation.gov.uk", "url": "https://www.legislation.gov.uk/eur/2018/1724/article/14", "version_or_date": "Regulation (EU) 2018/1724 of 2 October 2018; Article 14 (legislation.gov.uk record modified 2024-10-03)", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:32:00Z", "relevance": "Once-only principle and cross-border automated evidence exchange for procedures accessed through the Single Digital Gateway, affecting how applications obtain evidence without re-collection." }, { "id": "SRC-027", "title": "ISO 23081 Metadata for records", "organization": "ISO/TC 46/SC 11", "url": "https://committee.iso.org/sites/tc46sc11/home/projects/published/iso-23081-metadata-for-records.html", "version_or_date": "ISO 23081 series (Part 1:2017 framework)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T14:08:00Z", "relevance": "Metadata framework for authenticity, reliability, integrity and usability of records, and for telling who did what to which digital object across the application record's life." } ], "structure": { "bundles": [ { "id": "identity-and-actors", "name": "Request Identity, Typing and Actors", "description": "Establishes what a single request is, how it is named and classified, and which parties stand behind it and with what identity assurance.", "rationale": "Every downstream operation - deduplication, routing, clock computation, access control, disposal - depends on a stable answer to 'which request is this and whose is it'. Independently governed request models all begin with an identifier, a type/code and a requester distinct from the subject, so this concern is separated first.", "source_refs": [ "SRC-004", "SRC-006", "SRC-013", "SRC-001" ], "layers": [ { "id": "request-identity", "name": "Identity and Classification", "description": "Identifiers, naming authority, correlation across systems, and the typing/classification that determines which rules apply.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009", "SRC-001" ], "findings": [ { "id": "request-identifier-set", "name": "Request identifier set and naming authority", "description": "A request typically carries several identifiers at once: one assigned by the submitter, one assigned by the receiving body at registration, and internal surrogate keys. Which one is authoritative, when each is minted, and how they correlate must be explicit.", "source_refs": [ "SRC-004", "SRC-006", "SRC-009", "SRC-012" ], "questions": [ { "id": "rid-q1", "text": "Which identifier is the authoritative public reference for this request, which body minted it, and at which lifecycle event was it minted?", "kind": "identity", "answer_data": [ "Authoritative identifier value", "Issuing authority reference", "Minting event type (submission, receipt, registration)", "Minting timestamp" ] }, { "id": "rid-q2", "text": "Which additional identifiers exist for the same request, and what is the declared equivalence relation between them?", "kind": "interoperability", "answer_data": [ "Identifier collection with scheme, issuer and role", "Equivalence assertion type (same-as, correlates-with, supersedes)", "Scope of validity per identifier" ] }, { "id": "rid-q3", "text": "Is a tracking reference disclosed to the requester, and by when is disclosure required?", "kind": "requirement", "answer_data": [ "Tracking reference value", "Disclosure obligation flag and trigger condition", "Disclosure timestamp", "Status-lookup endpoint or channel reference" ] }, { "id": "rid-q4", "text": "How are duplicate submissions of the same underlying request detected and reconciled without destroying either record?", "kind": "validation", "answer_data": [ "Duplicate-detection key or fingerprint", "Duplicate relation link", "Reconciliation outcome code", "Retained-original reference" ] } ], "data_elements": [ { "id": "de-authoritative-request-id", "name": "Authoritative request identifier", "description": "The identifier assigned by the master system of record for this request, used as the public reference.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-012" ] }, { "id": "de-alternate-identifiers", "name": "Alternate identifiers", "description": "Submitter reference, channel transaction id, internal surrogate key and any partner-system identifiers, each with scheme and issuer.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-004", "SRC-009" ] }, { "id": "de-duplicate-of", "name": "Duplicate-of reference", "description": "Link to a prior request judged to be the same underlying ask.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004" ] } ], "artifacts": [], "inline_only_rationale": "Identifiers are inline scalar values on the request record and pointers into externally governed identifier schemes. No separate stored artefact exists; producing one would create a second place where identity could drift from the master system." }, { "id": "request-typing-and-classification", "name": "Request type, procedure binding and classification", "description": "The request must be bound to the specific procedure or service being requested, because the applicable evidence requirements, time limits, fees and competent authority all derive from that binding rather than from the request itself.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006" ], "questions": [ { "id": "rtc-q1", "text": "Which published service or procedure, at which version, does this request instantiate?", "kind": "classification", "answer_data": [ "Public service or procedure reference", "Catalogue version or effective date", "Jurisdiction or territorial scope", "Legal resource reference" ] }, { "id": "rtc-q2", "text": "What request intent does this record express - a proposal, a plan, or an actionable order to the receiving body?", "kind": "definition", "answer_data": [ "Intent code", "Intent code system reference", "Actionability flag" ] }, { "id": "rtc-q3", "text": "Which classification schemes are applied to the request, and which of them are normative for processing rather than merely descriptive?", "kind": "classification", "answer_data": [ "Classification code with scheme identifier", "Normative-versus-descriptive marker", "Classification assignment agent and timestamp" ] }, { "id": "rtc-q4", "text": "If the catalogue definition changes after submission, does the request remain governed by the version in force at submission?", "kind": "temporal", "answer_data": [ "Version-pinning policy code", "Catalogue version in force at submission", "Re-binding event record if re-pinned" ] } ], "data_elements": [ { "id": "de-procedure-reference", "name": "Procedure or service reference", "description": "Reference to the catalogue entry describing the requested service, including its version.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-request-intent", "name": "Request intent", "description": "Degree of actionability the requester attaches to the request.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-004" ] }, { "id": "de-request-category", "name": "Request category codes", "description": "Coded classifications applied for routing, statistics or legal treatment.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-016" ] } ], "artifacts": [], "inline_only_rationale": "Typing is a set of coded references into externally maintained catalogues and code lists. The catalogue entry itself is an artefact of the sibling public-service model; duplicating it here would fork the authoritative definition." }, { "id": "triggering-event-and-request-reason", "name": "Triggering event and stated reason", "description": "An Event (typically a Life Event or Business Event) relates a citizen or business situation to public services. FHIR independently records why the service is needed. The application should capture both the catalogue event hook and instance-level reasons.", "source_refs": [ "SRC-001", "SRC-021", "SRC-022" ], "questions": [ { "id": "triggering-event-and-request-reason-q01", "text": "Which life or business event triggered this application, and what is that event's identifier and name?", "kind": "event", "answer_data": [ "event identifier", "event name", "event type from controlled vocabulary", "related public service identifiers" ] }, { "id": "triggering-event-and-request-reason-q02", "text": "Why is the service needed or prohibited for this subject, in coded and/or narrative form?", "kind": "classification", "answer_data": [ "reason codeable references", "narrative reason", "supporting condition or observation references" ] }, { "id": "triggering-event-and-request-reason-q03", "text": "Does the instance reason align with the catalogue event that the Public Service is related to, or is this an atypical use?", "kind": "validation", "answer_data": [ "alignment boolean", "exception justification", "overriding legal basis" ] } ], "data_elements": [ { "id": "triggering-event-and-request-reason-data01", "name": "Triggering event", "description": "Life Event or Business Event related to the Public Service.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "triggering-event-and-request-reason-data02", "name": "Event type", "description": "Controlled vocabulary type of the event, for example the EU Business event NAL.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "triggering-event-and-request-reason-data03", "name": "Request reason", "description": "Coded or referenced justification for why the service is (not) needed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-022", "SRC-021" ] } ], "artifacts": [], "inline_only_rationale": "Events and reasons are references and codes on the application; underlying vital-event or business-registry proofs are evidence artefacts." } ] }, { "id": "request-actors", "name": "Parties, Representation and Identity Assurance", "description": "Who submits, who benefits, who is authorised to act for whom, and how strongly the submitter was identified.", "source_refs": [ "SRC-004", "SRC-007", "SRC-002", "SRC-010" ], "findings": [ { "id": "parties-roles-and-representation", "name": "Parties, roles and authority to act", "description": "The submitter, the beneficiary and the legally responsible party are frequently different, and third-party submission requires an evidenced mandate. Conflating them produces wrong notifications, wrong appeal rights and wrong privacy treatment.", "source_refs": [ "SRC-004", "SRC-007", "SRC-001", "SRC-006" ], "questions": [ { "id": "prr-q1", "text": "Who is the beneficiary or subject of the request, and is that party distinct from the submitter?", "kind": "relationship", "answer_data": [ "Subject party reference", "Submitter party reference", "Distinctness flag", "Role code per party" ] }, { "id": "prr-q2", "text": "Where a representative acts, what is the evidenced basis and scope of that mandate, and when does it expire?", "kind": "authority", "answer_data": [ "Mandate evidence reference", "Mandate scope description", "Mandate validity period start and end", "Delegation chain (acted-on-behalf-of)" ] }, { "id": "prr-q3", "text": "Which party carries legal responsibility for the truth of the declarations, and which party receives official notifications?", "kind": "ownership", "answer_data": [ "Responsible party reference", "Notification address or channel per party", "Liability declaration flag" ] }, { "id": "prr-q4", "text": "How are role changes during processing - change of representative, death, insolvency, transfer of the underlying interest - recorded without rewriting history?", "kind": "lifecycle", "answer_data": [ "Role assignment period", "Superseding role assignment reference", "Change event record with reason code" ] } ], "data_elements": [ { "id": "de-party-role-assignment", "name": "Party role assignment", "description": "A time-bounded association of a party to the request in a named role (submitter, subject, representative, payer, notified party).", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-004", "SRC-001" ] }, { "id": "de-mandate-reference", "name": "Mandate or power-of-attorney reference", "description": "Pointer to the evidence authorising a representative to act, with scope and validity window.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-017" ] }, { "id": "de-notification-target", "name": "Notification target", "description": "The address or channel to which official communications about this request must be sent.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "mandate-evidence-artifact", "name": "Mandate / authority-to-act evidence", "description": "The document or credential establishing that a representative may submit and act on the request, together with its scope and validity window.", "media_or_form": [ "signed document", "verifiable credential", "registry extract", "structured mandate assertion" ], "serial": false, "identity_strategy": "Use the issuing registry's mandate identifier where one exists; otherwise the credential identifier; otherwise a UUID assigned at capture, always paired with the issuer reference and validity period.", "source_refs": [ "SRC-017", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "identity-assurance-and-authentication", "name": "Identity assurance context of the submission act", "description": "The evidential weight of a request depends on how the submitter was identified at the moment of submission. Assurance must be recorded as an observed fact about that act, not inferred later from the account that holds the record.", "source_refs": [ "SRC-002", "SRC-010", "SRC-017", "SRC-014" ], "questions": [ { "id": "iaa-q1", "text": "By what means was the submitter authenticated at submission, and at what assurance level?", "kind": "evidence", "answer_data": [ "Authentication method code", "Assurance level code and scheme", "Authenticating provider reference", "Authentication timestamp" ] }, { "id": "iaa-q2", "text": "Which asserted attributes were verified against an authoritative source, and which remain self-declared?", "kind": "quality", "answer_data": [ "Attribute name", "Verification status code", "Verifying source reference", "Verification timestamp" ] }, { "id": "iaa-q3", "text": "If identity could not be established to the required level, what proportionate additional identification was requested, and did the clock stop?", "kind": "exception", "answer_data": [ "Identification-gap reason code", "Additional identification requested description", "Clock-effect flag", "Resolution outcome and timestamp" ] }, { "id": "iaa-q4", "text": "Is anonymous or pseudonymous submission permitted for this procedure, and what limits does that place on the outcome?", "kind": "constraint", "answer_data": [ "Anonymity permission flag", "Permitted pseudonymity mode", "Outcome limitation description" ] } ], "data_elements": [ { "id": "de-authentication-context", "name": "Authentication context", "description": "Method, provider, assurance level and timestamp of the authentication that accompanied the submission act.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-017" ] }, { "id": "de-attribute-verification-status", "name": "Attribute verification status", "description": "Per-attribute record of whether a declared value was verified, by whom and when.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-010" ] } ], "artifacts": [ { "id": "authentication-assertion-artifact", "name": "Authentication / identity assertion record", "description": "The retained assertion evidencing how the submitter was identified at submission time, sufficient to reconstruct assurance later without re-contacting the identity provider.", "media_or_form": [ "signed assertion", "verifiable presentation", "authentication event log entry" ], "serial": false, "identity_strategy": "Use the assertion identifier issued by the identity provider; where absent, a UUID assigned at capture bound to the request identifier and the RFC 3339 authentication instant.", "source_refs": [ "SRC-017", "SRC-002", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "reported-capture-and-participation-roles", "name": "Requester, representative and reporter", "description": "Who/what is requesting the service may differ from the subject (practitioner, organisation, related person, device). A representative participation role and a reported-versus-primary flag record third-party or secondary capture.", "source_refs": [ "SRC-022", "SRC-021", "SRC-001" ], "questions": [ { "id": "reported-capture-and-participation-roles-q01", "text": "Who or what is requesting the service, and in what capacity relative to the subject?", "kind": "authority", "answer_data": [ "requester reference", "requester type", "capacity or mandate code", "mandate instrument reference" ] }, { "id": "reported-capture-and-participation-roles-q02", "text": "Which participation roles are recorded (competent authority, service user, provider, representative) and who fills each?", "kind": "relationship", "answer_data": [ "participation identifier", "role code", "participant agent", "role vocabulary" ] }, { "id": "reported-capture-and-participation-roles-q03", "text": "Is this application a reported rather than primary record, and who reported it?", "kind": "provenance", "answer_data": [ "reported boolean", "reported-by agent reference", "capture channel implying secondary entry" ] } ], "data_elements": [ { "id": "reported-capture-and-participation-roles-data01", "name": "Requester", "description": "Who or what is requesting the service.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022", "SRC-021" ] }, { "id": "reported-capture-and-participation-roles-data02", "name": "Participation", "description": "Role-bearing participation of an agent in the application or its public service.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "reported-capture-and-participation-roles-data03", "name": "Reported rather than primary", "description": "Indicates secondary or reported capture of the request.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] }, { "id": "reported-capture-and-participation-roles-data04", "name": "Reported by", "description": "Agent who reported the request if not the primary recorder.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-022" ] } ], "artifacts": [ { "id": "reported-capture-and-participation-roles-artifact01", "name": "Mandate or representation instrument", "description": "Power of attorney, parental authority, professional mandate or similar instrument authorising a requester to file for a subject.", "media_or_form": [ "power of attorney", "mandate form", "court appointment order" ], "serial": true, "identity_strategy": "Authoritative instrument identifier from the issuing authority; else governed IRI; else Dimension UUID linked to the application identifier.", "source_refs": [ "SRC-001", "SRC-023" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "content-and-evidence", "name": "Declared Content, Evidence and Validation", "description": "What the requester actually asserted, what proof was attached or fetched, and whether the package is technically valid and legally admissible.", "rationale": "Application profiles model Evidence as proof that a Requirement is met, and intake specifications separate technical conformance from substantive review. Keeping declared content, evidence sufficiency and validation distinct prevents a schema error from being mistaken for an inadmissible application.", "source_refs": [ "SRC-001", "SRC-006", "SRC-002", "SRC-003" ], "layers": [ { "id": "declared-content", "name": "Declared Content and Evidence", "description": "The form instance, its attachments, and evidence obtained from authoritative sources instead of the applicant.", "source_refs": [ "SRC-001", "SRC-002", "SRC-017", "SRC-006" ], "findings": [ { "id": "form-instance-and-declared-data", "name": "Form definition, instance and declarations", "description": "A request instantiates a versioned form or payload definition. The definition and the instance are separate objects with separate lifecycles, and the definition in force at submission must remain retrievable for as long as the instance is kept.", "source_refs": [ "SRC-006", "SRC-001", "SRC-014", "SRC-016" ], "questions": [ { "id": "fid-q1", "text": "Which form or payload definition, at which version, does this instance conform to, and is that definition still retrievable?", "kind": "provenance", "answer_data": [ "Form definition reference", "Definition version identifier", "Definition effective period", "Retrievability status" ] }, { "id": "fid-q2", "text": "Which declarations, attestations or consents did the requester make, and what is the legal effect of each?", "kind": "requirement", "answer_data": [ "Declaration text reference", "Declaration acceptance flag", "Acceptance timestamp", "Legal effect description" ] }, { "id": "fid-q3", "text": "In which language was the request submitted, and does the procedure require translation or a specific official language?", "kind": "constraint", "answer_data": [ "Submission language code", "Required language codes", "Translation obligation flag", "Translation reference" ] }, { "id": "fid-q4", "text": "Which declared values are free text and which are bound to controlled vocabularies, and how are unbound values handled downstream?", "kind": "interoperability", "answer_data": [ "Field binding type", "Code system reference per bound field", "Unbound-value handling rule" ] } ], "data_elements": [ { "id": "de-form-definition-ref", "name": "Form definition reference", "description": "Versioned pointer to the definition the submitted payload conforms to.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "de-declared-payload", "name": "Declared payload", "description": "The structured set of values asserted by the requester, independent of any serialisation.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-006", "SRC-001" ] }, { "id": "de-declaration-acceptance", "name": "Declaration acceptance", "description": "Record of each attestation or consent accepted, with timestamp.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-002" ] }, { "id": "de-submission-language", "name": "Submission language", "description": "Language in which the request was made.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "submitted-payload-artifact", "name": "Submitted request payload as filed", "description": "The immutable as-filed content of the request, retained separately from any later working copy so that what was actually submitted can always be reproduced.", "media_or_form": [ "structured payload", "completed form document", "rendered human-readable view" ], "serial": false, "identity_strategy": "Identified by the authoritative request identifier plus a version ordinal; each amendment produces a new immutable instance rather than mutating the prior one.", "source_refs": [ "SRC-014", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "evidence-requirements-and-attachments", "name": "Evidence requirements, attachments and sufficiency", "description": "Evidence is proof that a stated requirement is met. The model must record which requirement each item of evidence discharges, not merely that files were attached, otherwise sufficiency cannot be assessed or re-assessed.", "source_refs": [ "SRC-001", "SRC-006", "SRC-017", "SRC-014" ], "questions": [ { "id": "era-q1", "text": "Which requirement does each supplied evidence item discharge, and are any mandatory requirements still undischarged?", "kind": "composition", "answer_data": [ "Requirement reference", "Evidence item reference", "Discharge status code", "Outstanding mandatory requirement list" ] }, { "id": "era-q2", "text": "Is an evidence item still valid at the moment of reliance, and was its status checked then?", "kind": "temporal", "answer_data": [ "Evidence validity period", "Status check timestamp", "Status check result", "Revocation or status endpoint reference" ] }, { "id": "era-q3", "text": "How is each attachment's integrity established and preserved between submission and reliance?", "kind": "quality", "answer_data": [ "Content digest with algorithm", "Digest computation timestamp", "Format and version identifier", "Size" ] }, { "id": "era-q4", "text": "Where alternative evidence is acceptable, which alternative was chosen and who accepted the substitution?", "kind": "decision", "answer_data": [ "Accepted alternative evidence type", "Substitution rule reference", "Accepting agent reference", "Acceptance timestamp" ] } ], "data_elements": [ { "id": "de-evidence-item", "name": "Evidence item", "description": "A supplied or referenced proof, with type, source, format, digest and validity window.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-017" ] }, { "id": "de-requirement-discharge", "name": "Requirement discharge link", "description": "Association between a catalogue requirement and the evidence judged to satisfy it, with status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "de-evidence-digest", "name": "Evidence content digest", "description": "Cryptographic digest of the attachment as received, with named algorithm.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-017" ] } ], "artifacts": [ { "id": "evidence-manifest-artifact", "name": "Evidence manifest", "description": "An enumeration of every evidence item bound to the request, the requirement each discharges, its origin, its digest and its validity, forming the sufficiency baseline.", "media_or_form": [ "structured manifest", "itemised schedule of documents" ], "serial": false, "identity_strategy": "Derived identity: request identifier plus manifest version ordinal; regenerated as a new version whenever evidence is added, replaced or withdrawn.", "source_refs": [ "SRC-001", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "authoritative-evidence-sourcing", "name": "Evidence obtained from authoritative sources on explicit request", "description": "Where a body may fetch evidence from another authority rather than ask the applicant, the model must record the applicant's explicit request, any preview and rejection of the fetched evidence, and the provenance of the retrieved item.", "source_refs": [ "SRC-002", "SRC-001", "SRC-007", "SRC-017" ], "questions": [ { "id": "aes-q1", "text": "Did the requester explicitly request that evidence be fetched from another authority, and how is that explicit request evidenced?", "kind": "authority", "answer_data": [ "Explicit request flag", "Explicit request evidence reference", "Scope of the authorisation", "Request timestamp" ] }, { "id": "aes-q2", "text": "Was the retrieved evidence previewed by the requester before use, and could it be rejected?", "kind": "process", "answer_data": [ "Preview offered flag", "Preview outcome code (used, rejected, not exercised)", "Preview timestamp", "Consequence of rejection" ] }, { "id": "aes-q3", "text": "Which authority provided the evidence, under which mapping between the requirement and that authority's evidence type?", "kind": "provenance", "answer_data": [ "Providing authority reference", "Evidence type mapping reference", "Retrieval activity record", "Retrieval timestamp" ] }, { "id": "aes-q4", "text": "What happens to the request when authoritative retrieval fails or returns no match?", "kind": "exception", "answer_data": [ "Failure reason code", "Fallback path code (applicant supplies, manual channel, refusal)", "Clock-effect flag", "Notification record" ] } ], "data_elements": [ { "id": "de-explicit-request-record", "name": "Explicit request record", "description": "Evidence that the requester asked for cross-authority evidence retrieval, with scope and timestamp.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "de-evidence-retrieval-activity", "name": "Evidence retrieval activity", "description": "Provenance record of a retrieval: requesting body, providing body, start and end instants, outcome.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-002" ] }, { "id": "de-preview-outcome", "name": "Preview outcome", "description": "Whether the requester previewed retrieved evidence and whether it was used or rejected.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "explicit-request-and-preview-artifact", "name": "Explicit request and preview record", "description": "The retained record of the applicant's explicit authorisation for cross-authority evidence retrieval and of any preview exercised, kept because it is the lawful basis for the retrieval.", "media_or_form": [ "structured authorisation record", "preview interaction log", "signed consent statement" ], "serial": false, "identity_strategy": "Request identifier plus retrieval activity identifier; where the exchange system issues its own correlation identifier, that value takes precedence as the authoritative key.", "source_refs": [ "SRC-002", "SRC-007" ] } ], "inline_only_rationale": null }, { "id": "eligibility-criteria-and-requirement-response", "name": "Held requirements and criteria", "description": "A Public Service holds requirements (residency, age, and similar). Criteria are requirements with an evaluation objective and optional weights. Information requirements request data that evidence must support. The application records which requirements apply and the assessment posture, not the criterion catalogue itself.", "source_refs": [ "SRC-001", "SRC-020" ], "questions": [ { "id": "eligibility-criteria-and-requirement-response-q01", "text": "Which requirements and criteria does this application have to satisfy, and which information concepts must be evidenced?", "kind": "requirement", "answer_data": [ "requirement identifiers", "criterion identifiers", "information concepts", "mandatory versus optional flag" ] }, { "id": "eligibility-criteria-and-requirement-response-q02", "text": "If criteria are weighted or biased for evaluation, what weights, weighting type and consideration description apply?", "kind": "measurement", "answer_data": [ "weight decimal 0 to 1", "weighting type code", "bias parameter", "weighting consideration description" ] }, { "id": "eligibility-criteria-and-requirement-response-q03", "text": "For each requirement, has evidence been provided, reused, waived, or is it still outstanding?", "kind": "state", "answer_data": [ "requirement identifier", "response state code", "linked evidence identifiers", "waiver or exception reference" ] } ], "data_elements": [ { "id": "eligibility-criteria-and-requirement-response-data01", "name": "Held requirement", "description": "Requirement the public service holds and that this application must address.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-020" ] }, { "id": "eligibility-criteria-and-requirement-response-data02", "name": "Criterion weight", "description": "Relative importance of a criterion between 0 and 1.", "value_kind": "number", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020" ] }, { "id": "eligibility-criteria-and-requirement-response-data03", "name": "Requirement response state", "description": "Whether the requirement is evidenced, outstanding, waived or failed.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-020" ] } ], "artifacts": [], "inline_only_rationale": "Requirements and criteria are references to CCCEV/CPSV-AP definitions plus per-application response state; the definitional catalogue is a sibling." } ] }, { "id": "completeness-and-validation", "name": "Completeness, Admissibility and Technical Validation", "description": "Two separate gates: does the package parse and conform, and is the request legally admissible and complete enough to start.", "source_refs": [ "SRC-003", "SRC-006", "SRC-012", "SRC-016" ], "findings": [ { "id": "completeness-and-admissibility", "name": "Completeness screening and admissibility determination", "description": "A request that is received is not necessarily perfected. Bodies commonly owe a duty to notify missing documents promptly and to say whether the processing clock is affected, and admissibility is a reviewable determination in its own right.", "source_refs": [ "SRC-003", "SRC-012", "SRC-010", "SRC-006" ], "questions": [ { "id": "caa-q1", "text": "Against which criteria is completeness assessed, and who is competent to make that determination?", "kind": "validation", "answer_data": [ "Completeness criteria set reference", "Determining agent reference", "Determination outcome code", "Determination timestamp" ] }, { "id": "caa-q2", "text": "When a deficiency is found, what must the notice tell the requester and by when must it be sent?", "kind": "requirement", "answer_data": [ "Deficiency item list", "Notice content requirements reference", "Notice dispatch deadline", "Actual dispatch timestamp" ] }, { "id": "caa-q3", "text": "What effect does a deficiency have on the statutory clock - suspension, restart, or none - and on what legal basis?", "kind": "temporal", "answer_data": [ "Clock-effect code", "Legal basis reference", "Suspension start and end instants", "Recomputed deadline" ] }, { "id": "caa-q4", "text": "If the requester does not cure the deficiency, what disposition follows and is it appealable?", "kind": "exception", "answer_data": [ "Cure deadline", "Non-cure disposition code", "Appealability flag", "Redress route reference" ] }, { "id": "caa-q5", "text": "Is completeness screening re-run after amendment, and does an amended request inherit the original submission date?", "kind": "lifecycle", "answer_data": [ "Re-screening trigger rule", "Date-inheritance policy code", "Effective submission date after amendment" ] } ], "data_elements": [ { "id": "de-completeness-determination", "name": "Completeness determination", "description": "Outcome, agent, basis and timestamp of the assessment that the request is or is not complete.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-deficiency-item", "name": "Deficiency item", "description": "A specific missing or defective element, with the requirement it relates to and the cure deadline.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] }, { "id": "de-effective-submission-date", "name": "Effective submission instant", "description": "The instant from which the procedure is legally treated as started, which may differ from first receipt.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-012", "SRC-008" ] } ], "artifacts": [ { "id": "deficiency-notice-artifact", "name": "Deficiency / further-information notice", "description": "The outbound notice telling the requester what is missing, by when it must be supplied, and what effect the deficiency has on the processing period.", "media_or_form": [ "formal letter", "structured notification message", "portal notification" ], "serial": true, "identity_strategy": "Request identifier plus a monotonically increasing notice sequence number within the request; where a correspondence register exists, its register identifier is authoritative.", "source_refs": [ "SRC-003", "SRC-012" ] } ], "inline_only_rationale": null }, { "id": "validation-rules-and-conformance", "name": "Technical validation, business rules and error reporting", "description": "Conformance checking against schema, code lists and business rules is distinct from legal admissibility and must produce machine-actionable, citable errors bound to specific fields.", "source_refs": [ "SRC-006", "SRC-016", "SRC-001", "SRC-004" ], "questions": [ { "id": "vrc-q1", "text": "Which validation layers apply - structural, code-list, cross-field, cross-record - and in which order are they executed?", "kind": "process", "answer_data": [ "Validation layer list", "Execution order", "Blocking versus advisory marker per layer" ] }, { "id": "vrc-q2", "text": "How is each validation failure identified so a requester or agent can locate and fix it?", "kind": "quality", "answer_data": [ "Error code", "Error code system reference", "Field path or element reference", "Human-readable message and severity" ] }, { "id": "vrc-q3", "text": "Which rules are enforced at submission time versus after receipt, and what is the consequence of that placement?", "kind": "constraint", "answer_data": [ "Rule enforcement point", "Rejection-at-submission flag", "Post-receipt handling path" ] }, { "id": "vrc-q4", "text": "When a rule set changes, are previously accepted requests revalidated, and how is a legacy pass recorded?", "kind": "provenance", "answer_data": [ "Rule set version at validation", "Revalidation policy code", "Prior validation outcome retained flag" ] } ], "data_elements": [ { "id": "de-validation-outcome", "name": "Validation outcome", "description": "Aggregate pass/fail result of a validation run, with rule set version and timestamp.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "de-validation-issue", "name": "Validation issue", "description": "A single detected problem with code, location, severity and message.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "validation-report-artifact", "name": "Validation report", "description": "The retained result of a validation run over the submitted package, enumerating issues with codes and locations, retained as evidence of why a submission was or was not accepted technically.", "media_or_form": [ "structured report", "machine-readable issue list" ], "serial": true, "identity_strategy": "Request identifier plus validation run ordinal and RFC 3339 run instant; each re-run creates a new report rather than overwriting.", "source_refs": [ "SRC-006", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "submission-and-capture", "name": "Submission Act, Channel and Record Capture", "description": "The act of submitting, the channel used, the receipt owed to the requester, and the capture of the submission as an authentic record.", "rationale": "Records become authoritative evidence only if captured with authenticity, reliability, integrity and usability preserved; and authorisation procedures impose an explicit duty to acknowledge receipt. The submission act is therefore a first-class, separately governed concern rather than a side effect of data entry.", "source_refs": [ "SRC-014", "SRC-003", "SRC-006", "SRC-019" ], "layers": [ { "id": "submission-event", "name": "Submission, Receipt and Channel", "description": "The instants that matter, the acknowledgement owed, and the channel through which the request arrived.", "source_refs": [ "SRC-003", "SRC-012", "SRC-008", "SRC-019" ], "findings": [ { "id": "submission-receipt-and-timestamps", "name": "Submission, receipt, registration and ingestion instants", "description": "Four distinct instants routinely diverge: when the requester submitted, when the body received it, when the proper component received it, and when the system ingested it. Legal effects attach to different ones, so they must be recorded separately with explicit offsets.", "source_refs": [ "SRC-003", "SRC-012", "SRC-008", "SRC-006" ], "questions": [ { "id": "srt-q1", "text": "Which instants are captured for this request and which one starts the legally relevant period?", "kind": "temporal", "answer_data": [ "Submission instant", "Receipt instant", "Component-receipt instant", "Registration instant", "Ingestion instant", "Clock-start designation" ] }, { "id": "srt-q2", "text": "Which clock and time zone are authoritative when the requester and the receiving body are in different zones, and how are out-of-hours and deadline-day submissions treated?", "kind": "temporal", "answer_data": [ "Authoritative time source reference", "Offset recorded per instant", "Business-hours rule reference", "Deadline-day treatment rule" ] }, { "id": "srt-q3", "text": "What must the acknowledgement of receipt tell the requester, and within what period must it be issued?", "kind": "requirement", "answer_data": [ "Stated processing period", "Means of redress statement", "Tacit-approval statement where applicable", "Tracking reference", "Issue deadline and actual issue instant" ] }, { "id": "srt-q4", "text": "How is receipt proven if the acknowledgement is never delivered or is disputed?", "kind": "evidence", "answer_data": [ "Delivery evidence reference", "Transport receipt or seal", "Dispute resolution rule", "Independent log entry reference" ] } ], "data_elements": [ { "id": "de-submission-instant", "name": "Submission instant", "description": "When the requester completed the submission act, as an RFC 3339 timestamp with seconds and explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-003" ] }, { "id": "de-receipt-instant", "name": "Receipt instant", "description": "When the receiving body took possession of the request; may differ from the submission instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-012", "SRC-008" ] }, { "id": "de-registration-instant", "name": "Registration instant", "description": "When the request was formally entered on the register and given its authoritative identifier.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] }, { "id": "de-ingestion-instant", "name": "Ingestion instant", "description": "When the record was captured into the managing system, recorded separately from the event instants.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-008" ] } ], "artifacts": [ { "id": "submission-receipt-artifact", "name": "Acknowledgement of receipt", "description": "The receipt issued to the requester stating the processing period, redress routes, any tacit-approval effect and the tracking reference; it is the requester's primary proof that the request exists.", "media_or_form": [ "receipt document", "structured acknowledgement message", "portal confirmation with printable form" ], "serial": true, "identity_strategy": "Carries the authoritative request identifier as its subject key and its own receipt serial from the issuing register; the pair is the citable reference.", "source_refs": [ "SRC-003", "SRC-012", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "channel-and-accessibility", "name": "Channel, cross-border access and accessibility equity", "description": "The channel is not a delivery detail: it determines available evidence-fetching, identity assurance, accessibility obligations and, for cross-border requesters, whether the procedure is usable at all. Outcomes must not depend on the channel chosen.", "source_refs": [ "SRC-001", "SRC-002", "SRC-019", "SRC-010" ], "questions": [ { "id": "cha-q1", "text": "Through which channel was the request submitted, and which channels are formally equivalent for this procedure?", "kind": "classification", "answer_data": [ "Channel reference", "Equivalent channel set", "Channel availability period", "Channel-specific constraints" ] }, { "id": "cha-q2", "text": "Can a non-resident or cross-border requester complete this procedure through the same channel with a foreign identity means?", "kind": "access", "answer_data": [ "Cross-border availability flag", "Accepted foreign identity means", "Discriminatory-barrier assessment", "Alternative route reference" ] }, { "id": "cha-q3", "text": "What accessibility and assisted-route provision exists for requesters who cannot use the primary channel?", "kind": "access", "answer_data": [ "Accessibility conformance statement reference", "Assisted route description", "Reasonable adjustment record" ] }, { "id": "cha-q4", "text": "Does the channel affect the legal treatment of the request - fees, deadlines, evidence, or the reply format owed?", "kind": "constraint", "answer_data": [ "Channel-dependent rule list", "Reply-format obligation", "Fee variation by channel", "Equivalence assurance statement" ] } ], "data_elements": [ { "id": "de-submission-channel", "name": "Submission channel", "description": "The medium through which the request reached the body, referencing the catalogue channel definition.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "id": "de-reasonable-adjustment", "name": "Reasonable adjustment record", "description": "Any accommodation applied so the requester could submit or be served.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-010" ] } ], "artifacts": [], "inline_only_rationale": "The channel is a coded reference into the sibling public-service catalogue, which owns the Channel object with its availability, cost and constraints. Holding a copy here would create a second, drifting definition of the same channel; only the reference and any request-specific adjustment are inline." } ] }, { "id": "authenticity-and-capture", "name": "Authenticity, Integrity and Capture", "description": "Signature, seal, fixity and the act of capturing the request into a managed records system.", "source_refs": [ "SRC-014", "SRC-006", "SRC-015", "SRC-017" ], "findings": [ { "id": "capture-fixity-and-non-repudiation", "name": "Capture, fixity, signature and non-repudiation", "description": "To function as authoritative evidence the request must be captured so that it is what it purports to be, complete and unaltered, and retrievable and interpretable for as long as it is needed. Signatures and seals support attribution; fixity supports integrity; neither substitutes for the other.", "source_refs": [ "SRC-014", "SRC-015", "SRC-006", "SRC-017" ], "questions": [ { "id": "cfn-q1", "text": "What binds the request content to its submitter in a way that resists later repudiation?", "kind": "security", "answer_data": [ "Signature or seal type", "Signatory or sealing entity reference", "Signature validation result and validation instant", "Trust anchor reference" ] }, { "id": "cfn-q2", "text": "How is integrity of the as-captured record demonstrated at any later date?", "kind": "quality", "answer_data": [ "Fixity digest and algorithm", "Fixity computation instant", "Fixity re-check schedule and last result", "Custody boundary crossings" ] }, { "id": "cfn-q3", "text": "At what point is the request formally captured as a record, and what becomes immutable at that point?", "kind": "lifecycle", "answer_data": [ "Capture event instant", "Immutability scope description", "Permitted post-capture change classes", "Capturing system reference" ] }, { "id": "cfn-q4", "text": "How will the record remain interpretable if its original format or signature algorithm becomes obsolete?", "kind": "retention", "answer_data": [ "Format identifier and version", "Preservation action plan reference", "Signature-renewal or evidence-record strategy", "Rendering surrogate reference" ] } ], "data_elements": [ { "id": "de-fixity-digest", "name": "Fixity digest", "description": "Digest of the as-captured request package with named algorithm and computation instant.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] }, { "id": "de-signature-validation", "name": "Signature validation result", "description": "Outcome of validating a signature or seal, with the instant of validation and the trust anchor used.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-006" ] }, { "id": "de-capture-event", "name": "Capture event", "description": "The event that brought the request under records control, with capturing system and instant.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-015" ] } ], "artifacts": [ { "id": "sealed-submission-package-artifact", "name": "Sealed submission package", "description": "The bundled as-received request with its attachments, signatures, seals, transport metadata and fixity values, retained as the evidential original.", "media_or_form": [ "signed container", "archival package", "sealed message envelope" ], "serial": false, "identity_strategy": "Authoritative request identifier plus package digest; the digest is the tamper-evident secondary key and must be recorded at capture, not recomputed on demand.", "source_refs": [ "SRC-014", "SRC-006", "SRC-015" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle-and-processing", "name": "Status, Change, Time and Handover", "description": "How the request moves through states, how it may lawfully change, how its clocks are computed, and how it hands over to a case or fulfilment.", "rationale": "Independently governed request models converge on an explicit status set with reasons and a separate business status, and authorisation law imposes fixed pre-published periods with defined extension and tacit-approval effects. These are the operating mechanics an agent must get right.", "source_refs": [ "SRC-005", "SRC-004", "SRC-003", "SRC-012" ], "layers": [ { "id": "status-and-change", "name": "Status Model and Permitted Change", "description": "The state set and transitions, and the amendment, withdrawal and supersession paths.", "source_refs": [ "SRC-005", "SRC-004", "SRC-007", "SRC-015" ], "findings": [ { "id": "request-status-model", "name": "Status set, transitions and status reasons", "description": "A defensible status model distinguishes the technical processing state from the business-meaningful state, records a reason for every non-obvious state, and keeps an explicit erroneous-entry state separate from legitimate cancellation.", "source_refs": [ "SRC-005", "SRC-004", "SRC-006" ], "questions": [ { "id": "rsm-q1", "text": "What is the complete set of states this request can occupy, and which are terminal?", "kind": "state", "answer_data": [ "State code list", "Terminal state markers", "State code system reference", "Initial state" ] }, { "id": "rsm-q2", "text": "Which state transitions are permitted, who may trigger each, and what precondition must hold?", "kind": "lifecycle", "answer_data": [ "Transition list with source and target state", "Authorised actor role per transition", "Precondition expression", "Transition event record" ] }, { "id": "rsm-q3", "text": "How is the technical processing state distinguished from the business status the requester is told about?", "kind": "definition", "answer_data": [ "Technical status value", "Business status value and vocabulary", "Mapping rule between them", "Externally disclosed status text" ] }, { "id": "rsm-q4", "text": "How is a request recorded that should never have existed, as distinct from one properly cancelled or withdrawn?", "kind": "exception", "answer_data": [ "Entered-in-error flag", "Cancellation reason code", "Withdrawal reason code", "Retention treatment for erroneous records" ] } ], "data_elements": [ { "id": "de-request-status", "name": "Request status", "description": "Current processing state of the request from the governed state set.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-005", "SRC-004" ] }, { "id": "de-status-reason", "name": "Status reason", "description": "Coded and free-text explanation of why the request is in its current state.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-business-status", "name": "Business status", "description": "Workflow-meaningful status communicated to the requester, distinct from the technical state.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [], "inline_only_rationale": "Current status is a single inline coded value; its history is not stored here but in the event-history artefact defined under the temporal layer. Materialising a second status artefact would create two competing sources of truth for the same state." }, { "id": "amendment-withdrawal-supersession", "name": "Amendment, supplementation, withdrawal and supersession", "description": "Requests change after submission. Each change class has different legal consequences for the submission date, the clock and the evidence baseline, and none may erase the prior state.", "source_refs": [ "SRC-003", "SRC-007", "SRC-014", "SRC-005" ], "questions": [ { "id": "aws-q1", "text": "Which change classes are permitted after submission, and until which point in the lifecycle?", "kind": "constraint", "answer_data": [ "Permitted change class list", "Cut-off state or instant per class", "Authorising rule reference" ] }, { "id": "aws-q2", "text": "Does an amendment create a new version of the same request or a new request that supersedes the old one?", "kind": "identity", "answer_data": [ "Versioning policy code", "Version ordinal", "Supersedes/superseded-by links", "Identifier continuity rule" ] }, { "id": "aws-q3", "text": "What effect does each change class have on the effective submission date and the running deadline?", "kind": "temporal", "answer_data": [ "Date-inheritance rule per class", "Clock effect per class", "Recomputed deadline", "Notification obligation" ] }, { "id": "aws-q4", "text": "On withdrawal, what is retained, what is returned, and what is the requester told?", "kind": "retention", "answer_data": [ "Withdrawal instant and actor", "Retention treatment of withdrawn content", "Fee refund entitlement", "Confirmation notice reference" ] } ], "data_elements": [ { "id": "de-version-ordinal", "name": "Version ordinal", "description": "Monotonic version number of the request content, incremented on each accepted amendment.", "value_kind": "number", "cardinality": "1", "required": true, "source_refs": [ "SRC-014", "SRC-007" ] }, { "id": "de-supersession-link", "name": "Supersession link", "description": "Derivation relation to the request or version this one replaces.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-change-event", "name": "Change event", "description": "Record of an amendment, supplementation or withdrawal with class, actor, reason and instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-005" ] } ], "artifacts": [ { "id": "change-or-withdrawal-notice-artifact", "name": "Amendment / withdrawal notice", "description": "The instrument by which the requester or body records a change or withdrawal, retained because it evidences consent to alter or end the request.", "media_or_form": [ "signed notice", "structured change message", "portal confirmation" ], "serial": true, "identity_strategy": "Request identifier plus change sequence number; where a correspondence register exists its identifier is authoritative, and the notice always cites the version ordinal it acts on.", "source_refs": [ "SRC-003", "SRC-015" ] } ], "inline_only_rationale": null } ] }, { "id": "time-and-deadlines", "name": "Time Limits and Event History", "description": "Statutory and service clocks, their suspension and extension, and the append-only history of what happened when.", "source_refs": [ "SRC-003", "SRC-012", "SRC-008", "SRC-015" ], "findings": [ { "id": "statutory-clock-management", "name": "Processing periods, tolling, extension and tacit outcomes", "description": "Processing periods must be fixed and published in advance, are commonly extendable once on justified grounds with notice before expiry, may be tolled in defined circumstances, and in some regimes expiry produces a deemed grant. Clock state is derived data that must be reproducible from recorded events.", "source_refs": [ "SRC-003", "SRC-012", "SRC-010", "SRC-008" ], "questions": [ { "id": "scm-q1", "text": "What processing period applies, on what legal basis, and where was it published in advance?", "kind": "authority", "answer_data": [ "Period duration and unit", "Calendar basis (working days versus calendar days)", "Legal basis reference", "Publication location reference" ] }, { "id": "scm-q2", "text": "From which recorded instant does the period run, and how is that instant chosen when receipt is staged across components?", "kind": "temporal", "answer_data": [ "Clock-start instant", "Clock-start selection rule", "Component-transfer instants", "Maximum permitted internal transfer delay" ] }, { "id": "scm-q3", "text": "Under which conditions may the clock be suspended or extended, who authorises it, and what notice is owed before expiry?", "kind": "process", "answer_data": [ "Suspension condition codes", "Extension grant record with justification", "Maximum extension", "Notice dispatch instant and content" ] }, { "id": "scm-q4", "text": "What happens on expiry - deemed grant, deemed refusal, or continued duty to decide - and how is that outcome recorded?", "kind": "decision", "answer_data": [ "Expiry consequence code", "Overriding public interest exception reference", "Deemed-outcome record", "Expiry instant" ] }, { "id": "scm-q5", "text": "Is an estimated completion date communicated to the requester, and how is it revised?", "kind": "measurement", "answer_data": [ "Estimated completion date", "Estimate basis", "Revision history", "Revision notification records" ] } ], "data_elements": [ { "id": "de-processing-deadline", "name": "Processing deadline", "description": "The computed instant by which the body must respond, derived from the clock-start instant and the applicable period.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "de-clock-suspension", "name": "Clock suspension interval", "description": "A tolling interval with start, end, reason and authorising basis.", "value_kind": "duration", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-003" ] }, { "id": "de-extension-grant", "name": "Extension grant", "description": "A recorded extension with justification, granting actor, new deadline and notice instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-tacit-outcome-flag", "name": "Tacit outcome indicator", "description": "Whether silence on expiry produces a deemed grant, deemed refusal, or no automatic effect.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "deadline-notification-artifact", "name": "Time-limit and extension notification", "description": "Outbound notices stating the applicable period, any extension with its justification, and the estimated completion date, retained as evidence that the notice duty was met before expiry.", "media_or_form": [ "formal notice", "structured notification message" ], "serial": true, "identity_strategy": "Request identifier plus notice sequence number and RFC 3339 dispatch instant; the dispatch instant, not the drafting instant, is the evidential value.", "source_refs": [ "SRC-003", "SRC-012", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "event-history-and-audit-trail", "name": "Append-only event history and audit trail", "description": "Every entity in a defensible records system carries an event history. For a request this history is both the operational timeline and the audit evidence, and it must distinguish when something happened from when it was recorded.", "source_refs": [ "SRC-015", "SRC-014", "SRC-007", "SRC-008" ], "questions": [ { "id": "eha-q1", "text": "Which event types must be recorded for a request, and is the history append-only?", "kind": "provenance", "answer_data": [ "Event type list", "Append-only guarantee statement", "Event ordering key", "Gap-detection mechanism" ] }, { "id": "eha-q2", "text": "For each event, is the event instant recorded separately from the observation or ingestion instant?", "kind": "temporal", "answer_data": [ "Event instant", "Recording instant", "Clock source reference", "Offset for each instant" ] }, { "id": "eha-q3", "text": "Which agent, human or software, is attributed to each event, and on whose behalf did it act?", "kind": "provenance", "answer_data": [ "Acting agent reference", "Agent type", "Acted-on-behalf-of chain", "Authorisation basis for the action" ] }, { "id": "eha-q4", "text": "How long is the event history retained relative to the request content, and can it be disposed of separately?", "kind": "retention", "answer_data": [ "History retention rule", "Independent disposal permitted flag", "Rationale for divergence from content retention" ] } ], "data_elements": [ { "id": "de-event-entry", "name": "Event history entry", "description": "One immutable entry: event type, event instant, recording instant, acting agent, affected element and outcome.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015", "SRC-007" ] }, { "id": "de-event-instant", "name": "Event instant", "description": "When the event actually occurred, as an RFC 3339 timestamp with explicit offset.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-008" ] }, { "id": "de-recording-instant", "name": "Recording instant", "description": "When the event was observed and written to the history, distinct from the event instant.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-008", "SRC-015" ] } ], "artifacts": [ { "id": "event-history-artifact", "name": "Request event history", "description": "The append-only sequence of events for the request, functioning as its audit trail and as the derivation source for every computed clock or status value.", "media_or_form": [ "append-only log", "structured event series", "audit register extract" ], "serial": false, "identity_strategy": "Bound one-to-one to the authoritative request identifier; individual entries keyed by a monotonic sequence number plus event instant, never by timestamp alone since timestamps can collide.", "source_refs": [ "SRC-015", "SRC-008", "SRC-014" ] } ], "inline_only_rationale": null } ] }, { "id": "routing-and-handover", "name": "Routing, Prioritisation and Handover", "description": "Determining the competent body and processing track, and the disposition that ends the request's own lifecycle.", "source_refs": [ "SRC-006", "SRC-012", "SRC-018", "SRC-002" ], "findings": [ { "id": "competence-routing-and-prioritisation", "name": "Competent body determination, transfer and processing track", "description": "A request may arrive at the wrong body or the wrong component. Competence determination, onward transfer with a preserved receipt date, and assignment to a processing track are distinct operations each with their own evidence and timing consequences.", "source_refs": [ "SRC-012", "SRC-006", "SRC-002", "SRC-001" ], "questions": [ { "id": "crp-q1", "text": "Which body is competent for this request, on what jurisdictional or subject-matter basis, and who determined that?", "kind": "authority", "answer_data": [ "Competent body reference", "Competence basis code", "Determining agent and instant", "Competence dispute record" ] }, { "id": "crp-q2", "text": "When a request is transferred, what date does the receiving body treat as receipt, and is the requester notified?", "kind": "process", "answer_data": [ "Transfer instant", "Receipt date carried forward flag", "Maximum internal transfer window", "Requester notification record" ] }, { "id": "crp-q3", "text": "Into which processing track is the request placed, on what criteria, and can the requester request expedition?", "kind": "classification", "answer_data": [ "Track code", "Track assignment criteria reference", "Expedition request record", "Expedition determination and deadline" ] }, { "id": "crp-q4", "text": "How is priority or queue position made auditable so that ordering can be shown to be non-arbitrary?", "kind": "quality", "answer_data": [ "Priority value and basis", "Queue position at assignment", "Reordering events with justification" ] } ], "data_elements": [ { "id": "de-competent-body", "name": "Competent body assignment", "description": "The body currently responsible, with basis and effective period.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "de-processing-track", "name": "Processing track", "description": "The queue or track into which the request is placed for handling.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] }, { "id": "de-expedition-determination", "name": "Expedition determination", "description": "Outcome, reason and instant of a decision on expedited handling.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012" ] } ], "artifacts": [ { "id": "transfer-notice-artifact", "name": "Transfer / referral notice", "description": "The record of forwarding a request to another body or component, preserving the original receipt date and evidencing that the requester was told where the request went.", "media_or_form": [ "referral notice", "structured transfer message", "register annotation" ], "serial": true, "identity_strategy": "Request identifier plus transfer sequence number; the notice must carry both the originating and receiving body identifiers and the original receipt instant.", "source_refs": [ "SRC-012", "SRC-006" ] } ], "inline_only_rationale": null }, { "id": "case-opening-and-request-disposition", "name": "Case opening, fulfilment and final disposition of the request", "description": "The request's own lifecycle ends at disposition: a case is opened, the service is fulfilled directly, or the request is refused, withdrawn or closed. This is the boundary handover to the neighbouring case model and must be an explicit, linked event.", "source_refs": [ "SRC-018", "SRC-006", "SRC-003", "SRC-005" ], "questions": [ { "id": "crd-q1", "text": "What disposition ended the request's own lifecycle, and when?", "kind": "lifecycle", "answer_data": [ "Disposition code", "Disposition instant", "Deciding agent reference", "Disposition reason" ] }, { "id": "crd-q2", "text": "If a case or proceeding was opened, what is its identifier and what is the typed relation between request and case?", "kind": "relationship", "answer_data": [ "Case identifier", "Relation type", "Case opening instant", "Opening body reference" ] }, { "id": "crd-q3", "text": "Can one request open several cases, or several requests be consolidated into one case, and how is that recorded?", "kind": "composition", "answer_data": [ "Cardinality rule", "Split or consolidation event record", "Resulting case identifier set", "Justification" ] }, { "id": "crd-q4", "text": "Where the request is refused at intake, what reasons must be given and which redress route is stated?", "kind": "requirement", "answer_data": [ "Refusal reason text and code", "Legal basis for refusal", "Redress route reference and deadline", "Notice dispatch instant" ] }, { "id": "crd-q5", "text": "After disposition, does the request record remain independently addressable and queryable for status?", "kind": "access", "answer_data": [ "Post-disposition addressability flag", "Status-query availability period", "Redirection rule to the case record" ] } ], "data_elements": [ { "id": "de-disposition-code", "name": "Disposition code", "description": "How the request lifecycle ended: case opened, fulfilled, refused, withdrawn, closed, entered in error.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "de-case-reference", "name": "Case reference", "description": "Identifier of the case or proceeding opened as a result of the request.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-006" ] }, { "id": "de-outcome-reference", "name": "Outcome reference", "description": "Pointer to the decision or output record produced, held in the sibling outcome model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [ { "id": "case-opening-or-refusal-notice-artifact", "name": "Case-opening or intake-refusal notice", "description": "The instrument recording that a case was opened with its reference, or that the request was refused at intake with reasons and redress information.", "media_or_form": [ "formal notice", "docketing confirmation", "structured notification message" ], "serial": true, "identity_strategy": "Request identifier plus the newly minted case identifier where a case exists; for refusals, request identifier plus notice sequence number.", "source_refs": [ "SRC-006", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "jurisdiction-place-and-lodgement-location", "name": "Jurisdiction, spatial coverage and place of performance", "description": "Public Organization and Public Service have spatial coverage (administrative regions). Requests may name a location of performance. Channel walk-in centres are locations. Geometry is optional via Core Location.", "source_refs": [ "SRC-001", "SRC-021" ], "questions": [ { "id": "jurisdiction-place-and-lodgement-location-q01", "text": "Which administrative region or jurisdiction does the requested service and competent authority cover, and is the subject in-scope?", "kind": "spatial", "answer_data": [ "spatial region URIs", "subject location or residency", "in-jurisdiction boolean" ] }, { "id": "jurisdiction-place-and-lodgement-location-q02", "text": "Where should the service be performed, if location-specific?", "kind": "spatial", "answer_data": [ "location reference", "location type", "coordinates or address if held" ] }, { "id": "jurisdiction-place-and-lodgement-location-q03", "text": "If lodged in person, at which office or address was the application received?", "kind": "spatial", "answer_data": [ "office location", "address", "channel location identifier" ] } ], "data_elements": [ { "id": "jurisdiction-place-and-lodgement-location-data01", "name": "Spatial coverage", "description": "Administrative region covered by the service or competent authority.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001" ] }, { "id": "jurisdiction-place-and-lodgement-location-data02", "name": "Performance location", "description": "Location where the service should be performed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-021" ] }, { "id": "jurisdiction-place-and-lodgement-location-data03", "name": "Lodgement location", "description": "Place of in-person or posted lodgement.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-001" ] } ], "artifacts": [], "inline_only_rationale": "Spatial values are references to location or region authorities; maps and geometries belong to the location sibling model." } ] } ] }, { "id": "authority-rights-and-stewardship", "name": "Legal Basis, Rights, Privacy and Stewardship", "description": "Why the body may collect this request at all, what it may charge, what the requester is owed, and how the record is protected, restricted and eventually disposed of.", "rationale": "Collection authority, applicant rights and disposition are legally mandated dimensions that intake systems routinely under-model. Authorisation-procedure law fixes the rights side, records standards fix the disposition side, and privacy authorities fix the personal-data side.", "source_refs": [ "SRC-003", "SRC-010", "SRC-014", "SRC-015" ], "layers": [ { "id": "authority-and-cost", "name": "Collection Authority and Cost", "description": "The mandate to require this information and the fees attached to the request.", "source_refs": [ "SRC-003", "SRC-001", "SRC-012", "SRC-013" ], "findings": [ { "id": "legal-basis-and-collection-authority", "name": "Legal basis, mandate and authority to collect", "description": "A request form is a collection of information exercised under a mandate. The mandate, the burden imposed and any approval or reference required for the collection are context an agent must be able to cite, not assume.", "source_refs": [ "SRC-013", "SRC-003", "SRC-002", "SRC-001" ], "questions": [ { "id": "lba-q1", "text": "Under which instrument is the body empowered to require this request and this information, and is that instrument cited to the requester?", "kind": "authority", "answer_data": [ "Legal resource reference", "Mandate identifier", "Citation shown to requester flag", "Effective period of the mandate" ] }, { "id": "lba-q2", "text": "Is the request voluntary or mandatory, and what follows from not providing a given item?", "kind": "requirement", "answer_data": [ "Voluntary or mandatory marker per item", "Consequence of non-provision", "Statement shown to requester" ] }, { "id": "lba-q3", "text": "Is a collection approval, control number or equivalent registration required before the form may be used, and is it current?", "kind": "validation", "answer_data": [ "Collection approval reference", "Approval expiry date", "Display obligation flag", "Consequence of an expired approval" ] }, { "id": "lba-q4", "text": "What burden does the request impose on the requester, and is that estimate published?", "kind": "measurement", "answer_data": [ "Estimated completion time", "Estimated cost to requester", "Burden estimate publication reference", "Estimate review date" ] } ], "data_elements": [ { "id": "de-legal-basis-ref", "name": "Legal basis reference", "description": "The instrument authorising the procedure and the collection of the requested information.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-001", "SRC-003" ] }, { "id": "de-collection-approval", "name": "Collection approval reference", "description": "Identifier and expiry of any required approval or registration for the information collection.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-013" ] }, { "id": "de-mandatory-marker", "name": "Mandatory-provision marker", "description": "Per data item, whether provision is mandatory and what the consequence of omission is.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "collection-authority-statement-artifact", "name": "Collection authority and burden statement", "description": "The statement presented with the form giving the legal authority for the collection, whether provision is mandatory, the consequences of non-provision and any burden estimate or approval reference.", "media_or_form": [ "notice text block", "structured statement", "published form annex" ], "serial": false, "identity_strategy": "Keyed by the form definition identifier and version rather than by request, since the statement is a property of the collection instrument; each request records which version it was shown.", "source_refs": [ "SRC-013", "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "fees-waivers-and-payment-conditionality", "name": "Fees, waivers and payment as an admissibility condition", "description": "Charges attach to many requests and unresolved fee questions can lawfully stop the clock or block admissibility. The model records the fee position and its effect on processing, not the payment transaction itself.", "source_refs": [ "SRC-001", "SRC-012", "SRC-011", "SRC-006" ], "questions": [ { "id": "fwp-q1", "text": "What charge applies to this request, on what basis, and does it vary by channel or requester category?", "kind": "constraint", "answer_data": [ "Fee amount and currency", "Fee basis reference", "Channel or category variation", "Fee calculation instant" ] }, { "id": "fwp-q2", "text": "Is payment a precondition of admissibility, and what is the effect of non-payment on the clock and the disposition?", "kind": "process", "answer_data": [ "Precondition flag", "Clock effect of unresolved fees", "Non-payment disposition code", "Payment deadline" ] }, { "id": "fwp-q3", "text": "On what grounds may a fee be waived, reduced or refunded, and who decides?", "kind": "decision", "answer_data": [ "Waiver ground code", "Deciding agent reference", "Determination and instant", "Refund entitlement on withdrawal" ] }, { "id": "fwp-q4", "text": "When may a charge be refused as excessive, or a request refused as manifestly unfounded, and who bears the burden of showing that?", "kind": "exception", "answer_data": [ "Excessiveness assessment record", "Burden-of-proof allocation", "Refusal reason and legal basis", "Redress route" ] } ], "data_elements": [ { "id": "de-fee-assessment", "name": "Fee assessment", "description": "Assessed charge with basis, amount, currency and calculation instant.", "value_kind": "quantity", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-001", "SRC-012" ] }, { "id": "de-fee-status", "name": "Fee status", "description": "Whether the charge is outstanding, paid, waived, reduced or refunded, with the effect on admissibility.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-012", "SRC-006" ] }, { "id": "de-payment-reference", "name": "Payment reference", "description": "Pointer to the payment transaction held in the sibling payment model.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "fee-assessment-artifact", "name": "Fee assessment and waiver determination", "description": "The record of the charge calculated for the request, any waiver or reduction granted with reasons, and the resulting effect on admissibility and the clock.", "media_or_form": [ "fee notice", "structured assessment record", "waiver determination letter" ], "serial": true, "identity_strategy": "Request identifier plus assessment sequence number; recalculation produces a new assessment rather than editing the prior one, so the basis at each point remains reconstructible.", "source_refs": [ "SRC-012", "SRC-006" ] } ], "inline_only_rationale": null } ] }, { "id": "rights-and-privacy", "name": "Applicant Rights and Personal Data", "description": "What the requester is entitled to receive and challenge, and how personal data in the request is lawfully handled.", "source_refs": [ "SRC-003", "SRC-010", "SRC-011", "SRC-019" ], "findings": [ { "id": "applicant-rights-and-remedies", "name": "Reasons, notification and routes of redress", "description": "Requesters are owed prompt reasoned communication of adverse determinations and a statement of the means of redress available, with the redress clock typically running from that notification.", "source_refs": [ "SRC-003", "SRC-012", "SRC-010" ], "questions": [ { "id": "arr-q1", "text": "Which determinations trigger a duty to give reasons, and to what standard of specificity?", "kind": "requirement", "answer_data": [ "Triggering determination list", "Reason specificity standard reference", "Reason text", "Legal basis cited" ] }, { "id": "arr-q2", "text": "Which redress routes are available, with what deadlines, and were they stated to the requester in writing?", "kind": "access", "answer_data": [ "Redress route reference", "Redress deadline", "Statement instant", "Delivery evidence" ] }, { "id": "arr-q3", "text": "Is the requester entitled to be heard or to correct the record before an adverse determination is made?", "kind": "process", "answer_data": [ "Right-to-be-heard applicability flag", "Opportunity offered instant", "Response received record", "Effect on the determination" ] }, { "id": "arr-q4", "text": "How is the notification instant established for the purpose of starting the redress clock?", "kind": "temporal", "answer_data": [ "Notification dispatch instant", "Deemed receipt rule", "Actual receipt evidence", "Resulting redress deadline" ] } ], "data_elements": [ { "id": "de-adverse-determination", "name": "Adverse determination record", "description": "A determination against the requester with its reasons, legal basis, agent and instant.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] }, { "id": "de-redress-route", "name": "Redress route", "description": "Available challenge mechanism with forum, deadline and any precondition.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-003" ] } ], "artifacts": [ { "id": "reasons-and-redress-notice-artifact", "name": "Reasoned determination and redress notice", "description": "The written communication giving the determination, its reasons and legal basis, and the available means of redress with deadlines; it is the instrument the redress clock runs from.", "media_or_form": [ "formal decision letter", "structured determination message", "portal notification with printable form" ], "serial": true, "identity_strategy": "Request identifier plus determination sequence number, with the RFC 3339 dispatch instant recorded as the legally operative value alongside any deemed-receipt date.", "source_refs": [ "SRC-003", "SRC-012", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "personal-data-and-lawful-processing", "name": "Personal data categories and lawful processing context", "description": "Requests concentrate personal data, often including special categories, supplied by a person exercising a right. The processing basis, minimisation position and controller/processor roles must be recorded against the request, not only at system level.", "source_refs": [ "SRC-010", "SRC-011", "SRC-019", "SRC-002" ], "questions": [ { "id": "pdl-q1", "text": "Which categories of personal data does this request contain, and are any of them special-category or otherwise heightened-risk?", "kind": "privacy", "answer_data": [ "Data category list", "Special-category marker", "Location of each category in the payload or attachments", "Risk classification" ] }, { "id": "pdl-q2", "text": "What is the lawful basis for processing each category, and does that basis persist after disposition?", "kind": "authority", "answer_data": [ "Lawful basis code per category", "Basis reference", "Persistence-after-disposition assessment", "Basis change events" ] }, { "id": "pdl-q3", "text": "Which body is controller and which are processors or joint controllers for this request, including exchange intermediaries?", "kind": "ownership", "answer_data": [ "Controller reference", "Processor references", "Joint controller arrangement reference", "Role effective periods" ] }, { "id": "pdl-q4", "text": "What minimisation was applied - which requested items were reduced, redacted or not collected - and on what assessment?", "kind": "constraint", "answer_data": [ "Minimisation decision record", "Items reduced or omitted", "Assessment reference", "Deciding agent and instant" ] }, { "id": "pdl-q5", "text": "Can the requester exercise data-subject rights over this request record, and how does that interact with the procedure's own retention duty?", "kind": "exception", "answer_data": [ "Rights applicability per right", "Conflict with retention duty description", "Resolution rule", "Handling record reference" ] } ], "data_elements": [ { "id": "de-data-category", "name": "Personal data category", "description": "A category of personal data present in the request, with sensitivity classification and location.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] }, { "id": "de-lawful-basis", "name": "Lawful processing basis", "description": "The basis relied on for processing, per category, with reference and effective period.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-010" ] }, { "id": "de-controller-role", "name": "Controller and processor roles", "description": "Which entity controls and which process the request's personal data, with effective periods.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-002" ] } ], "artifacts": [ { "id": "processing-record-entry-artifact", "name": "Processing record entry for the request category", "description": "The register entry describing purposes, categories, recipients, transfers and retention for requests of this type, which the individual request instance references.", "media_or_form": [ "register entry", "structured processing record" ], "serial": false, "identity_strategy": "Keyed by procedure identifier and register entry version rather than by individual request; each request cites the entry version applicable at its submission instant.", "source_refs": [ "SRC-011", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "access-and-disposition", "name": "Access Control and Disposition", "description": "Who may see the request and its parts, and when and how it is destroyed, transferred or preserved.", "source_refs": [ "SRC-015", "SRC-014", "SRC-013", "SRC-011" ], "findings": [ { "id": "access-control-and-confidentiality", "name": "Access control, confidentiality and public disclosure", "description": "Every managed entity carries an access control list, and request records frequently mix a publicly disclosable shell with confidential content. Access must be expressible at element granularity and must survive export.", "source_refs": [ "SRC-015", "SRC-014", "SRC-011", "SRC-012" ], "questions": [ { "id": "acc-q1", "text": "Who may read, amend and dispose of this request, and at what granularity is that expressed?", "kind": "access", "answer_data": [ "Permission entries by role or agent", "Granularity level (record, element, attachment)", "Grant basis", "Effective period per grant" ] }, { "id": "acc-q2", "text": "Which parts of the request are publicly disclosable and which are withheld, on what stated ground?", "kind": "security", "answer_data": [ "Disclosability marking per element", "Withholding ground code", "Marking agent and instant", "Public version reference" ] }, { "id": "acc-q3", "text": "How does the requester's own access to their request differ from third-party or public access?", "kind": "access", "answer_data": [ "Requester access scope", "Third-party access rule", "Public access rule", "Identity verification requirement per route" ] }, { "id": "acc-q4", "text": "Do access markings and controls travel with the record when it is exported or transferred to another body?", "kind": "interoperability", "answer_data": [ "Control-propagation guarantee", "Markings carried in the export package", "Recipient obligation statement", "Verification on receipt" ] } ], "data_elements": [ { "id": "de-access-control-entry", "name": "Access control entry", "description": "A grant of a named permission to a role or agent over a defined scope, with basis and validity period.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-015" ] }, { "id": "de-disclosability-marking", "name": "Disclosability marking", "description": "Per-element indication of whether content may be disclosed publicly and on what ground it is withheld.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-014" ] } ], "artifacts": [ { "id": "access-control-list-artifact", "name": "Access control list and redaction schedule", "description": "The authoritative statement of who may do what to the request and which elements are redacted for which audience, retained so that historical access decisions remain reconstructible.", "media_or_form": [ "structured permission list", "redaction schedule", "register annotation" ], "serial": false, "identity_strategy": "Bound to the request identifier with a version ordinal; each change appends a new version and the superseded version is retained for audit rather than overwritten.", "source_refs": [ "SRC-015", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "retention-disposition-and-legal-hold", "name": "Retention rule, disposition action and legal hold", "description": "Retention derives from a classification and a disposition authority, not from an ad hoc setting. Requests that never became cases, withdrawn requests and erroneous entries often carry different rules from the case file they would have joined.", "source_refs": [ "SRC-015", "SRC-014", "SRC-013", "SRC-011" ], "questions": [ { "id": "rdh-q1", "text": "Which retention rule applies to this request, from which classification and under which disposition authority?", "kind": "retention", "answer_data": [ "Retention rule reference", "Classification reference", "Disposition authority reference", "Rule version at binding" ] }, { "id": "rdh-q2", "text": "What event starts the retention period, and how is that trigger detected reliably?", "kind": "temporal", "answer_data": [ "Retention trigger event type", "Trigger instant", "Detection mechanism", "Computed disposal-due instant" ] }, { "id": "rdh-q3", "text": "Do withdrawn, refused-at-intake and entered-in-error requests follow the same rule as accepted ones?", "kind": "constraint", "answer_data": [ "Rule variant per disposition code", "Justification for divergence", "Approving authority" ] }, { "id": "rdh-q4", "text": "What disposal actions are permitted, and what evidence of disposal is kept after the content is gone?", "kind": "lifecycle", "answer_data": [ "Disposal action code (destroy, transfer, permanent retention, review)", "Disposal executor and instant", "Residual metadata retained", "Disposal certificate reference" ] }, { "id": "rdh-q5", "text": "How is a legal hold applied and released, and what does it override?", "kind": "exception", "answer_data": [ "Hold identifier and scope", "Applying authority and instant", "Overridden rules", "Release instant and authority" ] } ], "data_elements": [ { "id": "de-retention-rule-binding", "name": "Retention rule binding", "description": "The retention rule inherited from classification, with its version and the disposition authority behind it.", "value_kind": "reference", "cardinality": "1", "required": true, "source_refs": [ "SRC-015", "SRC-014" ] }, { "id": "de-disposal-due-instant", "name": "Disposal-due instant", "description": "Computed instant at which the disposal action becomes due, derived from the trigger and the retention period.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-008" ] }, { "id": "de-legal-hold", "name": "Legal hold", "description": "An active hold suspending disposal, with scope, applying authority and validity period.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015" ] }, { "id": "de-disposal-action", "name": "Disposal action record", "description": "The executed disposal with action code, executor, instant and residual metadata retained.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-014", "SRC-015" ] } ], "artifacts": [ { "id": "disposition-authority-binding-artifact", "name": "Disposition authority binding and disposal certificate", "description": "The record binding the request to its retention rule and disposition authority, and, once executed, the certificate evidencing what was destroyed or transferred, by whom and when.", "media_or_form": [ "schedule binding record", "disposal certificate", "transfer manifest" ], "serial": true, "identity_strategy": "Disposition authority identifier plus request identifier for the binding; the certificate carries its own register serial from the disposal register, which survives destruction of the content.", "source_refs": [ "SRC-015", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "interoperability-and-assurance", "name": "Exchange, Provenance, Measurement and Exceptions", "description": "How the request moves between systems, how its history is attributable, how the intake service is measured, and what happens when things go wrong.", "rationale": "Exchange packaging and naming rules are a distinct governed layer from the semantic record; provenance vocabularies are standardised and should not be reinvented; and public-authority standards require publishing performance data. Exceptions need explicit modelling because degraded intake is where legal deadlines are most often breached.", "source_refs": [ "SRC-016", "SRC-007", "SRC-019", "SRC-005" ], "layers": [ { "id": "exchange-and-interoperability", "name": "Exchange and Interoperability", "description": "Packaging the request for transmission and binding it to external profiles without letting a serialisation become the semantics.", "source_refs": [ "SRC-016", "SRC-006", "SRC-004", "SRC-002" ], "findings": [ { "id": "exchange-packaging-and-profile-binding", "name": "Exchange packaging, profile binding and standards alignment", "description": "The same request may need to appear as a filing message, a service-request resource, an evidence exchange payload or a domain exchange package. These are projections; the model must declare mappings and their loss characteristics rather than adopt any one as its structure.", "source_refs": [ "SRC-016", "SRC-006", "SRC-004", "SRC-005", "SRC-002" ], "questions": [ { "id": "epb-q1", "text": "Which external profiles is this request expected to be expressed in, and which elements have no counterpart in each?", "kind": "interoperability", "answer_data": [ "Target profile references with version", "Element mapping table", "Unmappable element list per profile", "Loss characterisation" ] }, { "id": "epb-q2", "text": "Is a mapping asserted as an alignment or claimed as conformance, and what evidence supports a conformance claim?", "kind": "evidence", "answer_data": [ "Alignment versus conformance marker", "Conformance evidence reference", "Test or certification result", "Assertion date and asserting party" ] }, { "id": "epb-q3", "text": "How are correlation identifiers preserved across an exchange so a response can be matched to the original request?", "kind": "identity", "answer_data": [ "Correlation identifier", "Identifier placement in the package", "Idempotency key", "Retry-safe matching rule" ] }, { "id": "epb-q4", "text": "What happens when the receiving system's profile version differs from the sending system's?", "kind": "exception", "answer_data": [ "Version negotiation rule", "Backward compatibility policy", "Rejection or downgrade behaviour", "Error signalling mechanism" ] } ], "data_elements": [ { "id": "de-profile-binding", "name": "Profile binding", "description": "Declared mapping from this model to an external exchange profile, with version and loss notes.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-016", "SRC-006" ] }, { "id": "de-correlation-key", "name": "Correlation and idempotency key", "description": "Value used to match responses and to make retried submissions safe.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] } ], "artifacts": [ { "id": "exchange-package-artifact", "name": "Request exchange package", "description": "A serialised, profile-conformant projection of the request assembled for transmission to a specific counterparty, retained alongside the semantic record as evidence of what was actually sent.", "media_or_form": [ "structured message", "exchange package", "transport envelope with manifest" ], "serial": true, "identity_strategy": "Request identifier plus counterparty identifier plus transmission sequence number; the exchange system's own message identifier takes precedence as the authoritative key when it issues one.", "source_refs": [ "SRC-016", "SRC-006", "SRC-002" ] } ], "inline_only_rationale": null } ] }, { "id": "assurance-and-quality", "name": "Provenance, Measurement and Exception Handling", "description": "Attributable history, published performance, and defensible behaviour under failure.", "source_refs": [ "SRC-007", "SRC-019", "SRC-005", "SRC-014" ], "findings": [ { "id": "provenance-and-chain-of-custody", "name": "Provenance and chain of custody", "description": "Provenance answers who or what generated each version of the request, from what it was derived, and on whose behalf agents acted. Reusing a standard provenance vocabulary keeps this verifiable across organisational boundaries.", "source_refs": [ "SRC-007", "SRC-014", "SRC-015", "SRC-017" ], "questions": [ { "id": "pcc-q1", "text": "Which activity generated each version of the request record, and which agent was associated with that activity?", "kind": "provenance", "answer_data": [ "Generating activity reference", "Associated agent reference", "Activity start and end instants", "Generated entity version" ] }, { "id": "pcc-q2", "text": "From which prior entities was this request derived - a draft, a previous request, a pre-filled dataset?", "kind": "provenance", "answer_data": [ "Derivation source references", "Derivation type", "Pre-fill source and instant", "Requester confirmation of pre-filled values" ] }, { "id": "pcc-q3", "text": "Where a software agent acted, on whose authority did it act and how is that delegation recorded?", "kind": "authority", "answer_data": [ "Software agent identifier and version", "Delegating agent reference", "Delegation basis", "Delegation validity period" ] }, { "id": "pcc-q4", "text": "Which custody boundaries did the record cross, and was integrity verified at each crossing?", "kind": "quality", "answer_data": [ "Custody transfer events", "Verifying party and method", "Verification result and instant", "Discrepancy record" ] } ], "data_elements": [ { "id": "de-generation-activity", "name": "Generation activity", "description": "The activity that produced a version of the request, with agent, instants and inputs used.", "value_kind": "object", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-007" ] }, { "id": "de-derivation-link", "name": "Derivation link", "description": "Reference to an entity this request or version was derived from, with derivation type.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] }, { "id": "de-delegation-record", "name": "Delegation record", "description": "Assertion that one agent acted on behalf of another, with basis and validity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007" ] } ], "artifacts": [ { "id": "provenance-bundle-artifact", "name": "Provenance bundle", "description": "A self-contained, attributable set of provenance assertions about the request, exportable so that a third party can reconstruct how the record came to be without access to the originating system.", "media_or_form": [ "provenance graph", "structured assertion set", "signed provenance document" ], "serial": false, "identity_strategy": "Named by an IRI derived from the authoritative request identifier; the bundle itself is an entity with its own generation activity and attribution, so it must carry a distinct identifier from the request it describes.", "source_refs": [ "SRC-007", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "performance-measurement-and-reporting", "name": "Intake performance measurement and published reporting", "description": "Public-authority standards require defining what success looks like and publishing performance data. Measurement definitions must be recorded with the request-level facts that feed them, or published figures cannot be reproduced or audited.", "source_refs": [ "SRC-019", "SRC-012", "SRC-002", "SRC-003" ], "questions": [ { "id": "pmr-q1", "text": "Which measures are computed over request records, and from exactly which recorded instants and codes?", "kind": "measurement", "answer_data": [ "Measure definition reference", "Source field list per measure", "Computation formula", "Measurement period definition" ] }, { "id": "pmr-q2", "text": "How is timeliness measured against the statutory period, including suspended and extended cases?", "kind": "measurement", "answer_data": [ "Elapsed time excluding suspensions", "Within-deadline flag", "Extension-adjusted deadline used", "Breach count and reasons" ] }, { "id": "pmr-q3", "text": "Which measures are published, at what aggregation, and how is disclosure of small cohorts prevented from re-identifying requesters?", "kind": "privacy", "answer_data": [ "Published measure list", "Aggregation level", "Suppression threshold rule", "Publication location and cadence" ] }, { "id": "pmr-q4", "text": "How are intake quality problems - rejection rate, deficiency rate, channel abandonment - fed back into the form and rules?", "kind": "quality", "answer_data": [ "Quality indicator values", "Threshold and alert rule", "Improvement action reference", "Review cadence" ] } ], "data_elements": [ { "id": "de-measure-definition", "name": "Measure definition reference", "description": "Pointer to the definition of a computed measure, including its source fields and formula.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019" ] }, { "id": "de-elapsed-processing-time", "name": "Elapsed processing time", "description": "Duration from clock start to disposition, with suspensions excluded, computed from recorded instants.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-008" ] }, { "id": "de-deadline-breach-flag", "name": "Deadline breach indicator", "description": "Whether the applicable deadline was exceeded, with reason where it was.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-012" ] } ], "artifacts": [ { "id": "performance-report-artifact", "name": "Published intake performance report", "description": "The periodic, aggregated report of intake volumes, timeliness, rejection and deficiency rates published for the procedure, together with the measure definitions needed to reproduce it.", "media_or_form": [ "published dataset", "performance dashboard extract", "periodic report document" ], "serial": true, "identity_strategy": "Procedure identifier plus reporting period expressed as an explicit RFC 3339 interval; the period, not the publication date, identifies the report.", "source_refs": [ "SRC-019", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "exception-handling-and-degraded-operation", "name": "Exception handling, outages and erroneous submissions", "description": "Intake fails in specific, foreseeable ways: the channel is unavailable at a deadline, a submission is duplicated by a retry, content is wrong, or an exchange partner is down. Each needs a defined, evidenced treatment because legal consequences attach.", "source_refs": [ "SRC-005", "SRC-002", "SRC-012", "SRC-006" ], "questions": [ { "id": "ehd-q1", "text": "If the submission channel is unavailable at or near a deadline, what fallback exists and how is the outage evidenced?", "kind": "exception", "answer_data": [ "Outage record with start and end instants", "Fallback channel reference", "Deadline relief rule", "Evidence of unavailability" ] }, { "id": "ehd-q2", "text": "How are retried or duplicated submissions distinguished from genuine repeat requests?", "kind": "validation", "answer_data": [ "Idempotency key", "Duplicate detection outcome", "Linkage to the retained original", "Requester notification" ] }, { "id": "ehd-q3", "text": "How is a record that should never have existed marked and treated, and is it destroyed or retained annotated?", "kind": "lifecycle", "answer_data": [ "Entered-in-error marker", "Annotation text and authorising agent", "Retention treatment", "Downstream notification of retraction" ] }, { "id": "ehd-q4", "text": "When an upstream evidence provider or exchange partner fails, what error is surfaced to the requester and what is the recovery path?", "kind": "process", "answer_data": [ "Error code and origin", "Message shown to requester", "Retry policy", "Manual fallback and its clock effect" ] }, { "id": "ehd-q5", "text": "How are partial submissions and abandoned drafts treated - are they records at all?", "kind": "definition", "answer_data": [ "Draft-status definition", "Record-status threshold", "Draft retention period", "Conversion event to a submitted request" ] } ], "data_elements": [ { "id": "de-exception-record", "name": "Exception record", "description": "A captured failure affecting the request, with type, origin, instants, impact and resolution.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-006" ] }, { "id": "de-entered-in-error-flag", "name": "Entered-in-error indicator", "description": "Marks a record created in error, distinct from a properly cancelled or withdrawn request.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "de-outage-relief", "name": "Outage relief determination", "description": "Whether a deadline was relieved because of a channel outage, with basis and authorising agent.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] } ], "artifacts": [ { "id": "exception-record-artifact", "name": "Intake exception record", "description": "The retained record of an outage, duplicate, erroneous entry or partner failure affecting one or more requests, including its impact on deadlines and the relief granted.", "media_or_form": [ "incident record", "structured exception log entry", "service availability statement" ], "serial": true, "identity_strategy": "Exception register serial as the authoritative key, cross-referenced to every affected request identifier; the register is independent of the request so a single outage is recorded once.", "source_refs": [ "SRC-005", "SRC-002" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "submit-request", "name": "Submit request", "description": "Perform the submission act: bind a payload to a procedure, attach evidence, capture the authentication context and create the request record in its initial state.", "inputs": [ "Procedure reference with version", "Declared payload conforming to the form definition", "Party role assignments", "Evidence items or evidence-sourcing authorisation", "Channel reference", "Authentication context where required" ], "outputs": [ "Request record in its initial state", "Submitter-facing reference", "Submission instant and ingestion instant recorded separately", "Initial event history entry" ], "preconditions": [ "The procedure is open for submission at the submission instant", "Any collection approval required for the form is current", "Mandatory items are present or the channel permits staged completion" ], "effects": [ "Creates an immutable as-filed payload version", "Assigns internal surrogate identity pending registration", "Starts provenance with a generation activity attributed to the submitting agent" ], "source_refs": [ "SRC-006", "SRC-001", "SRC-008", "SRC-007" ] }, { "id": "register-and-acknowledge", "name": "Register request and acknowledge receipt", "description": "Enter the request on the register, mint the authoritative identifier and issue the acknowledgement stating the processing period, redress routes and any tacit-approval effect.", "inputs": [ "Submitted request record", "Register configuration", "Applicable processing period and legal basis" ], "outputs": [ "Authoritative request identifier", "Acknowledgement of receipt artefact", "Registration instant", "Tracking reference disclosed to the requester" ], "preconditions": [ "Receipt instant has been captured", "The receiving body accepts the request as within its intake scope, or records that it does not" ], "effects": [ "Fixes the clock-start instant", "Makes the request externally addressable for status query", "Creates the receipt artefact as evidence that the acknowledgement duty was met" ], "source_refs": [ "SRC-003", "SRC-012", "SRC-006" ] }, { "id": "validate-conformance", "name": "Validate technical conformance", "description": "Run structural, code-list, cross-field and cross-record validation against the pinned rule-set version and emit a citable issue list.", "inputs": [ "Request payload and attachments", "Rule set version", "Code system references" ], "outputs": [ "Validation report artefact", "Pass or fail outcome", "Issue list with codes and element locations" ], "preconditions": [ "The form definition version is resolvable", "Referenced code systems are available or a cached snapshot is declared" ], "effects": [ "Records the rule-set version used so the result stays reproducible", "May place the request in a blocked technical state without affecting legal admissibility" ], "source_refs": [ "SRC-006", "SRC-016" ] }, { "id": "screen-completeness", "name": "Screen completeness and determine admissibility", "description": "Assess whether every mandatory requirement is discharged, issue a deficiency notice where it is not, and record the effect on the processing clock.", "inputs": [ "Evidence manifest", "Requirement set from the procedure catalogue", "Fee status", "Identification status" ], "outputs": [ "Completeness determination", "Deficiency notice artefact where applicable", "Cure deadline", "Clock-effect record" ], "preconditions": [ "Registration has occurred", "The requirement set version applicable at submission is resolvable" ], "effects": [ "May suspend the clock on a stated legal basis", "Sets the effective submission instant where it differs from first receipt", "Starts the cure period" ], "source_refs": [ "SRC-003", "SRC-012", "SRC-001" ] }, { "id": "retrieve-authoritative-evidence", "name": "Retrieve evidence from an authoritative source", "description": "On the requester's explicit request, obtain evidence from the competent providing authority, offer preview where required and bind the result to the requirement it discharges.", "inputs": [ "Explicit request record", "Requirement to evidence-type mapping", "Providing authority reference", "Subject identifiers" ], "outputs": [ "Retrieved evidence item with provenance", "Preview outcome record", "Requirement discharge link", "Retrieval activity record" ], "preconditions": [ "An explicit request by the user exists and is in scope", "The requirement is mapped to an available evidence type at the providing authority" ], "effects": [ "Adds evidence without asking the applicant again", "Records the retrieval as a provenance activity with both authorities as agents", "On preview rejection, leaves the requirement undischarged and notifies the requester" ], "source_refs": [ "SRC-002", "SRC-007", "SRC-001", "SRC-017" ] }, { "id": "amend-or-withdraw-request", "name": "Amend, supplement or withdraw the request", "description": "Apply a permitted change class, creating a new version linked by derivation and recomputing any affected dates without erasing prior state.", "inputs": [ "Change class", "Changed payload or evidence", "Requester or authorised representative identity", "Reason" ], "outputs": [ "New version with incremented ordinal", "Supersession and derivation links", "Recomputed effective submission instant and deadline", "Change or withdrawal notice artefact" ], "preconditions": [ "The change class is permitted in the current state", "The acting party holds authority to make the change" ], "effects": [ "Prior version remains immutable and retrievable", "May trigger re-screening and revalidation", "On withdrawal, sets a terminal disposition and determines refund entitlement" ], "source_refs": [ "SRC-003", "SRC-007", "SRC-014", "SRC-005" ] }, { "id": "route-and-assign", "name": "Determine competence, transfer and assign a processing track", "description": "Identify the competent body and component, transfer where necessary preserving the original receipt date, and place the request in a processing track.", "inputs": [ "Request classification and subject matter", "Jurisdictional rules", "Track assignment criteria", "Any expedition request" ], "outputs": [ "Competent body assignment", "Transfer notice artefact where transferred", "Processing track and priority", "Expedition determination" ], "preconditions": [ "The request is registered", "Competence rules for the procedure are resolvable" ], "effects": [ "Carries the original receipt instant forward across transfer", "Constrains the maximum internal transfer window used in clock computation", "Makes queue ordering auditable" ], "source_refs": [ "SRC-012", "SRC-006", "SRC-002" ] }, { "id": "manage-time-limits", "name": "Compute and manage processing time limits", "description": "Derive the deadline from recorded instants and the applicable period, apply suspensions and extensions with notice, and evaluate any expiry consequence.", "inputs": [ "Clock-start instant", "Applicable period, calendar basis and legal basis", "Suspension and extension events", "Tacit-outcome rule" ], "outputs": [ "Current deadline", "Suspension intervals", "Extension grant with justification and notice", "Expiry consequence determination" ], "preconditions": [ "The clock-start instant is fixed and recorded with an explicit offset", "The period is published in advance" ], "effects": [ "Deadline is always recomputable from the event history rather than stored as an unexplained value", "Notice is dispatched before expiry where an extension is taken", "Records a deemed outcome where silence has legal effect" ], "source_refs": [ "SRC-003", "SRC-012", "SRC-008" ] }, { "id": "dispose-request", "name": "Dispose the request by opening a case, fulfilling or refusing", "description": "End the request's own lifecycle by linking a case, recording direct fulfilment, or issuing a reasoned refusal with redress information.", "inputs": [ "Disposition decision", "Case identifier where a case is opened", "Reasons and legal basis where adverse" ], "outputs": [ "Disposition code and instant", "Case reference or outcome reference", "Reasoned determination and redress notice artefact" ], "preconditions": [ "Admissibility has been determined", "Where adverse, the requester has had any applicable opportunity to be heard" ], "effects": [ "Transfers substantive handling to the neighbouring case model", "Starts the redress clock from the notification instant", "Typically starts the retention clock for the request record" ], "source_refs": [ "SRC-018", "SRC-006", "SRC-003" ] }, { "id": "export-exchange-package", "name": "Export a profile-conformant exchange package", "description": "Project the request into a declared external profile for transmission, preserving correlation identifiers, access markings and integrity values.", "inputs": [ "Request record and selected elements", "Target profile and version", "Counterparty reference", "Disclosability markings" ], "outputs": [ "Exchange package artefact", "Correlation and idempotency keys", "Mapping loss statement" ], "preconditions": [ "A declared mapping to the target profile exists", "The requester or legal basis permits disclosure to the counterparty" ], "effects": [ "Records exactly what was sent, to whom and when", "Carries access markings and recipient obligations with the package", "Does not alter the semantic record, which remains format-neutral" ], "source_refs": [ "SRC-016", "SRC-006", "SRC-002" ] }, { "id": "apply-retention-and-disposition", "name": "Apply retention rule and execute disposition", "description": "Bind the request to its retention rule via classification, detect the retention trigger, honour any legal hold and execute the due disposal action with evidence.", "inputs": [ "Classification assignment", "Disposition authority", "Retention trigger event", "Active legal holds" ], "outputs": [ "Retention rule binding", "Disposal-due instant", "Disposal action record and certificate", "Residual metadata retained after destruction" ], "preconditions": [ "A disposition authority covering this record class is in force", "No unreleased legal hold applies to the scope" ], "effects": [ "Destroys, transfers or permanently retains content per the authorised action", "Preserves disposal evidence after the content is gone", "Applies variant rules to withdrawn, refused and erroneous requests where authorised" ], "source_refs": [ "SRC-015", "SRC-014", "SRC-013" ] }, { "id": "retract-erroneous-record", "name": "Mark a record entered in error and retract downstream", "description": "Distinguish a record that should never have existed from a properly cancelled one, annotate it, and notify downstream consumers of the retraction.", "inputs": [ "Erroneous record reference", "Authorising agent", "Reason and evidence" ], "outputs": [ "Entered-in-error marker and annotation", "Retraction notifications to known consumers", "Event history entry" ], "preconditions": [ "An authorised agent has determined the record is erroneous", "Downstream consumers of the record are identifiable from the exchange history" ], "effects": [ "Preserves the original for audit rather than deleting it, unless disposal is separately authorised", "Excludes the record from performance measures with the exclusion recorded", "Prevents silent divergence between the master record and previously exported copies" ], "source_refs": [ "SRC-005", "SRC-014", "SRC-007" ] }, { "id": "transition-request-status", "name": "Transition intention status", "description": "Move request status among draft, active, on-hold, revoked, completed, entered-in-error or unknown with a recorded reason, without encoding fulfilment work.", "inputs": [ "application identifier", "target status", "status reason", "actor" ], "outputs": [ "updated status", "provenance event" ], "preconditions": [ "transition is legal from current status", "actor authorised" ], "effects": [ "authorisation/intention state changes", "fulfilment tasks if any are not implicitly completed" ], "source_refs": [ "SRC-022", "SRC-021" ] } ], "composition": [ { "target": "WM-REC-007", "relation": "EXTEND", "purpose": "Specialise the generic record model for the request case. Record characteristics, base metadata and the record/agent/business/mandate/relationship entity view are inherited, not restated here.", "required": true, "source_refs": [ "SRC-014", "SRC-013" ] }, { "target": "WM-POL-017 (Administrative case)", "relation": "REFERENCE", "purpose": "Record the handover: the case identifier created when the request is admitted, and the typed relation between request and proceeding. The registry records WM-POL-017 as composing this model; from the request side the case is a forward reference, and it is optional because a request may be fulfilled or refused without opening a case.", "required": false, "source_refs": [ "SRC-018", "SRC-006" ] }, { "target": "Public service / procedure catalogue model (CPSV-AP aligned)", "relation": "ALIGN", "purpose": "Resolve the procedure, its Requirements, Evidence types, Channels, Costs, Rules and Outputs. This model instantiates catalogue definitions and must cite the catalogue version rather than copy the definitions.", "required": true, "source_refs": [ "SRC-001", "SRC-002" ] }, { "target": "Party / agent model (natural person and organisation)", "relation": "REFERENCE", "purpose": "Resolve submitter, subject, representative, payer and notified-party references to governed party identities without embedding master data in the request.", "required": true, "source_refs": [ "SRC-013", "SRC-004" ] }, { "target": "Evidence / document record model", "relation": "COMPOSE", "purpose": "Attach and reference evidence items whose content model, format and preservation are governed elsewhere; this model contributes the requirement-discharge link, sufficiency judgement and integrity values.", "required": false, "source_refs": [ "SRC-001", "SRC-017" ] }, { "target": "Identity and trust-service model (authentication and assurance)", "relation": "MIX-IN", "purpose": "Supply the authentication context and assurance level observed at the submission act, and validate signatures and seals against trust anchors, without duplicating credential lifecycle management.", "required": false, "source_refs": [ "SRC-002", "SRC-017" ] }, { "target": "Provenance mixin (PROV-aligned)", "relation": "MIX-IN", "purpose": "Provide Entity/Activity/Agent, generation, derivation, attribution, association and delegation terms for the event history and provenance bundle rather than defining a bespoke audit vocabulary.", "required": true, "source_refs": [ "SRC-007" ] }, { "target": "Retention schedule and disposition authority model", "relation": "REFERENCE", "purpose": "Inherit the retention rule from a classification under a named disposition authority, and record holds and executed disposal actions against that authority.", "required": true, "source_refs": [ "SRC-015", "SRC-014" ] }, { "target": "Payment / fee transaction model", "relation": "REFERENCE", "purpose": "Link the fee assessment and its admissibility effect to the payment transaction, whose execution, settlement and refund mechanics are out of scope here.", "required": false, "source_refs": [ "SRC-006", "SRC-012" ] }, { "target": "Decision / authorisation outcome record model", "relation": "REFERENCE", "purpose": "Point to the grant, refusal, permit or award produced, which carries its own identity, effective dates and appeal window.", "required": false, "source_refs": [ "SRC-001", "SRC-003" ] }, { "target": "Appeal / complaint record model", "relation": "REFERENCE", "purpose": "Link a challenge lodged against an intake refusal or adverse determination; the appeal is a distinct triggering record with its own lifecycle.", "required": false, "source_refs": [ "SRC-003" ] }, { "target": "Exchange profile bindings (domain exchange package, filing message, service-request resource)", "relation": "ALIGN", "purpose": "Declare mappings to external serialisation profiles as alignments with stated loss characteristics. Conformance is claimed only where test or certification evidence exists.", "required": false, "source_refs": [ "SRC-016", "SRC-006", "SRC-004", "SRC-005" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "A single accountable owner package must be named for WM-REC-009, holding the record owner or records-management authority role recorded in the registry, and must publish the procedure-to-model bindings it governs.", "The owner package must declare, per adopting jurisdiction, which processing periods, calendar bases, tacit-outcome rules and disposition authorities are in force, and the effective period of each, because these are the values that make the model operable rather than descriptive.", "The owner package must maintain the alignment register of external profile bindings with version, mapping table and loss statement, and must mark each entry as alignment or evidenced conformance.", "The owner package must not redefine concepts owned by the composable siblings named in the composition links; it may only add request-specific constraints and must record any such constraint with its legal or policy basis.", "The owner package must publish a change log for the model and for each catalogue binding, so that a request can always be interpreted under the rules in force at its submission instant." ], "namespace_guidance": "Use one stable namespace for the model's own terms, distinct from any adopting organisation's namespace and from any serialisation namespace. Do not mint local terms where a governed external term exists: reuse provenance terms from the PROV namespace, timestamp forms from RFC 3339, and catalogue terms from the public-service application profile. Local identifiers within the model are lower-kebab-case and stable for the life of the model; retired terms are deprecated with a successor pointer rather than removed or reused.", "registry_links": [ "vr.wm-rec-009 is the registry entry of record; nav path NAV.INF.REC.APP and domain tags INF.REC.APP are the navigational keys.", "Parent link to WM-REC-007 must resolve before this model is treated as complete, since base record semantics are inherited rather than defined here.", "The inbound COMPOSE relation from WM-POL-017 must be kept consistent with the outbound REFERENCE declared here; the pair is the single boundary and must not be duplicated as two independent relations.", "External registry links required for operation: the procedure or public-service catalogue, the party register, the classification and disposition-authority register, and the code systems used for status, disposition and error codes." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is the semantic record, not any serialisation. JSON, YAML, Markdown, HTML, Git, MCP and MongoDB projections must be derivable from it and must not carry meaning absent from it.", "All timestamps are canonicalised to RFC 3339 with seconds and an explicit offset or Z. Where an original local offset carries legal meaning, the original offset is preserved rather than normalised to UTC, and any UTC form is stored as a derived value.", "Identifier values are canonicalised with their scheme and issuing authority; a bare identifier string without a scheme is not canonical and must not be used for matching.", "Coded values are canonicalised as a code plus its code-system reference and, where the system is versioned, the system version in force at the instant the code was assigned.", "Derived values - deadlines, elapsed times, breach flags, completeness state - are recomputable from the event history. Where a derived value is materialised it must record the inputs and the rule version used, and it is never authoritative over the history." ], "patch_rules": [ "Changes to a submitted request are expressed as new versions with derivation links, never as in-place mutation of the as-filed payload.", "A patch must state the change class (correction, amendment, supplementation, withdrawal, retraction) because each class has a different effect on the effective submission instant and the clock.", "Patches to model structure are additive by default: new bundles, layers, findings, questions, data elements and artefacts may be added at any time; removal or narrowing requires a compatibility assessment and a deprecation period.", "Every patch records the acting agent, the authorising basis, the event instant and the recording instant separately.", "A patch that changes the meaning of an existing identifier is prohibited; mint a new identifier and deprecate the old one with a successor pointer." ], "compatibility_rules": [ "Consumers must tolerate unknown additional elements and must not treat their presence as an error, so that additive change does not break existing readers.", "Removing a required data element, tightening a cardinality, or changing a code system binding is a breaking change and requires a new major version of the model.", "External profile bindings are versioned independently of the model; a profile version change never silently changes model semantics.", "A request must remain interpretable under the model version and the catalogue version in force at its submission instant, for at least as long as its retention period.", "Conformance to an external standard is claimed only where test or certification evidence is recorded; otherwise the relationship is recorded as an alignment." ] }, "artifact_rules": { "identity_priority": [ "First: the identifier assigned by the authoritative master system for that artefact class - the register serial for a receipt or disposal certificate, the filing or case identifier from the intake register, the assertion identifier from the identity provider, the message identifier from the exchange system.", "Second: a governed global identifier or IRI from a recognised scheme, used where the artefact must be resolvable outside the issuing organisation - for example an IRI for a provenance bundle or a governed evidence-type identifier.", "Third: a UUID or ULID assigned by the adopting Dimension at capture, preferring a time-ordered form for records that are inserted in sequence, and always paired with the request identifier it belongs to.", "A date, a period, a filename, a display label or a content digest is not an identifier. A digest may serve as a tamper-evident secondary key but never as the primary identity, since identical content can be submitted twice for different requests.", "Where several identifiers exist, exactly one is designated authoritative and the others are recorded as alternates with scheme, issuer and role." ], "timestamp_rule": "All recorded instants use RFC 3339 date-time with seconds and an explicit UTC offset or Z. Event time and observation or ingestion time are recorded as separate values on every event; where they are equal that equality is asserted, not assumed. Submission, receipt, component-receipt, registration and ingestion instants are distinct fields and must never be collapsed into one, because different legal effects attach to different ones. Durations and retention periods are expressed as explicit intervals or durations with a stated calendar basis (working days or calendar days), never as bare day counts.", "serial_naming_rule": "Artefacts issued in a numbered series - receipts, deficiency notices, deadline and extension notices, transfer notices, determination and redress notices, fee assessments, validation reports, exchange transmissions, exception records, performance reports - carry the authoritative request identifier plus a monotonically increasing sequence number scoped to that request and artefact class, together with the RFC 3339 issue instant. Where an independent register exists (correspondence, disposal, exception, exchange), that register's serial is authoritative and the request-scoped sequence is an alternate. Performance reports are serialised by explicit reporting interval rather than by publication date. Sequence numbers are never reused, and a gap is a defect to be investigated rather than silently closed.", "integrity_rule": "Every artefact records a content digest with a named algorithm and the instant the digest was computed, taken at capture rather than on demand. Artefacts that constitute evidence of the submission act - the as-filed payload, the sealed submission package, the acknowledgement, the event history and the disposal certificate - are immutable once captured; corrections are appended as new versions with derivation links and the superseded version is retained. Integrity is re-verified at every custody boundary crossing and on a scheduled cycle, with each verification result and its instant recorded. Where signatures or seals may become cryptographically obsolete before the retention period ends, a renewal or evidence-record strategy is declared at capture, not deferred." }, "policies": [ "Format neutrality: no storage or interface choice may add, remove or reinterpret meaning. If a fact cannot be expressed in the semantic record it does not exist in the model, regardless of what a projection can carry.", "Evidence over assertion: a structural node, a conformance claim or a legal duty stated in this model must trace to a cited source. Where support is absent the node is marked as a gap rather than presented as canonical.", "Separation of receipt from admission: acknowledging that a request was received never implies that it is complete, admissible or will be granted, and the two determinations are recorded independently with their own agents and instants.", "Non-destruction of prior state: no operation may erase what was submitted, when it was received, or what was decided. Correction, withdrawal and retraction are additive events; only an authorised disposition action under a disposition authority may destroy content.", "Proportionate identification: identity verification demanded of a requester must be proportionate to the risk and must not become a barrier to exercising a right or accessing a service.", "Channel equivalence: the substantive outcome, deadlines and rights attaching to a request must not depend on the channel used, and any channel-dependent rule must be declared with its basis.", "Boundary discipline: concepts owned by a composable sibling are referenced, never copied. A duplicated definition is treated as a defect in this model, not as redundancy.", "Applications containing personal data are processed under specified purposes, data minimisation, accuracy, storage limitation, and integrity/confidentiality, with the controller able to demonstrate compliance.", "Capture as a record is mandatory once the lodging is accepted for business use; draft proposals may exist pre-capture under explicit policy.", "Once-only reuse SHALL be preferred over re-collection where a legal and technical path exists, with exchange provenance retained.", "Disposal follows the records schedule and does not silently defeat evidential retention or GDPR archival safeguards." ], "crud": { "read": [ "Read of the request record resolves the semantic record; any serialisation returned is a projection and must be labelled with the profile and version it conforms to.", "Status queries must remain answerable after disposition for a declared period, returning at minimum the status, the receipt instant and the estimated or actual completion date.", "Reads are filtered by the access control list at element granularity; withheld elements are reported as withheld with a ground rather than silently omitted, so that absence is never mistaken for non-existence.", "Reads that disclose personal data to anyone other than the requester are logged with the reader, purpose and instant.", "Bulk and analytical reads use aggregated or minimised projections with a suppression threshold, and must not be used to reconstruct individual requesters." ], "create": [ "Creation requires a resolvable procedure reference and version, a party role assignment identifying at least the submitter, and the channel.", "Creation records the submission instant and the ingestion instant separately at the moment of capture, each with an explicit offset.", "Creation is idempotent under a declared idempotency key so that transport retries do not produce duplicate requests.", "Creation of a request on behalf of another party requires an evidenced mandate with a scope covering the procedure and a validity window covering the submission instant.", "A draft below the declared record threshold is not a request; conversion to a submitted request is an explicit event with its own instant." ], "update": [ "The as-filed payload is never updated in place; accepted changes create a new version with a derivation link and an incremented ordinal.", "Every update records the change class, the acting agent, the authorising basis and both the event and recording instants.", "Updates that could affect admissibility, the effective submission instant or the deadline must trigger recomputation and, where the result changes, notification of the requester.", "Status changes are permitted only along declared transitions by an authorised role, and a status reason is required for every non-obvious state.", "Updates to access markings append a new version of the access control list; superseded versions are retained for audit." ], "delete": [ "Deletion is not an ordinary operation. Content is removed only by an authorised disposal action under a named disposition authority, or where a superior legal duty to erase applies and is recorded with its basis.", "No disposal may execute while an unreleased legal hold covers the scope; the hold, its applying authority and its release are all recorded.", "Disposal leaves residual evidence - a disposal certificate and minimal metadata - that survives destruction of the content and is itself retained under the register's own rule.", "A record marked entered in error is annotated and retained by default, not deleted, and is excluded from performance measures with the exclusion recorded; deletion of such a record requires separate authorisation.", "Where content has been exported, disposal must be accompanied by retraction notifications to known recipients, since destroying the master copy alone does not dispose of the record." ] }, "roles": [ { "name": "Record owner / records-management authority", "responsibilities": [ "Hold accountability for WM-REC-009 as registered, including its scope, boundaries and change log", "Approve classification, retention rules and disposition authorities applied to request records", "Authorise disposal actions and the application and release of legal holds", "Ensure the record retains authenticity, reliability, integrity and usability for its full retention period" ] }, { "name": "Intake / registry officer", "responsibilities": [ "Register incoming requests, mint authoritative identifiers and issue acknowledgements within the required period", "Determine completeness and admissibility, issue deficiency notices and record the clock effect", "Determine competence, transfer misdirected requests preserving the original receipt date, and assign processing tracks", "Maintain the correspondence and exception registers and investigate serial gaps" ] }, { "name": "Data protection and information-rights officer", "responsibilities": [ "Record lawful basis, controller and processor roles and minimisation decisions for each procedure", "Set access markings and disclosability rules, including the split between public and withheld content", "Handle data-subject rights exercised over request records and resolve conflicts with retention duties", "Review published performance data for re-identification risk and set suppression thresholds" ] }, { "name": "Model steward / interoperability architect", "responsibilities": [ "Maintain the alignment register of external profile bindings with versions, mapping tables and loss statements", "Distinguish alignment from evidenced conformance and refuse unsupported conformance claims", "Govern additive change, deprecation and major-version decisions under the compatibility rules", "Keep boundaries with WM-REC-007, WM-POL-017 and the composable siblings free of duplicated definitions" ] }, { "name": "Service owner", "responsibilities": [ "Publish the procedure definition, processing periods, fees and channels in advance and keep them versioned", "Define what success looks like for intake and publish the resulting performance data", "Ensure channel equivalence and accessibility, including assisted and non-digital routes", "Own the fallback arrangements and deadline-relief rules for channel outages" ] }, { "name": "Automation / agent operator", "responsibilities": [ "Register software agents acting on requests, with version and the delegation basis under which they act", "Ensure automated actions are attributed and recorded with both event and recording instants", "Enforce idempotency on submission and exchange so retries never create duplicate records", "Escalate to a human role any determination that is adverse to the requester or that alters a legal deadline" ] } ], "access": { "default_rule": "Deny by default. Access is granted only by an explicit, time-bounded entry in the request's access control list, scoped to a named permission and a defined element scope, and justified by a recorded basis. The requester and any evidenced representative hold read access to their own request by default; everyone else, including other components of the same body, requires an explicit grant.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "The requester and an evidenced representative may read the request and its status without a discretionary grant, subject to proportionate identification.", "Statutory disclosure duties - public registers, information-access regimes, oversight and audit bodies, judicial orders - override the default deny, but each disclosure is recorded with its legal basis, recipient, scope and instant.", "Emergency or safeguarding access may be granted ahead of the normal approval path, but must be time-boxed, notified to the information-rights role and reviewed after the fact.", "Aggregated, suppression-thresholded statistics may be published without per-request grants, provided small cohorts cannot re-identify requesters.", "Withheld elements are reported as withheld with a ground rather than omitted, so that a partial read never misrepresents the record as complete.", "Sealed filings (minors, protected identities, whistleblowing) hide subject identity from general processors.", "Law-enforcement or court overlays may freeze disposal and widen or narrow access under a recorded legal basis.", "Once-only providing authorities see evidence-request metadata, not necessarily the full application." ], "audit_requirements": [ "Every access decision - grant, denial, exception invocation - is logged with the acting agent, the scope, the basis, the event instant and the recording instant.", "Access to elements marked as special-category or otherwise heightened-risk personal data is logged with the stated purpose, not only the identity of the reader.", "Access control list changes are versioned and the superseded version is retained; the audit trail must be able to answer who could see what at any past instant, not only who could see what now.", "Export and transmission events record the recipient, the elements included, the access markings carried and the recipient's obligations, so that retraction can reach every copy.", "Audit records are append-only and are retained at least as long as the request content; where their retention diverges, the divergence and its justification are recorded explicitly.", "Log create, read of classified evidence, status change, amendment, evidence add/remove, case link, exchange, and disposal with agent, action, object and RFC 3339 time.", "Retain audit logs at least as long as the application record or as required by the controller's accountability policy, whichever is longer." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Model ID and registry ID (WM-REC-009 / vr.wm-rec-009)", "Model version and effective date", "Owner and contact for the record-owner role", "Boundary statement naming WM-REC-007 as parent and WM-POL-017 as the case neighbour", "Jurisdiction and regional profile in force, with processing periods and calendar basis", "Timestamp and identifier rules in force (RFC 3339 with explicit offset; identity priority order)", "Known gaps, conflicts and unresolved boundaries" ], "read_order": [ "AGENTS.md first, to resolve the model's name, type and the four URLs before any other action", "Specification URL, to load the semantic model: scope, boundaries, bundles, layers, findings and data elements", "Storage type URL, to learn how the semantic record is projected into the deployed store, and to confirm that the projection adds no meaning", "Interface URL, to learn the available read, create, update and disposal operations and their preconditions", "Processes URL, to learn the operational functions, their preconditions and effects, and the escalation points that require a human role", "The jurisdiction and regional profile section, before computing any deadline, fee or retention date", "The known gaps and conflicts section last, before acting, so that unsupported structure is not treated as canonical" ] } }, "coverage": { "claim": "Covers the intake-to-handover surface of an application/request record: identity and typing, parties, representation and identity assurance, declared content and evidence sufficiency, completeness/admissibility and technical validation, submission-receipt-capture instants, status and permitted change, statutory clocks, routing and disposition, legal basis, fees, applicant rights, privacy, access, retention, exchange, provenance, measurement and exception handling — with eligibility-criteria evaluation, triggering life/business events, reported third-party capture and place-of-lodgement added from grok. Not universal: jurisdiction-specific procedural detail is representative only; competitive-selection, IP-filing, batch/M2M intake and capacity/duress profiles are unvalidated; several ISO texts were reached at abstract or committee-summary level only.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Identifier set, minting event, naming authority, correlation and duplicate handling are modelled explicitly, with the three-tier identity priority stated in the artefact rules and grounded in a filing-system tracking identifier, a statutory tracking-number duty and the UUID standard's own guidance against name-based keys. The rule that a date is not an identifier is enforced in artifact_rules." }, { "dimension": "lifecycle", "status": "covered", "notes": "Status set with terminal states, permitted transitions with authorised actors, status reason, business status distinct from technical status, amendment and withdrawal classes, supersession, and disposition into a case or closure. Grounded in an independently governed task state set and a filing review/docketing flow rather than invented." }, { "dimension": "relationships", "status": "covered", "notes": "Party role assignments, representation and delegation, requirement-to-evidence discharge links, derivation and supersession, request-to-case cardinality including split and consolidation, and twelve typed composition links to sibling models." }, { "dimension": "temporal", "status": "covered", "notes": "Five distinct instants are separated (submission, receipt, component receipt, registration, ingestion); event time and recording time are separate on every event; clocks, tolling, extension, tacit outcomes and estimated completion dates are modelled; all instants require RFC 3339 with seconds and explicit offset, with original offsets preserved where legally meaningful." }, { "dimension": "provenance", "status": "covered", "notes": "Generation, derivation, attribution, association and delegation are taken from a W3C recommendation rather than reinvented; an exportable provenance bundle is defined as an entity with its own identity; chain-of-custody verification at boundary crossings is required." }, { "dimension": "ownership", "status": "covered", "notes": "Record owner, competent body assignment with effective periods, controller and processor roles including exchange intermediaries, responsible party for declarations, and six governance roles with responsibilities." }, { "dimension": "validation", "status": "covered", "notes": "Technical conformance is separated from legal admissibility as two gates with distinct artefacts, agents and consequences; rule-set versioning makes results reproducible; deficiency notices carry cure deadlines and a stated clock effect." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with element-granularity ACL entries, requester self-access as a named exception, withheld-not-omitted reporting, disclosability markings that travel with exports, and audit requirements able to reconstruct historical permissions." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Retention inherited from classification under a named disposition authority, trigger detection, variant rules for withdrawn, refused and erroneous requests, legal hold and release, disposal certificate surviving destruction, and retraction notification to known export recipients." }, { "dimension": "interoperability", "status": "covered", "notes": "Profile bindings declared as alignments with mapping tables and loss statements; conformance claimed only on recorded test or certification evidence; correlation and idempotency keys; version-negotiation behaviour on profile mismatch; explicit statement that serialisations are projections." }, { "dimension": "completeness and admissibility", "status": "covered", "notes": "Modelled as a first-class determination distinct from receipt and from validation, with the notice duty, cure period, clock effect and non-cure disposition, grounded in a directive article and a statutory tolling regime from two independent jurisdictions." }, { "dimension": "authority and legal basis", "status": "covered", "notes": "Mandate for the procedure, authority to collect the information, mandatory-versus-voluntary marking with consequences, collection approval and expiry, and burden estimates. The collection-approval element is the weakest-sourced item here." }, { "dimension": "measurement", "status": "covered", "notes": "Measure definitions bound to the exact source instants and codes, suspension-adjusted timeliness, publication with suppression thresholds, and feedback of intake quality indicators into form and rule change." }, { "dimension": "privacy", "status": "covered", "notes": "Data categories with sensitivity, lawful basis per category and its persistence after disposition, controller/processor allocation, minimisation decisions, proportionate identification, and the conflict between data-subject rights and retention duties." }, { "dimension": "security and non-repudiation", "status": "covered", "notes": "Signature and seal validation with trust anchors and validation instant, fixity at capture with scheduled re-verification, immutability scope at capture, and a declared strategy for cryptographic obsolescence within the retention period." }, { "dimension": "accessibility and channel equity", "status": "covered", "notes": "Channel equivalence as a policy, cross-border access with foreign identity means, assisted and non-digital routes, reasonable adjustments, and channel-dependent rules requiring a declared basis. Sourced from a public-authority service standard and single-market law rather than from an accessibility standard." }, { "dimension": "exception handling", "status": "covered", "notes": "Outages with deadline relief, retry and duplicate detection, entered-in-error distinct from cancellation, upstream partner failure with fallback and clock effect, and the draft-versus-record threshold." }, { "dimension": "spatial", "status": "not-applicable", "notes": "Location matters here only derivatively - as jurisdiction, competence and territorial scope, all covered under authority and routing. A request record has no intrinsic geometry, so no geometry-valued elements are defined. Procedures whose subject is a place (planning, licensing of premises) carry that geometry on the subject or the case, not on the request." }, { "dimension": "measurement units and quantities", "status": "covered", "notes": "Fees carry amount and currency; durations carry an explicit calendar basis; burden estimates carry time and cost. No bare numeric quantities are defined without a unit or basis." }, { "dimension": "evidence sufficiency", "status": "covered", "notes": "Evidence is bound to the requirement it discharges rather than merely attached, with validity checked at the instant of reliance, alternatives and substitution decisions recorded, and authoritative retrieval carrying its own provenance and preview outcome." } ], "known_omissions": [ "Substantive adjudication, deliberation, hearings and the reasoning of the deciding body are excluded by design and belong to WM-POL-017; if that model does not in fact cover them, the gap is real but is not this model's to fill.", "No accessibility standard was cited directly. Accessibility obligations are asserted from a public-authority service standard and from single-market access law, not from a conformance standard, so the accessibility finding is weaker than the others.", "Collection-approval mechanics (control numbers, expiry, public-protection effects) are modelled generically from a records-metadata frame; the specific US Paperwork Reduction Act instrument could not be retrieved live because the federal regulations site refused automated access, so that element is generic rather than jurisdiction-grounded.", "Patent, trademark and other intellectual-property filing regimes were not examined. They add priority dates, filing-date accord rules and international phase transitions that would likely require a dedicated sibling profile rather than fitting this model unchanged.", "Procurement tender submission, grant application scoring and examination or admissions applications were not examined. Competitive selection introduces sealed-bid opening rules, comparative ranking and cohort deadlines that this model does not currently express.", "Emergency and verbal requests captured by a third party on the requester's behalf, and requests made under duress or by a person lacking capacity, are only partially addressed through the representation finding.", "Machine-to-machine bulk submission (batch filing, API-first intake at volume) is addressed only through idempotency and exchange packaging; batch-level acceptance semantics, partial-batch failure and batch receipt are not modelled.", "No formal state-machine specification is given for the status model: the finding requires a declared transition set but the model does not fix one, because the defensible transition sets differ by regime.", "Cost and effort of operating the model - storage volumes for immutable versioning, and the practical burden of element-granularity access control - are not assessed.", "Full ISO 15489-1:2016 and ISO 23081-1:2017 clause text was not retrieved (ISO OBP served unrelated documents); capture/authenticity/disposal semantics rely on ISO/TC 46/SC 11 first-party summaries.", "CMMN CaseFileItem lifecycle states beyond Available and Discarded (clause 8.3) were not fully enumerated from the PDF extract; remaining states are a gap.", "National administrative-procedure acts (US APA, member-state APAs), MoReq2010, ICA Records in Contexts, NIEM petition/application exchanges, and ITIL service-request definitions were not fetched and are not claimed.", "SDG Article 14 body text was only partially recovered (title and once-only framing); implementing regulation (EU) 2022/1463 OOTS details are omitted.", "Legal capacity of minors, deceased applicants, anonymous/whistleblower lodgements, quota/lottery allocation, and FOI/SAR as request types lack primary support here.", "Qualified electronic signature profiles (eIDAS) are implied by channel evidence variance but not modelled from an eIDAS primary text.", "Fee payment and refund as a condition of admissibility is only present as CPSV-AP Cost, not as a financial transaction model." ], "conflicts": [ "The two most direct legal sources disagree on the clock-start rule. One regime starts the period from receipt by the authority with a duty to notify missing documents promptly and state the effect on the period; another starts it from receipt by the proper component, no later than ten days after initial agency receipt, and permits tolling only to seek clarification or resolve fees. The model therefore records clock-start as a declared, jurisdiction-scoped selection rule rather than a fixed value.", "Tacit authorisation is regime-specific. Silence produces a deemed grant in some authorisation procedures but a continuing duty to decide, or a deemed refusal, elsewhere. The model carries an explicit tacit-outcome indicator rather than assuming any default.", "Request status vocabularies conflict across the cited standards: a health task state set, a filing accepted/rejected/docketed progression, and administrative admissible/inadmissible language are not mutually mappable without loss. The model requires a governed local state set plus declared mappings, and refuses to adopt any one vocabulary as canonical.", "Identification requirements pull in opposite directions. Assurance frameworks push toward higher-assurance authentication, while data-protection authorities hold that identification must be proportionate and must not become a barrier to exercising a right. The model records assurance as an observed fact and proportionality as a policy, and does not resolve the tension in general.", "The GDPR text available live was the UK-assimilated version, which has diverged from the EU original in article structure and in some rights. Article 12 duties relied on here are stable across both, but the model must not be read as asserting EU-text conformance on the basis of that source.", "Records standards require preservation and defensible disposal, while erasure rights and data-minimisation duties can require earlier deletion. The model surfaces this as an explicit question rather than asserting that retention duties always prevail.", "Whether the acknowledgement of receipt is legally constitutive or merely evidential differs by regime; the model treats it as evidential and separately records the registration event that has constitutive effect where one exists.", "FHIR Request.status is authorisation/intention, not fulfilment; many administrative systems encode received/under-review/decided on the application itself — both views must be stored if used, with canonical declared.", "CPSV-AP Public Service exists whether used or not; conflating catalogue status with application status is a modelling error.", "GDPR storage limitation versus ISO 15489 evidential retention: archival/research exception exists but is not automatic; Dimensions must record which clock wins.", "Channel-level hasInput versus service-level hasInput can disagree; CPSV-AP says use channel level only when evidence truly varies.", "CMMN CaseFileItem discard does not equal records destruction or FHIR entered-in-error.", "This model aligns to the cited standards; it does not claim conformance to any of them." ], "regional_assumptions": [ "The strongest procedural duties cited - prompt acknowledgement stating the period, redress routes and tacit-approval effect; fixed pre-published periods; one justified extension with prior notice; prompt notification of missing documents - come from EU single-market law and are assumed, not established, to have analogues elsewhere.", "Two EU acts were read from a UK national mirror rather than the Official Journal. The substantive text relied on is stable, but any claim of exact EU-text conformance would need verification against the OJ.", "Cross-border evidence retrieval with explicit request and preview reflects an EU once-only arrangement. Jurisdictions without such a system will have no explicit-request or preview artefacts, and the corresponding findings degrade to inline evidence supply.", "The tracking-number duty, the twenty-working-day determination with tolling, and multitrack and expedited processing are US federal information-access mechanics used here as a counterexample regime. They are not general requirements.", "Working-day versus calendar-day computation, public holidays, deadline-day cut-off times and out-of-hours submission treatment vary by jurisdiction and are left as declared configuration.", "The model assumes a legal system in which an adverse intake determination is challengeable and reasons are owed. Where that is not so, the rights findings will be present but unused.", "Language and translation obligations are assumed to be procedure-specific; no multilingual default is asserted.", "CPSV-AP, CCCEV, SDG and GDPR are European Union instruments; competent-authority language cites the Services Directive 2006/123/EC as reused by CPSV-AP.", "FHIR ServiceRequest examples are healthcare-centric; the Request pattern is used here as a cross-domain analogue, which HL7 presents as informative, not a universal civic-application schema.", "ISO 15489 and CMMN are treated as globally applicable records and case frames.", "Once-only cross-border exchange applies to SDG in-scope procedures among participating states; other jurisdictions need a local reuse policy.", "Administrative-region spatial values in Europe are expected to use ATU or equivalent named-authority lists per CPSV-AP guidance." ], "adversarial_checks": [ "Is the request record distinguishable from the case it opens? Tested against a case-modelling standard: case content, stages, milestones and plan items are modelled separately from the intake artefact, and the model stops at an explicit disposition event carrying a case reference. The boundary holds, but it is the model's most fragile edge - if an adopting organisation treats the application form as the case file, the two models will overlap in practice regardless of what the specification says.", "Is the request record distinguishable from an incident? Tested against service-management practice, where a service request is a pre-defined, pre-approved ask and an incident is an unplanned interruption. They are separate resolution flows and are recorded as separate triggers, so a fault report must not be forced into this model.", "Does any structural node lack primary support? Every bundle, layer and finding cites at least one source and most cite three or more. The weakest are the collection-approval element, whose specific statutory instrument could not be retrieved live, and the accessibility content, which rests on a service standard rather than a conformance standard. Both are recorded as omissions rather than presented as canonical.", "Does the model smuggle in a storage or interface assumption? Checked deliberately: no finding requires a file, a document, a table or an endpoint. Artefacts are described by form and identity strategy, never by media type or serialisation, and the canonicalisation rules state that the semantic record is authoritative over every projection.", "Would a single timestamp field suffice? Tested against the divergent clock-start rules in the cited regimes, and against transfer between components: a single field cannot distinguish submission from receipt from component receipt from registration from ingestion, and each of those carries a different legal effect somewhere in the cited material. Five separate instants are therefore required, not offered.", "Is any conformance claimed without evidence? All external standards are recorded as alignments. The compatibility rules and the model-steward role both state that conformance is asserted only where test or certification evidence is recorded, and no such evidence is claimed here.", "Is the artefact inventory padded? Four findings carry no artefact and give an explicit rationale: identifiers, typing, channel and current status are inline values or references into externally governed registers, and materialising them would create a second source of truth that could drift from the master.", "Could the model be satisfied while losing the record's evidential value? Checked against the records-management characteristic set: authenticity is carried by attribution, signature and authentication context; integrity by fixity at capture with re-verification; reliability by the immutable as-filed payload and the append-only history; usability by format identification and a declared preservation strategy. A conforming implementation that dropped any one of these would fail an explicit question, not merely a principle.", "A freedom-of-information or subject-access request is a different legal regime; including it requires an explicit Dimension classification, not silent reuse of this model.", "A licence, permit or benefit decision is an output, not the application; treating the award instrument as WM-REC-009 would duplicate the decision sibling.", "doNotPerform / negative requests and mandatory notifications (no discretionary ask) are in the FHIR pattern but under-specified for civic notice-filings — marked as edge, not dropped.", "Verbal or phone lodgements are in-scope as channel types; absence of a signed form does not mean absence of a record if ISO 15489 capture occurs.", "Death or loss of capacity of the applicant mid-process is not specified in the cited primary sources and must not be invented as a canonical state.", "Automated or robotic filing is not supported by primary sources retrieved; bot intake is a policy exception, not a core class." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "Both providers independently classify WM-REC-009 as an entity and both anchor it as a specialisation of WM-REC-007 distinct from WM-POL-017. Claude's boundary is the cleaner cut and is adopted verbatim: the subject is the request-as-record from the submission act to the disposition event (case opened, request fulfilled, or refused/withdrawn/closed), plus the record's retention and disposal life, explicitly excluding substantive adjudication, the outcome instrument, and the CPSV-AP catalogue definition. Grok's wider union pulls case-internal CaseFileItem lifecycle and expected-output semantics inside the line and is rejected on that basis. Grok's exclusion of FOI/SAR requests unless separately classified is not adopted: Claude's treatment — such requests are instances of this model at the request-handling surface, while the substantive rights framework stays in the privacy/access-regime sibling — is the more defensible reading and keeps SRC-010/SRC-012 evidence usable." }, "decisions": [ { "concept": "Base provider selection", "disposition": "claude", "rationale": "Claude carries eight explicit boundary notes with source refs against named neighbours, a disposition-bounded scope statement, and per-finding inline-only rationales that justify every absent artefact. Grok's structure is coherent but its wide-union scope leaves the case-file edge open. Base chosen on boundary clarity, not on the 28-versus-23 finding count." }, { "concept": "Model boundary at the disposition event", "disposition": "accepted from base", "rationale": "Adopting the intake-to-handover cut keeps WM-REC-009 from overlapping WM-POL-017 and the outcome-record sibling. Base itself flags this as its most fragile edge; the adjudicated line is the explicit, linked disposition event carrying a case reference." }, { "concept": "FOI/SAR and data-subject-rights requests as instances", "disposition": "resolved in favour of base", "rationale": "Grok excludes these unless a Dimension separately classifies them; base includes them at the request-handling surface only, with the substantive rights framework left to the privacy/access sibling. The base reading is more defensible and preserves the evidential value of SRC-010 and SRC-012." }, { "concept": "CCCEV criteria, weighting and requirement response state", "disposition": "accepted into declared-content", "rationale": "Materially absent from the base, tier-1 sourced in grok, and it closes the base's own stated gap on grant scoring and competitive selection. The requirement-discharge overlap must be deduplicated at merge." }, { "concept": "Triggering life/business event and instance reason", "disposition": "accepted into request-identity", "rationale": "The base has no why-axis at all. CPSV-AP Event plus the FHIR reason element supply a distinct, evidence-backed classification dimension that does not displace procedure binding." }, { "concept": "Reported-versus-primary capture and participation roles", "disposition": "accepted into request-actors", "rationale": "Fills an omission the base names itself regarding third-party and verbal capture, while its overlapping requester-capacity question collapses into the existing parties finding." }, { "concept": "Jurisdiction, place of performance and lodgement place", "disposition": "accepted into routing-and-handover with checklist revision", "rationale": "Two instance-level place facts belong to the submission and routing act rather than the subject. Accepting this obliges the synthesizer to change the spatial checklist entry from not-applicable to covered-by-reference; leaving it unchanged would make the merged model internally inconsistent." }, { "concept": "CMMN CaseFileItem lifecycle and case-role mapping", "disposition": "rejected on boundary", "rationale": "The case file and its item lifecycle are case-internal and sit past the adjudicated disposition line, so they belong to WM-POL-017. Grok itself records that its CaseFileItem state enumeration was incomplete." }, { "concept": "Expected outputs, prerequisite services and encounter context", "disposition": "rejected", "rationale": "The output instrument is the outcome-record sibling and the requires relation between services is catalogue-level in CPSV-AP. At instance level a prerequisite service's output reduces to evidence, which the base already models as requirement discharge." }, { "concept": "Grok application-instance-identity", "disposition": "rejected as duplicative", "rationale": "The base identifier-set finding already covers authoritative identifier, minting body and event, correlation, and duplicate reconciliation, and supersession lineage is carried by amendment-withdrawal-supersession. Only the composite requisition/group identifier is genuinely new and is deferred rather than bolted on." }, { "concept": "Grok intent, category, priority and do-not-perform", "disposition": "rejected as duplicative, prohibition deferred", "rationale": "Intent is base rtc-q2, classification schemes rtc-q3, priority and expedition crp-q3. Only the prohibition-type request is novel, and grok itself marks it under-specified for civic filings, so it goes to deferred research rather than into structure." }, { "concept": "Grok submitted-evidence and completeness-and-once-only", "disposition": "rejected as duplicative", "rationale": "The base covers evidence-to-requirement binding, validity at the instant of reliance, integrity, alternatives, explicit-request authoritative retrieval with preview and failure handling, and completeness screening as a first-class determination. The CCCEV creator/issuer/transmitter distinction is absorbed by the base provenance and chain-of-custody finding." }, { "concept": "Grok provenance, personal-data and retention findings", "disposition": "rejected as duplicative", "rationale": "Base findings on provenance and chain of custody, personal data and lawful processing, and retention with legal hold are strictly broader. The storage-limitation-versus-evidential-retention tension both providers raise is already recorded as a declared conflict in the base and is preserved." }, { "concept": "Grok capture-application, link-to-case-file and withdraw-hold-or-revoke functions", "disposition": "rejected", "rationale": "Records capture collapses into base register-and-acknowledge, case linking into dispose-request, and withdrawal into amend-or-withdraw-request. Only the authority-initiated hold is uncovered, and that is a state the added status-transition function can express without a separate operation." }, { "concept": "Requested occurrence window for the service", "disposition": "deferred", "rationale": "The FHIR occurrence element is a real declared-content fact the base omits, but it sits at the fulfilment edge the base excludes and would duplicate the base's five-instant model if merged carelessly. Deferred for a scoped decision rather than accepted." }, { "concept": "Service-layer merge", "disposition": "accepted", "rationale": "Merging the service layers is required by the synthesis contract and is compatible with the adopted boundary, since no accepted node depends on the layers remaining separate." } ], "publicationHolds": [ "Live source verification is incomplete: both providers reached ISO 15489-1 and ISO 23081 only at abstract or committee-summary level, grok recovered CMMN 1.1 CaseFileItem states only partially from the PDF, and grok recovered SDG Article 14 body text only in part. Every accepted source must be re-fetched and version-pinned before publication.", "GDPR citation provenance is unresolved: the base relied on the UK-assimilated Article 12 text via legislation.gov.uk and grok used the unofficial gdpr-info.eu mirror for Article 5. No EU-text conformance may be asserted until both are re-verified against EUR-Lex/OJ; until then the model states alignment only.", "CCCEV 2.1.0 (grok SRC-002) must be fetched and version-pinned before the added eligibility-criteria finding is published, since it is the sole support for the criteria-weighting axis and no base source corroborates it.", "Multi-domain profile validation is outstanding: the merged model has not been exercised against judicial e-filing, healthcare service request, benefits/permit authorisation, and FOI/SAR profiles simultaneously. Publish as a research draft only until at least these four profiles are walked through.", "Accessibility content rests on a public-authority service standard and single-market access law, with no accessibility conformance standard cited. Accessibility claims are held until EN 301 549 or WCAG is added, or the finding is downgraded to an assertion of policy.", "The spatial coverage checklist entry must be revised from not-applicable to covered-by-reference before publication, otherwise the accepted jurisdiction-and-lodgement finding contradicts the model's own coverage statement.", "The collection-approval element remains generically sourced because the specific statutory instrument could not be retrieved live; it must be either grounded or explicitly marked non-jurisdictional in the published draft." ], "deferredResearch": [ "Prohibition-type and do-not-perform requests, plus mandatory notification filings where no discretionary ask exists — grok carries the FHIR pattern element but marks it under-specified for civic filings.", "Requested occurrence window and scheduling semantics for the requested service, and where they sit relative to the excluded fulfilment surface.", "Composite requisition and group identifiers binding related filings, and their interaction with the base's duplicate-detection and consolidation questions.", "Competitive selection beyond criterion weighting: sealed-bid opening, comparative ranking, cohort deadlines for procurement, grant and admissions applications.", "Intellectual-property filing regimes: priority dates, filing-date accord rules and international phase transitions, which likely need a dedicated sibling profile.", "Machine-to-machine and batch intake: batch-level acceptance semantics, partial-batch failure and batch receipt, which the base addresses only via idempotency and exchange packaging.", "Legal capacity edges: minors, deceased applicants, loss of capacity mid-process, requests made under duress, and anonymous or whistleblower lodgement.", "ELI-identified legal resource binding and eIDAS qualified-signature profiles, both implied by channel evidence variance but not modelled from primary text by either provider.", "Whether a canonical state-machine specification should be fixed for the status model, or whether the base's position that defensible transition sets differ by regime should stand." ] }, "statistics": { "sources": 27, "bundles": 6, "layers": 14, "findings": 32, "questions": 130, "artifacts": 25, "functions": 13 } }