> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/the-assessment-toolkit/the-templates-for-verification.md). # The templates for verification These four templates are used in step 4 of the method, where the answers gathered so far are checked before anything is scored. **Method step:** 4 of 9 — Verify the answers in facilitated sessions **Public anchor:** PAERA version 1.0 (GovStack, 2024), section 5.4, "Organisational Assessment & Roadmap", steps 2 to 4: the assessment tools, among them document review, interviews and focus groups, and technology audits; conducting the assessment; and analysing its results. PAERA writes that procedure for assessing one organisation; it is the nearest published procedure for the verification of a national assessment. The four templates, the order of the verification activities and the ranking of evidence are the team's own and are presented as the team's multi-country implementation experience. These four templates are used in step 4 of the method, where the answers gathered so far are checked before anything is scored. By this step the assessment team holds two statements about each point. The desk result of step 2 says what the public record suggests. The questionnaire answer of step 3 says what a body reports about itself. Neither is yet a finding. In step 4 the facilitator checks both against documents and against systems seen working, settles each point where they disagree, and has the result confirmed by the bodies that gave the answers. Only a position verified in this way goes forward to scoring in step 5. The work runs in six activities, in this order. The facilitator receives the signed questionnaire answers. The facilitator reads every document the answers name and compares it with the desk results. Each disputed point goes to the person who owns it, in a clarification interview. The team sees the systems working, in technical workshops. The facilitator writes the verified position for every point. Last, the verified positions are presented to all the bodies in a final validation workshop, which closes the points still disputed. The four templates serve these activities. The map of the bodies involved says who must take part. The session plan, which is the plan of sessions, sets out the interviews and the workshops. The reconciled-response table, which is the table of reconciled answers, holds the verified position for every point. The agenda of the final validation workshop, which is the agenda of the validation workshop, is the order of the half day in which the result is confirmed. The templates name no country, no body and no person. Every person is recorded by role, never by name, in any record that may be published. The five domains are written by their codes: GOV for governance and policy with the legal framework, ACC for access, DAT for digital data, INT for interoperability and IDN for digital identity. A point is named by the identifier of its desk result from step 2, which is the letters AF, the code of the domain and a two-digit running number, joined by hyphens. **The roles named in the templates.** | Role | Who holds it | What the role does | | -------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Facilitator | A member of the assessment team | Plans and runs the sessions, keeps the evidence, writes the verified positions | | Respondent team lead | The head of the unit that answered the questionnaire | Brings the right people and documents; signs off the verified positions for the unit | | Section leads | Staff of the responding unit, one for each section of the questionnaire | Answer the clarification questions for their section | | Focal points | One person in each other body named on the frame page of step 1 | Confirm or correct statements about their own body's systems | | Validation chair | A senior official named by the sponsor of the assessment | Chairs the final validation workshop and closes disputed points | ## 1. Map of the bodies involved This map is the assessment's stakeholder map. The facilitator fills it at the start of step 4, before any session is planned. It is filled from the frame page of step 1, which names the bodies that answer for each domain, and from the questionnaires of step 3, which show which bodies answered and which did not. Each body gets one row for each domain it takes part in. The map decides who is asked to which session, and who only sees the result at the final validation workshop. | Body | Its part in the domain | What it stands to gain or lose | Its influence on the result | How it will be engaged | Focal point (by role, never by name in a published record) | | ---- | ---------------------- | ------------------------------ | --------------------------- | ------------------------------------------------------ | ---------------------------------------------------------- | | | | | high / medium / low | questionnaire / interview / workshop / validation only | | | | | | | | | | | | | | | | ## 2. Session plan The facilitator fills this plan after the document review, from the list of points that agree, disagree or lack evidence, and from the map of the bodies involved. Each row is one session: a clarification interview with the section lead who owns the disputed points, or a technical workshop in which a system is seen working. Give each session an identifier, V-01, V-02 and so on, so that the reconciled-response table can cite the session as evidence. List the points to clarify by their identifiers. Under evidence to bring, name what the body is asked to bring or to show, at the highest level of evidence it can reach: a system working is better than a document, and a document is better than a statement. | Session | Domain and questionnaire sections | Participants (by role) | Length | Points to clarify | Evidence to bring | | ------- | --------------------------------- | ---------------------- | ------ | ----------------- | ----------------- | | | | | | | | | | | | | | | | | | | | | | ## 3. Reconciled-response table The facilitator fills this table in the synthesis, after the sessions of the plan are held. It is filled from the desk results of step 2, the signed questionnaire answers of step 3, the notes of the clarification interviews and the evidence seen in the technical workshops. Each row is one point. The verified position is one plain statement of what is true, with the evidence behind it and the level of that evidence. At the final validation workshop the validation chair decides each point still marked disputed, and the decision is recorded in the same row. Step 5 scores from the verified positions in this table and from nothing else: a desk result or a questionnaire answer that was not verified is never scored. | Point | Desk result (step 2) | Questionnaire answer (step 3) | Verified position | Evidence and its level | Status | | ----- | -------------------- | ----------------------------- | ----------------- | ---------------------- | ------------------------------- | | | | | | | verified / corrected / disputed | | | | | | | | | | | | | | | **The three statuses.** *Verified*: the evidence confirms what was reported. *Corrected*: the evidence shows something different from the desk result or the questionnaire answer, and the verified position states what the evidence shows. *Disputed*: the sources still disagree, and the point goes to the final validation workshop. **The levels of evidence.** When sources disagree, the higher level wins. A verified position needs either one source at level 1, or two independent sources at levels 2 or 3. | Level | Kind of evidence | Example | | ----- | ----------------------------- | ---------------------------------------------- | | 1 | A system seen working | A demonstration, an export, a log | | 2 | An official document in force | A law, a signed regulation, an approved budget | | 3 | Official statistics | A published yearbook | | 4 | An internal report | A unit's annual report, a project report | | 5 | A statement in an interview | What an official says in a session | Where two sources at the same level still disagree, the facilitator records both, marks the point disputed and brings it to the final validation workshop. ## 4. Agenda of the final validation workshop The facilitator prepares this agenda with the validation chair once the reconciled-response table is complete, and it is the last activity of step 4. Every body on the map of the bodies involved is asked to the workshop, including those marked "validation only". The verified positions are presented one domain at a time, in the order of the five domains. The items on disputed points are taken from the rows of the reconciled-response table marked disputed, and the decisions are written back into those rows. The workshop takes half a day; the times are counted from the opening. | Time | Item | Led by | | ---- | ---------------------------------------------------------------------- | ---------------- | | 0:00 | Opening: the purpose and the five domains | Validation chair | | 0:15 | The verified positions, one domain at a time | Facilitator | | 1:45 | Break | | | 2:00 | Disputed points: each body states its position and its evidence | Facilitator | | 3:00 | Decisions on disputed points, recorded in the table | Validation chair | | 3:30 | Next steps: scoring, the domain reports, the dates of the gap workshop | Facilitator | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/roadmap/the-assessment-toolkit/the-templates-for-verification.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.