Horn Information Types
Raw to Knowledge classifies every candidate answer using Robert Horn's Information Mapping methodology. Horn's framework defines discrete categories of knowledge based on what kind of claim the content makes. In Raw to Knowledge, the information type assigned to an answer determines how it is stored, who can approve it, how it is searched and retrieved, and whether it can conflict with other answers.
Note: Information Mapping was developed by Robert E. Horn as a method for structuring technical content so readers can locate and use information efficiently. Raw to Knowledge applies Horn's type taxonomy to knowledge governance — ensuring that different kinds of claims are handled by people with the appropriate expertise and are evaluated against the appropriate criteria.
The nine Horn types
| Type | Definition | When used | Validation authority | Reuse context |
|---|---|---|---|---|
| FACT | A specific, testable claim about the world. Must carry an assertion subtype and a fully populated assertion grammar (subject, predicate, object, scope). The most rigorous governance path. | A specific product capability, configuration setting, measured state, or time-bounded claim was stated in the source. | Validator / SME (subtype-dependent; CONSTRAINT may require governance lead) | Pre-meeting readouts, product datasheets, capabilities matrices, contradiction detection |
| CONCEPT | Defines what a term, system, or thing is. Establishes meaning and boundaries. | A term was defined, or the nature of a product, process, or component was explained. | Validator / SME, Technical Writer | Glossaries, onboarding content, product documentation |
| PROCEDURE | An ordered sequence of steps to accomplish a task. Steps must be tested, complete, and sequentially executable. | A how-to was provided: configuration steps, setup instructions, a troubleshooting resolution sequence. | Validator / SME, Technical Writer | Runbooks, knowledge base articles, support documentation |
| PROCESS | Describes how something works as a system — not how to do it. Focuses on the mechanism, not the user action. | Background context was provided explaining a system's internal behavior, data flow, or automated behavior. | Validator / SME, Technical Writer | Architecture documentation, training materials |
| PRINCIPLE | A governing rule, design philosophy, or decision heuristic that applies broadly. Not a specific factual claim — principles describe intent or guidance. | A design decision rationale, architectural philosophy, or organizational policy was articulated. | Knowledge Architect / Governance Lead | Architecture decision records, governance documentation |
| REFERENCE | Lookup data: tables, version numbers, API parameters, configuration values, specifications. | Structured, stable lookup information was provided (pricing tiers, version compatibility matrices, field definitions). | Validator / SME, Technical Writer | API docs, configuration references, release notes |
| TROUBLESHOOTING | A problem → cause → solution structure. Connects a symptom or error to its root cause and resolution. | A support case, error condition, or configuration problem and its fix were discussed. | Validator / SME, Support Engineer | Knowledge base articles, support runbooks, incident retrospectives |
| RECOMMENDATION | Advice about the best approach, given a context. Softer epistemic status than FACT — it is a considered opinion, not a testable claim. | Best practices, preferred configurations, or strategic guidance were offered. | Validator / SME | Advisory content, pre-sales guidance, customer success materials |
| OPEN_ISSUE | An unresolved question that has no validated answer. The question was raised, but no answer is available from the conversation or the knowledge base. | A question was asked but unanswered; the issue is genuinely unresolved at the time of ingestion. | Cannot be approved — always escalates | Escalation tracking; identifies knowledge gaps in the registry |
Important: OPEN_ISSUE is the only type that can never receive an APPROVED decision. The validation system enforces this at the application layer. An OPEN_ISSUE candidate is automatically routed to ESCALATED status when it reaches the validation queue. The governance lead manages the escalation queue and is responsible for resolving or formally recording these gaps.
FACT assertion subtypes
FACT is the most governance-intensive type because facts are testable, comparable, and potentially contradictory. Every FACT candidate must carry one of six assertion subtypes. The subtype determines what kind of claim is being made and guides the validator in assessing its accuracy.
| Subtype | Definition | Example |
|---|---|---|
| EXISTENCE | Asserts that something exists or is available | "Multi-factor authentication is available for all enterprise tiers." |
| CAPABILITY | Asserts that something can do or support something | "The platform supports automatic failover across three AWS regions." |
| CONFIGURATION | Asserts how something is set up or configured | "Default session timeout is 30 minutes for standard accounts." |
| STATE | Asserts the current condition or status of something | "API v2 is deprecated as of Q3 2024." |
| CONSTRAINT | Asserts a limitation, boundary, or restriction | "Tenant data exports are limited to 10,000 records per request." |
| TEMPORAL | Asserts something that was true at a specific time, or will be true at a future time | "Feature parity between regions was achieved in release 4.2." |
Assertion grammar
For every FACT candidate, the classification engine populates a four-field assertion grammar. This structured representation is what makes FACT answers machine-comparable — it is the basis for contradiction detection in the graph layer.
| Field | Meaning | Example value |
|---|---|---|
| Subject | The entity the claim is about | enterprise tenants |
| Predicate | The relationship or property being asserted | supports automatic failover |
| Object | The value or target of the predicate | 3 AWS regions, RTO < 15 minutes |
| Scope | The context in which the claim holds (environment, time, condition) | production environment |
When two FACT answers share the same subject, predicate, and scope but have different object values, the graph layer flags this as a ConflictFlag. This conflict is surfaced to validators and governance leads before the newer answer can be approved, allowing a human to determine which version is correct and to supersede the other.
Note: Validators who review FACT candidates are responsible for verifying that the assertion grammar fields accurately represent the source statement. A validator can correct grammar fields during the REVISED decision flow — corrected grammar triggers re-classification before the candidate returns to the queue.
Classification confidence and forced review
The classifier produces a confidence score for every type assignment. Two conditions force requires_review = True regardless of confidence:
- Confidence score is below 0.75
- Assigned type is OPEN_ISSUE
A requires_review = True flag means the candidate will be routed to a human validator without exception, even if the pipeline is configured for high-confidence bypass in other configurations. This ensures that uncertain classifications and all unresolved questions always receive human attention.