GovKM Proposed Standards and Guidance
Show Who Can Approve Policies and Decisions
Designate governing sources, preserve delegation evidence and resolve approval conflicts through accountable officials.
GovKM-proposed public draft. Published for public review. Not externally accredited or endorsed.
View the EICARS framework resourceDocument
Return to the EICARS guidance index
EICARS implementation guidance — proposed public draft. Checklist coverage: R02.1, R02.2, R02.3, R02.4. Prepared November 9, 2026. These suggested approaches support the published GovKM-proposed EICARS v0.1 draft; they do not add requirements or grant external accreditation.
Purpose and use
Designate governing sources, preserve delegation evidence and resolve approval conflicts through accountable officials.
Use this guide within a declared organizational scope, with existing repositories and suitable organizational processes. AI is optional. Examples and suggested evidence are implementation aids; the published standard governs a conformance assessment. The Riverton case below is fictional, not an observed deployment or test result.
Responsible roles
Business owners and officials holding actual approval powers, with records and legal support.
Assign responsibilities through the organization’s actual instruments. A suggested role in this guide does not itself confer decision authority.
R02.1 Designate authoritative sources
Suggested approach: Identify the office and designated source for each relevant information type. Distinguish an approved policy, operational record, reporting view and convenience copy. Document source assignments through the organization’s existing authority and keep them accessible to authorized users. A source register may reference several repositories; central storage is unnecessary.
Riverton example: Facilities owns inspection findings. IT owns network acceptance. Acquisition owns the procurement file. A project dashboard summarizes these sources but does not become a substitute approval record.
Evidence and completion check: Retain source assignments and representative references. Ask staff to resolve one dashboard claim to the designated source and explain which office can correct it.
R02.2 Preserve approvals and delegations
Suggested approach: Preserve the actual approval and delegation instruments needed for the task. Capture their issuer, recipient or role, scope, limits, effective period and revocation information where relevant. Reference existing standing instruments instead of requiring a fresh approval for every routine action. Do not create authority evidence retroactively from a person’s job title.
Riverton example: The director’s opening decision and a contracting official’s delegated authority answer different questions. An unsigned modification does not establish that contract work has been authorized.
Evidence and completion check: Trace a policy and delegated decision to the applicable instruments. Include an expired or revoked case using safe material, and record any missing instrument as a gap.
R02.3 Approve authority and approval policy
Suggested approach: Approve a practical policy explaining source assignments, approval and publication responsibilities, effective dates, exceptions and conflict escalation. Use existing policy structures where they already cover the need. Specify how proposals become approved instructions and who can resolve disputes. Publication status and decision authority should be separately understandable.
Riverton example: Riverton staff may prepare an updated schedule, but the approved opening target changes only through the director’s established process. A coordinator cannot make a proposal operative by uploading it to the project site.
Evidence and completion check: Retain the approved policy and evidence that the process operates. Inspect a proposed change and its approval or rejection, including the source staff are told to use.
R02.4 Apply standing authority and escalate disputes
Suggested approach: Use documented standing authority within its scope and limits. Confirm relevant delegations when responsibilities change. Treat system access, reporting hierarchy and repository location as context rather than sufficient proof of decision authority. Escalate disputed authority to the official designated by governing instruments; do not let a search engine or AI settle the dispute.
Riverton example: An employee can edit the Riverton schedule but cannot authorize contract changes. A change of director prompts a review of relevant responsibilities without automatically canceling every predecessor policy.
Evidence and completion check: Keep the instruments, dispute referral and determination. Demonstrate one valid standing authorization and one action outside its limits; record who resolves the latter.
Evidence and completion checks
Agree the population, expected results and acceptance conditions before assessing. Record the date, assessor, evidence reference, observed result and limitation. Use approved safe examples for access, malicious-content or lifecycle tests. Documented policy and observed operating behavior are both relevant; one does not automatically prove the other.
On smaller screens, scroll the table horizontally to view every column.
| Item | Suggested evidence and demonstration |
|---|---|
| R02.1 | Retain source assignments and representative references. Ask staff to resolve one dashboard claim to the designated source and explain which office can correct it. |
| R02.2 | Trace a policy and delegated decision to the applicable instruments. Include an expired or revoked case using safe material, and record any missing instrument as a gap. |
| R02.3 | Retain the approved policy and evidence that the process operates. Inspect a proposed change and its approval or rejection, including the source staff are told to use. |
| R02.4 | Keep the instruments, dispute referral and determination. Demonstrate one valid standing authorization and one action outside its limits; record who resolves the latter. |
Record a gap where the required outcome is not demonstrated. Assign an owner and review date, then verify any correction. Completion of this page alone does not demonstrate conformance with all ten domains, certify legal compliance, approve an AI deployment or authorize autonomous actions.
Common mistakes
Equating edit permission with authority; relying on titles instead of instruments; treating an unsigned proposal as approved.
Continue the checklist
Use this page with the EICARS standard, the identity guide and the full Riverton scenario. No particular product, model or repository migration is required.
Implementation overview
Suggested operating approach: assign the responsible roles, confirm applicability, implement suitable controls in the existing environment, examine operating evidence and track unresolved gaps. Tailor the methods to scale and risk. Maintain current services during preparation and preserve records, access and legal obligations throughout.
Standards traceability and references
Version history
November 9, 2026 — Publication authorized by GovKM. Guidance based on checklist and government authority reference package checked November 5, 2026. References must be periodically revalidated.
November 9, 2026 — Expanded implementation guidance, version 0.1. Replaced the shorter implementation text with the reviewed Riverton examples, task-specific approaches, evidence checks and official authority mappings, with Robert Noyes’s approval. Existing URLs and checklist anchors are preserved. No EICARS requirement or GovKM doctrine is amended.