KNOBE Government Profile v1 Non-normative

This page is non-normative guidance for using KNOBE in public-sector records work. Nothing here changes the protocol. If this document conflicts with the normative specification, the specification governs.

The record loop this profile documents: a record is sealed at creation; a redaction is sealed as a transform of it; the public release verifies against that lineage.

1. Recordsealed at creation
   →
2. Redactionsealed as a transform of it
   →
3. Releaseverifies against its lineage

Each link is a payload hash: the release names exactly which record and which redaction it came from.

§1Why KNOBE in government

Public-sector records outlive the systems that hold them. A record created in one case-management platform is migrated to another, exported for litigation, released under FOIA, adapted for accessibility, summarized for a briefing, and increasingly ingested by AI tools that compress and recombine it. At each step, the conditions that made the record interpretable travel less reliably than the content: who issued it and under what authority, what it can and cannot be trusted to represent, what was withheld and on what legal basis, and whether it is the version of record or a downstream derivative.

KNOBE addresses this at the artifact layer, without requiring an agency to adopt a new system of record. A .knobe.md file is readable in any text editor, verifiable with a small Python script, and self-describing: it carries attribution, source relations, transformation history, fidelity limits, handling terms, and a hash-sealed integrity check. It is a system of context that rides alongside whatever systems an agency already runs.

Three government problems map directly onto the protocol's fields. Chain of custody and provenance: attribution, parents, and transformation_history record where a record came from and what has been done to it. Release integrity: a redacted FOIA production can reference the unaltered source by hash, a precise, tamper-evident identification of the exact record it declares as its source, checkable whenever that record is produced. Accessibility as legal obligation: Section 508 and WCAG adaptations (alt text, plain-language versions, captions, translations) can be recorded with the adapter's labor visible and the source preserved, rather than circulating as detached copies. KNOBE records who produced an adaptation and how it relates to its source; it does not itself certify that an adaptation meets Section 508 or WCAG, which remains the agency's determination.

§2Recommended field defaults for government use

Recommended content_type values for government artifacts

§3Sensitivity and handling guidance

The protocol's open vocabulary for privacy_level is: public, internal, sensitive, restricted. In government contexts these declare handling intent and travel with the artifact; they do not replace an agency's marking systems or governing authorities.

§4Custody and attribution roles

The protocol requires an attribution.sources array with at least one entry. Each source should include author and contribution. Adding a role to each entry makes custody records interoperable across tools. The following roles are recommended for government workflows.

§5Fidelity limit templates

The fidelity_limits field tells a recipient what an artifact is fit for and what must not be inferred from it. In records work it makes the difference visible between a redacted release and a complete record, between a briefing and its underlying evidence, and between an AI-assisted summary and verified content.

{
  "fidelity_limits": {
    "represents": "the redacted public version of [record] as released under [authority]",
    "trust_as": "an accurate reproduction of the source record with [category] withheld",
    "do_not_infer": [
      "that redacted passages are absent from the source, they are withheld, not deleted",
      "that this release reflects events after the source record's date",
      "that withheld content implies any particular fact about its subject"
    ]
  }
}

{
  "fidelity_limits": {
    "represents": "the authoritative published version of [notice/report] as issued",
    "trust_as": "the official statement of record as of the created_date",
    "do_not_infer": [
      "that real-time conditions or later corrections are reflected here",
      "that this remains current after a later record supersedes it"
    ]
  }
}

{
  "fidelity_limits": {
    "represents": "a summary of [records] assisted by AI as described in attribution",
    "trust_as": "a starting point for review, not a substitute for the underlying records",
    "do_not_infer": [
      "that AI-generated statements have been independently verified",
      "that every source record was consulted in full",
      "that the summary captures all legally material detail"
    ]
  }
}

§6Use condition and release templates

The use_conditions field carries the originator's declared terms for how the next person may use the artifact, terms that otherwise get separated from the record as it moves.

{
  "use_conditions": {
    "license": "Public domain (U.S. Government work)",
    "permitted": [
      "republish, quote, and redistribute freely",
      "incorporate into downstream products and tools"
    ],
    "requested_preservations": [
      "preserve the issuing authority and record identifier when republishing",
      "preserve fidelity limits so recipients read the record correctly"
    ]
  }
}

{
  "use_conditions": {
    "license": "Not for public release",
    "permitted": [
      "internal review and records retention"
    ],
    "requested_preservations": [
      "do not release externally without records-office review and required redaction",
      "preserve the governing authority reference"
    ],
    "consent_note": "Controlled handling. Contains material subject to [CUI category / statute / legal hold]."
  }
}

§7UI label translations

Protocol field names are precise but not always the right language for a records-facing interface. The following translations are recommended for government tools. The protocol field names remain unchanged in the payload; these labels apply only at the display layer.

§8Worked example: a record and its release

The two examples below form a verifiable release lineage. An internal inspection memo is the record of origin; a FOIA release is a redacted public version that references the source memo by hash. Download both and verify with lens.py. The release declares its source by payload hash. A recipient cannot see the restricted memo, but the reference is precise and tamper-evident: if the source record is ever produced (in litigation, audit, or a later release), anyone can confirm it is the exact record the release named at sealing. The derivation itself is declared by the issuing office, not proven by the hash.

What the lineage demonstrates

Opening the release's parents array reveals one entry with a payload hash. Verify that hash against the source record above and it matches: the release names that exact record as its source, and no other. The hash proves the identity of the referenced record precisely; the derivation and the faithfulness of reproduced text remain declarations by the issuing office: sealed, attributable, and tamper-evident, but not independently proven. The redaction field records the governing exemption and the scope of what was withheld, so the basis for withholding travels with the release rather than living only in a separate log. The chain (originating office certifies the record, FOIA office redacts and releases) is sealed and checkable without any case-management system, portal, or database. The artifacts carry their own custody.