KNOBE Enterprise Profile v1 Non-normative

This page is non-normative guidance for using KNOBE in enterprise AI pipelines and knowledge management. Nothing here changes the protocol. If this document conflicts with the normative specification, the specification governs.

The pipeline loop this profile documents: a source is sealed with its terms; agent output chains to the source by hash; a gate verifies the chain before the output is used.

1. Sourcesealed with its terms
   →
2. Agent outputchains to the source by hash
   →
3. Gateverifies before use

A broken seal cannot anchor a chain; the gate reads the verdict before anything downstream consumes the artifact.

§1Why KNOBE in enterprise pipelines

An enterprise AI pipeline is a sequence of transformations. A document is retrieved, chunked, embedded, summarized, synthesized with other sources, drafted into a response, and handed to the next tool or model. Each hop is a compression, and at each hop the conditions that made the input trustworthy travel less reliably than the text: what the source was, whether it was current, what the output can and cannot be relied on for, and whether a human has reviewed it. The result is an orphaned fragment: content detached from the context that made it interpretable, and the coordination cost of re-establishing that context by hand at every stage.

KNOBE gives each artifact a portable, hash-sealed record of its own provenance and limits. It is a system of context that rides alongside the systems of record an enterprise already runs (the data warehouse, the vector store, the document management system) rather than replacing them. A .knobe.md file is plain text, diff-able in version control, readable without a proprietary client, and verifiable with a small script, which makes it durable across vendor changes and auditable after the fact.

The most consequential field for AI pipelines is quarantine_status. Model- and agent-generated artifacts default to quarantine; promotion to trusted is a governed step, not a side effect of generation. This quarantine-first posture keeps unreviewed machine output from silently acquiring the authority of a reviewed source as it flows downstream.

§2Recommended field defaults for pipeline use

Recommended content_type values for pipeline artifacts

§3Data-classification mapping

The protocol's open vocabulary for privacy_level is: public, internal, sensitive, restricted. Most enterprises already run a classification scheme; the field declares the artifact's class so it travels with the object, and complements, rather than replaces, existing data-loss-prevention and classification controls.

§4Pipeline and attribution roles

The protocol requires an attribution.sources array with at least one entry, each with author and contribution. Adding a role makes provenance records interoperable across pipeline stages and tools. The following roles are recommended for enterprise workflows.

Model contribution disclosure

For model- or agent-generated artifacts, the contribution of an ai_assistant source should be specific enough that a downstream consumer understands what the model did: which model and release, what it was given, and what it produced ("summarized the retrieved source; did not consult any other document" or "drafted three candidate responses ranked by a reranker; no human edit"). Specific disclosure is what lets a reviewer, or another agent, decide how far to trust the output.

§5Fidelity limit templates

The fidelity_limits field states what an artifact is fit for and what must not be inferred from it. In a pipeline this keeps a synthesis from being treated as a verified source, a draft from being shipped as final, and a compression from standing in for the document it condensed.

{
  "fidelity_limits": {
    "represents": "a synthesis over [N] retrieved sources as listed in attribution",
    "trust_as": "a starting point that must be checked against the cited sources",
    "do_not_infer": [
      "that every retrieved source was authoritative or current",
      "that citations, if present, were verified against the sources",
      "that coverage is complete: retrieval may have missed relevant material"
    ]
  }
}

{
  "fidelity_limits": {
    "represents": "an agent-generated draft, unreviewed at time of sealing",
    "trust_as": "a candidate for human review, not an approved response",
    "do_not_infer": [
      "that any claim has been verified",
      "that the draft reflects current policy or data",
      "that it is cleared for customer-facing or external use"
    ]
  }
}

{
  "fidelity_limits": {
    "represents": "a compression of [source], approximately [X]% of original length",
    "trust_as": "an accurate summary of the source's main points",
    "do_not_infer": [
      "that all nuance, exceptions, or edge cases are preserved",
      "that this should substitute for the source in a decision of record"
    ]
  }
}

§6Use condition templates

The use_conditions field carries the originator's declared terms for downstream use, terms that would otherwise be lost as the artifact crosses pipeline boundaries.

{
  "use_conditions": {
    "license": "All rights reserved",
    "permitted": [
      "internal retrieval, synthesis, and review"
    ],
    "requested_preservations": [
      "cite the source by identifier when summarizing",
      "keep quarantine status on machine output until a human review clears it"
    ],
    "consent_note": "Internal use only. Not for external distribution."
  }
}

{
  "use_conditions": {
    "license": "Shared under agreement",
    "permitted": [
      "use within the scope of the governing agreement"
    ],
    "requested_preservations": [
      "do not redistribute beyond the agreed parties",
      "preserve attribution and fidelity limits"
    ],
    "consent_note": "Shared under [agreement reference]. Handling per that agreement."
  }
}

§7UI label translations

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

§8Interoperability

KNOBE is a plain-text object with a stable, hashable payload, which makes it straightforward to carry alongside, or reference from, the open packaging and identifier standards an enterprise may already use. The mappings below are non-normative and describe complementary use, not equivalence.

§9Worked example: source and agent synthesis

The two examples below form a verifiable pipeline lineage. A human-maintained knowledge-base document is the trusted source; an agent-generated summary is a synthesis that references the source by hash and carries quarantine_status: quarantine. Download both and verify with lens.py. The pair shows quarantine-first in practice: a trusted input produces an untrusted output that cannot be mistaken for a reviewed source, and whose single retrieved source is provable rather than asserted.

What the lineage demonstrates

Opening the synthesis's parents array reveals one entry with a payload hash. Verify that hash against the knowledge-base source above and it matches: the summary names that exact document as its source. The hash identifies the referenced document precisely; the derivation itself is a declaration by the sealing pipeline: tamper-evident, but not independently proven. The source is trusted; the synthesis is quarantine. Nothing about generating the summary promoted it: trust is conferred by an explicit review step, recorded by a reviewer role, not by the act of generation. The chain (human-maintained source, agent synthesis, pending review) is sealed and checkable in version control, without a pipeline-observability platform or database. The artifacts carry their own lineage.