{"schema":"https://ver.cy/schemas/card/1.0.0","id":"vr.wm-rec-009","code":"wm-rec-009-application-request-record","url":"https://ver.cy/models/wm-rec-009-application-request-record/","name":"Application / Request Record","alternateNames":[],"kind":"world-model","status":"published","version":"0.3.0-research.1","language":"en","classifiers":{"family":"World Models","category":"Information and virtual systems","entryKind":"entity","plane":"","domain":["INF.REC.APP"],"industry":["Cross-industry"],"navPath":"NAV.INF.REC.APP","tags":["application","request","record","inf.rec.app"],"facets":{}},"whatItIs":"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.","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":{"in":["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":["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"],"boundaries":[{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."},{"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."}]},"distinguishingFeatures":["Captures the request at the moment a party asks a competent body to act, before any case is opened.","Ends at disposition: opening a case, fulfilling the request or refusing it, so it does not model case handling.","Records admissibility, completeness and processing time limits that start running at receipt.","Differs from a form submission by carrying the legal effect of an application, such as a filing date."],"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.","layers":[{"id":"request-identity","name":"Identity and Classification","description":"Identifiers, naming authority, correlation across systems, and the typing/classification that determines which rules apply.","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.","questions":[{"text":"Which identifier is the authoritative public reference for this request, which body minted it, and at which lifecycle event was it minted?","id":"rid-q1","kind":"identity"},{"text":"Which additional identifiers exist for the same request, and what is the declared equivalence relation between them?","id":"rid-q2","kind":"interoperability"},{"text":"Is a tracking reference disclosed to the requester, and by when is disclosure required?","id":"rid-q3","kind":"requirement"},{"text":"How are duplicate submissions of the same underlying request detected and reconciled without destroying either record?","id":"rid-q4","kind":"validation"}]},{"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.","questions":[{"text":"Which published service or procedure, at which version, does this request instantiate?","id":"rtc-q1","kind":"classification"},{"text":"What request intent does this record express - a proposal, a plan, or an actionable order to the receiving body?","id":"rtc-q2","kind":"definition"},{"text":"Which classification schemes are applied to the request, and which of them are normative for processing rather than merely descriptive?","id":"rtc-q3","kind":"classification"},{"text":"If the catalogue definition changes after submission, does the request remain governed by the version in force at submission?","id":"rtc-q4","kind":"temporal"}]},{"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.","questions":[{"text":"Which life or business event triggered this application, and what is that event's identifier and name?","id":"triggering-event-and-request-reason-q01","kind":"event"},{"text":"Why is the service needed or prohibited for this subject, in coded and/or narrative form?","id":"triggering-event-and-request-reason-q02","kind":"classification"},{"text":"Does the instance reason align with the catalogue event that the Public Service is related to, or is this an atypical use?","id":"triggering-event-and-request-reason-q03","kind":"validation"}]}]},{"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.","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.","questions":[{"text":"Who is the beneficiary or subject of the request, and is that party distinct from the submitter?","id":"prr-q1","kind":"relationship"},{"text":"Where a representative acts, what is the evidenced basis and scope of that mandate, and when does it expire?","id":"prr-q2","kind":"authority"},{"text":"Which party carries legal responsibility for the truth of the declarations, and which party receives official notifications?","id":"prr-q3","kind":"ownership"},{"text":"How are role changes during processing - change of representative, death, insolvency, transfer of the underlying interest - recorded without rewriting history?","id":"prr-q4","kind":"lifecycle"}]},{"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.","questions":[{"text":"By what means was the submitter authenticated at submission, and at what assurance level?","id":"iaa-q1","kind":"evidence"},{"text":"Which asserted attributes were verified against an authoritative source, and which remain self-declared?","id":"iaa-q2","kind":"quality"},{"text":"If identity could not be established to the required level, what proportionate additional identification was requested, and did the clock stop?","id":"iaa-q3","kind":"exception"},{"text":"Is anonymous or pseudonymous submission permitted for this procedure, and what limits does that place on the outcome?","id":"iaa-q4","kind":"constraint"}]},{"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.","questions":[{"text":"Who or what is requesting the service, and in what capacity relative to the subject?","id":"reported-capture-and-participation-roles-q01","kind":"authority"},{"text":"Which participation roles are recorded (competent authority, service user, provider, representative) and who fills each?","id":"reported-capture-and-participation-roles-q02","kind":"relationship"},{"text":"Is this application a reported rather than primary record, and who reported it?","id":"reported-capture-and-participation-roles-q03","kind":"provenance"}]}]}]},{"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.","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.","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.","questions":[{"text":"Which form or payload definition, at which version, does this instance conform to, and is that definition still retrievable?","id":"fid-q1","kind":"provenance"},{"text":"Which declarations, attestations or consents did the requester make, and what is the legal effect of each?","id":"fid-q2","kind":"requirement"},{"text":"In which language was the request submitted, and does the procedure require translation or a specific official language?","id":"fid-q3","kind":"constraint"},{"text":"Which declared values are free text and which are bound to controlled vocabularies, and how are unbound values handled downstream?","id":"fid-q4","kind":"interoperability"}]},{"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.","questions":[{"text":"Which requirement does each supplied evidence item discharge, and are any mandatory requirements still undischarged?","id":"era-q1","kind":"composition"},{"text":"Is an evidence item still valid at the moment of reliance, and was its status checked then?","id":"era-q2","kind":"temporal"},{"text":"How is each attachment's integrity established and preserved between submission and reliance?","id":"era-q3","kind":"quality"},{"text":"Where alternative evidence is acceptable, which alternative was chosen and who accepted the substitution?","id":"era-q4","kind":"decision"}]},{"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.","questions":[{"text":"Did the requester explicitly request that evidence be fetched from another authority, and how is that explicit request evidenced?","id":"aes-q1","kind":"authority"},{"text":"Was the retrieved evidence previewed by the requester before use, and could it be rejected?","id":"aes-q2","kind":"process"},{"text":"Which authority provided the evidence, under which mapping between the requirement and that authority's evidence type?","id":"aes-q3","kind":"provenance"},{"text":"What happens to the request when authoritative retrieval fails or returns no match?","id":"aes-q4","kind":"exception"}]},{"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.","questions":[{"text":"Which requirements and criteria does this application have to satisfy, and which information concepts must be evidenced?","id":"eligibility-criteria-and-requirement-response-q01","kind":"requirement"},{"text":"If criteria are weighted or biased for evaluation, what weights, weighting type and consideration description apply?","id":"eligibility-criteria-and-requirement-response-q02","kind":"measurement"},{"text":"For each requirement, has evidence been provided, reused, waived, or is it still outstanding?","id":"eligibility-criteria-and-requirement-response-q03","kind":"state"}]}]},{"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.","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.","questions":[{"text":"Against which criteria is completeness assessed, and who is competent to make that determination?","id":"caa-q1","kind":"validation"},{"text":"When a deficiency is found, what must the notice tell the requester and by when must it be sent?","id":"caa-q2","kind":"requirement"},{"text":"What effect does a deficiency have on the statutory clock - suspension, restart, or none - and on what legal basis?","id":"caa-q3","kind":"temporal"},{"text":"If the requester does not cure the deficiency, what disposition follows and is it appealable?","id":"caa-q4","kind":"exception"},{"text":"Is completeness screening re-run after amendment, and does an amended request inherit the original submission date?","id":"caa-q5","kind":"lifecycle"}]},{"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.","questions":[{"text":"Which validation layers apply - structural, code-list, cross-field, cross-record - and in which order are they executed?","id":"vrc-q1","kind":"process"},{"text":"How is each validation failure identified so a requester or agent can locate and fix it?","id":"vrc-q2","kind":"quality"},{"text":"Which rules are enforced at submission time versus after receipt, and what is the consequence of that placement?","id":"vrc-q3","kind":"constraint"},{"text":"When a rule set changes, are previously accepted requests revalidated, and how is a legacy pass recorded?","id":"vrc-q4","kind":"provenance"}]}]}]},{"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.","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.","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.","questions":[{"text":"Which instants are captured for this request and which one starts the legally relevant period?","id":"srt-q1","kind":"temporal"},{"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?","id":"srt-q2","kind":"temporal"},{"text":"What must the acknowledgement of receipt tell the requester, and within what period must it be issued?","id":"srt-q3","kind":"requirement"},{"text":"How is receipt proven if the acknowledgement is never delivered or is disputed?","id":"srt-q4","kind":"evidence"}]},{"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.","questions":[{"text":"Through which channel was the request submitted, and which channels are formally equivalent for this procedure?","id":"cha-q1","kind":"classification"},{"text":"Can a non-resident or cross-border requester complete this procedure through the same channel with a foreign identity means?","id":"cha-q2","kind":"access"},{"text":"What accessibility and assisted-route provision exists for requesters who cannot use the primary channel?","id":"cha-q3","kind":"access"},{"text":"Does the channel affect the legal treatment of the request - fees, deadlines, evidence, or the reply format owed?","id":"cha-q4","kind":"constraint"}]}]},{"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.","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.","questions":[{"text":"What binds the request content to its submitter in a way that resists later repudiation?","id":"cfn-q1","kind":"security"},{"text":"How is integrity of the as-captured record demonstrated at any later date?","id":"cfn-q2","kind":"quality"},{"text":"At what point is the request formally captured as a record, and what becomes immutable at that point?","id":"cfn-q3","kind":"lifecycle"},{"text":"How will the record remain interpretable if its original format or signature algorithm becomes obsolete?","id":"cfn-q4","kind":"retention"}]}]}]},{"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.","layers":[{"id":"status-and-change","name":"Status Model and Permitted Change","description":"The state set and transitions, and the amendment, withdrawal and supersession paths.","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.","questions":[{"text":"What is the complete set of states this request can occupy, and which are terminal?","id":"rsm-q1","kind":"state"},{"text":"Which state transitions are permitted, who may trigger each, and what precondition must hold?","id":"rsm-q2","kind":"lifecycle"},{"text":"How is the technical processing state distinguished from the business status the requester is told about?","id":"rsm-q3","kind":"definition"},{"text":"How is a request recorded that should never have existed, as distinct from one properly cancelled or withdrawn?","id":"rsm-q4","kind":"exception"}]},{"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.","questions":[{"text":"Which change classes are permitted after submission, and until which point in the lifecycle?","id":"aws-q1","kind":"constraint"},{"text":"Does an amendment create a new version of the same request or a new request that supersedes the old one?","id":"aws-q2","kind":"identity"},{"text":"What effect does each change class have on the effective submission date and the running deadline?","id":"aws-q3","kind":"temporal"},{"text":"On withdrawal, what is retained, what is returned, and what is the requester told?","id":"aws-q4","kind":"retention"}]}]},{"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.","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.","questions":[{"text":"What processing period applies, on what legal basis, and where was it published in advance?","id":"scm-q1","kind":"authority"},{"text":"From which recorded instant does the period run, and how is that instant chosen when receipt is staged across components?","id":"scm-q2","kind":"temporal"},{"text":"Under which conditions may the clock be suspended or extended, who authorises it, and what notice is owed before expiry?","id":"scm-q3","kind":"process"},{"text":"What happens on expiry - deemed grant, deemed refusal, or continued duty to decide - and how is that outcome recorded?","id":"scm-q4","kind":"decision"},{"text":"Is an estimated completion date communicated to the requester, and how is it revised?","id":"scm-q5","kind":"measurement"}]},{"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.","questions":[{"text":"Which event types must be recorded for a request, and is the history append-only?","id":"eha-q1","kind":"provenance"},{"text":"For each event, is the event instant recorded separately from the observation or ingestion instant?","id":"eha-q2","kind":"temporal"},{"text":"Which agent, human or software, is attributed to each event, and on whose behalf did it act?","id":"eha-q3","kind":"provenance"},{"text":"How long is the event history retained relative to the request content, and can it be disposed of separately?","id":"eha-q4","kind":"retention"}]}]},{"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.","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.","questions":[{"text":"Which body is competent for this request, on what jurisdictional or subject-matter basis, and who determined that?","id":"crp-q1","kind":"authority"},{"text":"When a request is transferred, what date does the receiving body treat as receipt, and is the requester notified?","id":"crp-q2","kind":"process"},{"text":"Into which processing track is the request placed, on what criteria, and can the requester request expedition?","id":"crp-q3","kind":"classification"},{"text":"How is priority or queue position made auditable so that ordering can be shown to be non-arbitrary?","id":"crp-q4","kind":"quality"}]},{"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.","questions":[{"text":"What disposition ended the request's own lifecycle, and when?","id":"crd-q1","kind":"lifecycle"},{"text":"If a case or proceeding was opened, what is its identifier and what is the typed relation between request and case?","id":"crd-q2","kind":"relationship"},{"text":"Can one request open several cases, or several requests be consolidated into one case, and how is that recorded?","id":"crd-q3","kind":"composition"},{"text":"Where the request is refused at intake, what reasons must be given and which redress route is stated?","id":"crd-q4","kind":"requirement"},{"text":"After disposition, does the request record remain independently addressable and queryable for status?","id":"crd-q5","kind":"access"}]},{"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.","questions":[{"text":"Which administrative region or jurisdiction does the requested service and competent authority cover, and is the subject in-scope?","id":"jurisdiction-place-and-lodgement-location-q01","kind":"spatial"},{"text":"Where should the service be performed, if location-specific?","id":"jurisdiction-place-and-lodgement-location-q02","kind":"spatial"},{"text":"If lodged in person, at which office or address was the application received?","id":"jurisdiction-place-and-lodgement-location-q03","kind":"spatial"}]}]}]},{"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.","layers":[{"id":"authority-and-cost","name":"Collection Authority and Cost","description":"The mandate to require this information and the fees attached to the request.","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.","questions":[{"text":"Under which instrument is the body empowered to require this request and this information, and is that instrument cited to the requester?","id":"lba-q1","kind":"authority"},{"text":"Is the request voluntary or mandatory, and what follows from not providing a given item?","id":"lba-q2","kind":"requirement"},{"text":"Is a collection approval, control number or equivalent registration required before the form may be used, and is it current?","id":"lba-q3","kind":"validation"},{"text":"What burden does the request impose on the requester, and is that estimate published?","id":"lba-q4","kind":"measurement"}]},{"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.","questions":[{"text":"What charge applies to this request, on what basis, and does it vary by channel or requester category?","id":"fwp-q1","kind":"constraint"},{"text":"Is payment a precondition of admissibility, and what is the effect of non-payment on the clock and the disposition?","id":"fwp-q2","kind":"process"},{"text":"On what grounds may a fee be waived, reduced or refunded, and who decides?","id":"fwp-q3","kind":"decision"},{"text":"When may a charge be refused as excessive, or a request refused as manifestly unfounded, and who bears the burden of showing that?","id":"fwp-q4","kind":"exception"}]}]},{"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.","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.","questions":[{"text":"Which determinations trigger a duty to give reasons, and to what standard of specificity?","id":"arr-q1","kind":"requirement"},{"text":"Which redress routes are available, with what deadlines, and were they stated to the requester in writing?","id":"arr-q2","kind":"access"},{"text":"Is the requester entitled to be heard or to correct the record before an adverse determination is made?","id":"arr-q3","kind":"process"},{"text":"How is the notification instant established for the purpose of starting the redress clock?","id":"arr-q4","kind":"temporal"}]},{"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.","questions":[{"text":"Which categories of personal data does this request contain, and are any of them special-category or otherwise heightened-risk?","id":"pdl-q1","kind":"privacy"},{"text":"What is the lawful basis for processing each category, and does that basis persist after disposition?","id":"pdl-q2","kind":"authority"},{"text":"Which body is controller and which are processors or joint controllers for this request, including exchange intermediaries?","id":"pdl-q3","kind":"ownership"},{"text":"What minimisation was applied - which requested items were reduced, redacted or not collected - and on what assessment?","id":"pdl-q4","kind":"constraint"},{"text":"Can the requester exercise data-subject rights over this request record, and how does that interact with the procedure's own retention duty?","id":"pdl-q5","kind":"exception"}]}]},{"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.","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.","questions":[{"text":"Who may read, amend and dispose of this request, and at what granularity is that expressed?","id":"acc-q1","kind":"access"},{"text":"Which parts of the request are publicly disclosable and which are withheld, on what stated ground?","id":"acc-q2","kind":"security"},{"text":"How does the requester's own access to their request differ from third-party or public access?","id":"acc-q3","kind":"access"},{"text":"Do access markings and controls travel with the record when it is exported or transferred to another body?","id":"acc-q4","kind":"interoperability"}]},{"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.","questions":[{"text":"Which retention rule applies to this request, from which classification and under which disposition authority?","id":"rdh-q1","kind":"retention"},{"text":"What event starts the retention period, and how is that trigger detected reliably?","id":"rdh-q2","kind":"temporal"},{"text":"Do withdrawn, refused-at-intake and entered-in-error requests follow the same rule as accepted ones?","id":"rdh-q3","kind":"constraint"},{"text":"What disposal actions are permitted, and what evidence of disposal is kept after the content is gone?","id":"rdh-q4","kind":"lifecycle"},{"text":"How is a legal hold applied and released, and what does it override?","id":"rdh-q5","kind":"exception"}]}]}]},{"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.","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.","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.","questions":[{"text":"Which external profiles is this request expected to be expressed in, and which elements have no counterpart in each?","id":"epb-q1","kind":"interoperability"},{"text":"Is a mapping asserted as an alignment or claimed as conformance, and what evidence supports a conformance claim?","id":"epb-q2","kind":"evidence"},{"text":"How are correlation identifiers preserved across an exchange so a response can be matched to the original request?","id":"epb-q3","kind":"identity"},{"text":"What happens when the receiving system's profile version differs from the sending system's?","id":"epb-q4","kind":"exception"}]}]},{"id":"assurance-and-quality","name":"Provenance, Measurement and Exception Handling","description":"Attributable history, published performance, and defensible behaviour under failure.","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.","questions":[{"text":"Which activity generated each version of the request record, and which agent was associated with that activity?","id":"pcc-q1","kind":"provenance"},{"text":"From which prior entities was this request derived - a draft, a previous request, a pre-filled dataset?","id":"pcc-q2","kind":"provenance"},{"text":"Where a software agent acted, on whose authority did it act and how is that delegation recorded?","id":"pcc-q3","kind":"authority"},{"text":"Which custody boundaries did the record cross, and was integrity verified at each crossing?","id":"pcc-q4","kind":"quality"}]},{"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.","questions":[{"text":"Which measures are computed over request records, and from exactly which recorded instants and codes?","id":"pmr-q1","kind":"measurement"},{"text":"How is timeliness measured against the statutory period, including suspended and extended cases?","id":"pmr-q2","kind":"measurement"},{"text":"Which measures are published, at what aggregation, and how is disclosure of small cohorts prevented from re-identifying requesters?","id":"pmr-q3","kind":"privacy"},{"text":"How are intake quality problems - rejection rate, deficiency rate, channel abandonment - fed back into the form and rules?","id":"pmr-q4","kind":"quality"}]},{"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.","questions":[{"text":"If the submission channel is unavailable at or near a deadline, what fallback exists and how is the outage evidenced?","id":"ehd-q1","kind":"exception"},{"text":"How are retried or duplicated submissions distinguished from genuine repeat requests?","id":"ehd-q2","kind":"validation"},{"text":"How is a record that should never have existed marked and treated, and is it destroyed or retained annotated?","id":"ehd-q3","kind":"lifecycle"},{"text":"When an upstream evidence provider or exchange partner fails, what error is surfaced to the requester and what is the recovery path?","id":"ehd-q4","kind":"process"},{"text":"How are partial submissions and abandoned drafts treated - are they records at all?","id":"ehd-q5","kind":"definition"}]}]}]}]},"agentConduct":{"may":["Register a request and issue an acknowledgement with receipt time and reference.","Screen completeness and tell the applicant what is missing.","Retrieve evidence from an authoritative source when the applicant has agreed to it.","Compute processing time limits under the applicable rules."],"mustNot":["Refuse or reject a request on its own authority.","Change the recorded receipt time or filing date.","Silently drop a request that seems incomplete instead of recording and reporting it.","Ask the applicant for evidence the authority already holds where once-only rules apply.","Use request data for purposes unrelated to the request."],"requiresHuman":["Deciding admissibility or refusal.","Transferring a request to another competent body.","Marking a request as entered in error and retracting downstream records."]},"ethics":{"considerations":["Requests often concern benefits, permits or rights; delay or loss can cause real hardship.","Applicants are usually the weaker party and need clear acknowledgement and status.","Requests reveal personal circumstances such as health, income or migration status."],"affectedParties":["Applicants and their representatives","Public bodies and service providers that receive requests","Third parties named in a request"]},"owners":{"steward":"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.","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"]}],"masterSystems":[]},"relations":[{"target":"WM-REC-007","type":"extends","note":"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."},{"target":"WM-POL-017 (Administrative case)","type":"references","note":"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."},{"target":"Public service / procedure catalogue model (CPSV-AP aligned)","type":"aligned","note":"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."},{"target":"Party / agent model (natural person and organisation)","type":"references","note":"Resolve submitter, subject, representative, payer and notified-party references to governed party identities without embedding master data in the request."},{"target":"Evidence / document record model","type":"composes","note":"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."},{"target":"Identity and trust-service model (authentication and assurance)","type":"composes","note":"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."},{"target":"Provenance mixin (PROV-aligned)","type":"composes","note":"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."},{"target":"Retention schedule and disposition authority model","type":"references","note":"Inherit the retention rule from a classification under a named disposition authority, and record holds and executed disposal actions against that authority."},{"target":"Payment / fee transaction model","type":"references","note":"Link the fee assessment and its admissibility effect to the payment transaction, whose execution, settlement and refund mechanics are out of scope here."},{"target":"Decision / authorisation outcome record model","type":"references","note":"Point to the grant, refusal, permit or award produced, which carries its own identity, effective dates and appeal window."},{"target":"Appeal / complaint record model","type":"references","note":"Link a challenge lodged against an intake refusal or adverse determination; the appeal is a distinct triggering record with its own lifecycle."},{"target":"Exchange profile bindings (domain exchange package, filing message, service-request resource)","type":"aligned","note":"Declare mappings to external serialisation profiles as alignments with stated loss characteristics. Conformance is claimed only where test or certification evidence exists."},{"target":"WM-REC-007 (parent record model)","type":"neighbor","note":"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."},{"target":"WM-POL-017 (Administrative case)","type":"neighbor","note":"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."},{"target":"Public service description (CPSV-AP)","type":"neighbor","note":"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."},{"target":"Outcome / decision record","type":"neighbor","note":"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."},{"target":"Incident record (service management)","type":"neighbor","note":"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."},{"target":"Evidence / attachment document record","type":"neighbor","note":"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."},{"target":"Identity and trust-service model","type":"neighbor","note":"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."},{"target":"Data-subject rights request (privacy request)","type":"neighbor","note":"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."},{"target":"WM-REC-007","type":"parent"}],"interaction":{"identity":{"applicability":"required","items":["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."]},"properties":{"applicability":"not-applicable","items":[]},"recognition":{"applicability":"optional","items":["A request record names an applicant, a receiving body, a requested act, a receipt time and a status up to disposition.","Often confused with the form it was submitted on, the administrative case that follows and the final decision."]},"capabilities":{"applicability":"required","items":["Submit request: 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.","Register request and acknowledge receipt: 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.","Validate technical conformance: Run structural, code-list, cross-field and cross-record validation against the pinned rule-set version and emit a citable issue list.","Screen completeness and determine admissibility: Assess whether every mandatory requirement is discharged, issue a deficiency notice where it is not, and record the effect on the processing clock.","Retrieve evidence from an authoritative source: 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.","Amend, supplement or withdraw the request: Apply a permitted change class, creating a new version linked by derivation and recomputing any affected dates without erasing prior state.","Determine competence, transfer and assign a processing track: Identify the competent body and component, transfer where necessary preserving the original receipt date, and place the request in a processing track.","Compute and manage processing time limits: Derive the deadline from recorded instants and the applicable period, apply suspensions and extensions with notice, and evaluate any expiry consequence.","Dispose the request by opening a case, fulfilling or refusing: End the request's own lifecycle by linking a case, recording direct fulfilment, or issuing a reasoned refusal with redress information.","Export a profile-conformant exchange package: Project the request into a declared external profile for transmission, preserving correlation identifiers, access markings and integrity values.","Apply retention rule and execute disposition: 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.","Mark a record entered in error and retract downstream: Distinguish a record that should never have existed from a properly cancelled one, annotate it, and notify downstream consumers of the retraction.","Transition intention status: Move request status among draft, active, on-hold, revoked, completed, entered-in-error or unknown with a recorded reason, without encoding fulfilment work."]},"hazards":{"applicability":"required","items":["A lost request or wrong receipt time can forfeit the applicant's rights.","Missed statutory deadlines expose the receiving body to liability.","Misrouted requests disclose personal data to the wrong body."]},"interfaces":{"applicability":"required","items":["HL7 FHIR ServiceRequest and Task resources.","Core Public Service Vocabulary Application Profile (CPSV-AP).","W3C PROV-O.","ISO 15489-1 records management."]},"context":{"applicability":"required","items":["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."]}},"sources":[{"title":"Core Public Service Vocabulary Application Profile (CPSV-AP) 3.2.0","url":"https://semiceu.github.io/CPSV-AP/releases/3.2.0/","note":"SEMIC / European Commission"},{"title":"Regulation (EU) 2018/1724 establishing a single digital gateway","url":"https://www.legislation.gov.uk/eur/2018/1724/contents","note":"European Union (text as published by The National Archives, legislation.gov.uk)"},{"title":"Directive 2006/123/EC on services in the internal market, Article 13 (Authorisation procedures)","url":"https://www.legislation.gov.uk/eudr/2006/123/article/13","note":"European Union (text as published by The National Archives, legislation.gov.uk)"},{"title":"FHIR ServiceRequest resource, FHIR Release 5","url":"https://hl7.org/fhir/R5/servicerequest.html","note":"HL7 International"},{"title":"FHIR Task resource, FHIR Release 5","url":"https://hl7.org/fhir/R5/task.html","note":"HL7 International"},{"title":"Electronic Court Filing Version 5.0, Committee Specification 01","url":"https://docs.oasis-open.org/legalxml-courtfiling/ecf/v5.0/ecf-v5.0.html","note":"OASIS LegalXML Electronic Court Filing TC"},{"title":"PROV-O: The PROV Ontology","url":"https://www.w3.org/TR/prov-o/","note":"World Wide Web Consortium (W3C)"},{"title":"RFC 3339: Date and Time on the Internet: Timestamps","url":"https://www.rfc-editor.org/rfc/rfc3339","note":"Internet Engineering Task Force (IETF)"},{"title":"RFC 9562: Universally Unique IDentifiers (UUIDs)","url":"https://www.rfc-editor.org/rfc/rfc9562.html","note":"Internet Engineering Task Force (IETF)"},{"title":"Guidelines 01/2022 on data subject rights - Right of access, Version 2.1","url":"https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-012022-data-subject-rights-right-access_en","note":"European Data Protection Board (EDPB)"},{"title":"Regulation (EU) 2016/679 (GDPR) Article 12 as assimilated in UK law","url":"https://www.legislation.gov.uk/eur/2016/679/article/12","note":"The National Archives (legislation.gov.uk)"},{"title":"5 U.S. Code § 552 - Public information; agency rules, opinions, orders, records, and proceedings","url":"https://www.law.cornell.edu/uscode/text/5/552","note":"Cornell Law School Legal Information Institute (publishing the United States Code)"},{"title":"ISO 23081-2:2021 Information and documentation - Metadata for managing records - Part 2: Conceptual and implementation issues","url":"https://www.iso.org/standard/81600.html","note":"International Organization for Standardization (ISO)"},{"title":"ISO 15489-1:2016 Information and documentation - Records management - Part 1: Concepts and principles","url":"https://www.iso.org/standard/62542.html","note":"International Organization for Standardization (ISO)"},{"title":"MoReq2010 Modular Requirements for Records Systems","url":"https://moreq.info/","note":"DLM Forum Foundation"},{"title":"NIEMOpen - National Information Exchange Model","url":"https://niemopen.org/","note":"OASIS Open Project (NIEMOpen); sponsors include DHS S&T and FBI CJIS"},{"title":"Verifiable Credentials Data Model v2.0","url":"https://www.w3.org/TR/vc-data-model-2.0/","note":"World Wide Web Consortium (W3C)"},{"title":"Case Management Model and Notation (CMMN) Version 1.1","url":"https://www.omg.org/spec/CMMN/1.1/About-CMMN","note":"Object Management Group (OMG)"},{"title":"GOV.UK Service Manual - Service Standard","url":"https://www.gov.uk/service-manual/service-standard","note":"Government Digital Service, UK Government"},{"title":"Core Criterion and Core Evidence Vocabulary (CCCEV) 2.1.0","url":"https://semiceu.github.io/CCCEV/releases/2.1.0/","note":"European Commission SEMIC"},{"title":"HL7 FHIR R5 Resource ServiceRequest","url":"https://www.hl7.org/fhir/servicerequest.html","note":"HL7 International"},{"title":"HL7 FHIR R5 Request pattern","url":"https://www.hl7.org/fhir/request.html","note":"HL7 International"},{"title":"ISO 15489-1:2016 Information and documentation — Records management — Part 1: Concepts and principles","url":"https://committee.iso.org/sites/tc46sc11/home/projects/published/iso-15489-records-management.html","note":"ISO/TC 46/SC 11"},{"title":"Case Management Model and Notation (CMMN) Version 1.1","url":"https://www.omg.org/spec/CMMN/1.1/PDF","note":"Object Management Group"},{"title":"Regulation (EU) 2016/679 Article 5 — Principles relating to processing of personal data","url":"https://gdpr-info.eu/art-5-gdpr/","note":"European Union"},{"title":"Regulation (EU) 2018/1724 Article 14 — Technical system for the cross-border automated exchange of evidence and application of the once-only principle","url":"https://www.legislation.gov.uk/eur/2018/1724/article/14","note":"European Union / legislation.gov.uk"},{"title":"ISO 23081 Metadata for records","url":"https://committee.iso.org/sites/tc46sc11/home/projects/published/iso-23081-metadata-for-records.html","note":"ISO/TC 46/SC 11"}],"openQuestions":["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.","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."],"resources":{"spec":"/models/wm-rec-009-application-request-record/spec.yaml","agents":"/models/wm-rec-009-application-request-record/AGENTS.md","source":"https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-rec-009"},"provenance":{"origin":"world-models research","builtFrom":["models/wm-rec-009-application-request-record/spec.yaml","ver-cy/world-models/card-supplements/wm-rec-009-application-request-record.json"],"providers":["Claude","Grok"],"researchStatus":"reviewable-draft","generatedAt":"2026-08-24T13:58:52Z","builder":"tools/build_cards.py@1.0.0"},"completeness":{"sections":{"classifiers":"filled","whatItIs":"filled","purpose":"filled","distinguishingFeatures":"filled","structure":"filled","agentConduct":"filled","ethics":"filled","owners":"filled","relations":"filled","interaction.identity":"filled","interaction.properties":"not-applicable","interaction.recognition":"filled","interaction.capabilities":"filled","interaction.hazards":"filled","interaction.interfaces":"filled","interaction.context":"filled","sources":"filled"},"notes":{"interaction.properties":"Institutional or informational subject: no invented physical properties.","_supplement":"Sections authored in card supplement 1.0.0 by Claude (Opus 5.5) (2026-10-05, unreviewed). Written from the published specification and established practice in the field; no new sources were read. Unreviewed."},"score":1.0}}