GovKM Proposed Standards and Guidance
Define the Scope Before Assessing AI Readiness
Define the information, responsibilities and obligations covered by an assessment before claiming organizational readiness.
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: S01, S02, S03, S04. 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
Define the information, responsibilities and obligations covered by an assessment before claiming organizational readiness.
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 sponsor and assessment lead, supported by relevant governance and technical officials.
Assign responsibilities through the organization’s actual instruments. A suggested role in this guide does not itself confer decision authority.
S01 Define the assessment scope
Suggested approach: Start with a business decision or service, then identify the organizational unit, information population, repositories, interfaces and necessary historical dependencies. Describe exclusions and their consequences. Have the accountable official approve a scope that staff can actually assess. A narrow pilot can be useful, but cannot support an enterprise-wide claim.
Riverton example: Riverton scopes the office-opening briefing across Facilities, IT, Acquisition, Finance and an approved HR readiness confirmation. Unrelated personnel case files remain excluded; the exclusion does not eliminate the staffing condition.
Evidence and completion check: Retain the signed scope and population description. Ask a reviewer to follow one declared task across every necessary source and identify any excluded dependency.
S02 Assign accountable officials
Suggested approach: Name an executive sponsor, approving official and assessment lead. Assign business, records, architecture, IT, security, privacy, legal, accessibility and workforce responsibilities as appropriate. Distinguish coordination from approval powers. Existing governance bodies can perform these roles; a new committee is optional.
Riverton example: The Riverton coordinator assembles the briefing. The director decides whether to open; the contracting official retains contract authority. Neither role acquires the other’s powers through this project.
Evidence and completion check: Keep the approved responsibility assignment and escalation contacts. Walk through an unresolved issue and confirm that staff know who prepares advice and who can decide.
S03 Inventory repositories and dependencies
Suggested approach: Inventory existing repositories, system owners, formats, interfaces, physical files and offline holdings. Record approximate population and coverage limits, rather than presenting a partial crawl as a complete inventory. Include exports, email, shared drives and analytical copies when relevant. Use read-only discovery or other approved techniques that preserve ongoing services.
Riverton example: Riverton finds a current facilities report in a shared library, IT tickets in another application and older approvals in a records repository. The inventory records all three locations and the known gaps.
Evidence and completion check: Retain the bounded inventory, owner confirmations and unknowns. Reconcile a representative business file against the inventory; investigate missing sources without moving or deleting them automatically.
S04 Document applicability
Suggested approach: Create an applicability register linking each relevant law, regulation, policy, contract and adopted standard to its version, organizational scope, responsible official and supporting source. Separate mandatory obligations from conditional requirements and voluntary recommendations. Have qualified officials resolve conflicts and identify agency supplements. A reference list alone is not an applicability determination.
Riverton example: Riverton records the actual records schedule items, approved access rules and acquisition requirements for its project. It does not label every NIST catalog control mandatory merely because the catalog is cited.
Evidence and completion check: Show a reviewer one obligation from authoritative source through applicability decision to implementation evidence. Record the review date and any unresolved legal or policy question.
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 |
|---|---|
| S01 | Retain the signed scope and population description. Ask a reviewer to follow one declared task across every necessary source and identify any excluded dependency. |
| S02 | Keep the approved responsibility assignment and escalation contacts. Walk through an unresolved issue and confirm that staff know who prepares advice and who can decide. |
| S03 | Retain the bounded inventory, owner confirmations and unknowns. Reconcile a representative business file against the inventory; investigate missing sources without moving or deleting them automatically. |
| S04 | Show a reviewer one obligation from authoritative source through applicability decision to implementation evidence. Record the review date and any unresolved legal or policy question. |
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
Treating a convenient repository inventory as the whole enterprise; excluding essential dependencies; failing to assign an approving official.
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.