Skip to content

Glossary

This glossary defines Raw to Knowledge-specific terms alphabetically. For Horn type definitions, see Horn Information Types. For validation state definitions, see Validation Authority and Lifecycle.

Approved Answer : The canonical unit of knowledge in the Raw to Knowledge registry. An approved answer is an immutable record created when a validator approves a candidate. It carries a Horn type, assertion grammar (for FACTs), provenance fields, evidence links, a version number, and a review due date. Approved answers are the only content surfaced in readouts, retrieval, and exports.

Assertion Grammar : The four-field structured representation of a FACT-type answer: subject, predicate, object, and scope. The assertion grammar makes facts machine-comparable and is the basis for contradiction detection in the graph layer. Grammar fields are populated by the classification engine and may be corrected by a validator during a REVISED decision.

Assignment : The action a validator takes to claim a candidate from the validation queue. Once a validator assigns a candidate to themselves, it transitions to IN_REVIEW status. Assignments are tracked as session-scoped locks in Redis to prevent two validators from reviewing the same candidate simultaneously.

Candidate Answer : A question-and-answer pair extracted from a transcript segment that has not yet been validated. Candidates are the working data of the pipeline. They exist in the CandidateAnswer table and progress through the 9-state validation machine. Only approved candidates become approved answers. Rejected candidates remain in the table for audit purposes but are never surfaced to consumers.

Candidate Question : The question text extracted from a transcript segment during intake. A candidate question may or may not have a corresponding answer in the source (see Flow A and Flow B). The candidate question is the anchor of a candidate record and persists through the pipeline regardless of whether the answer is sourced from the transcript or generated.

Circuit Breaker : A fault-tolerance mechanism on the raw_to_knowledge_generation Celery queue. If the LLM service or a RAG source returns errors above a configured threshold rate, the circuit breaker opens and subsequent generation tasks fail immediately with a clear error rather than queuing. This prevents cascading failures when downstream dependencies are degraded. The circuit resets automatically after a configured cooldown period.

Classification Record : A database record created for each candidate during the classification stage. It stores the assigned Horn type, the classification confidence score, the FACT assertion subtype (if applicable), the populated assertion grammar fields, and the requires_review flag. Classification records are retained as part of the audit trail even after a candidate is approved, rejected, or superseded.

Conflict Flag : A record created when two approved answers assert incompatible claims — specifically, when two FACT answers share the same subject, predicate, and scope but have different object values. A conflict flag is raised during validation (blocking the APPROVED decision by default) and is also created by the ContradictionDetector running in the raw_to_knowledge_graph worker. Conflict flags are surfaced in readouts, the graph API, and the governance dashboard.

Customer Scope : An optional field on approved answers that associates the answer with a specific customer engagement. Customer scope is enforced at the repository layer: readouts for Customer A will never include answers scoped exclusively to Customer B. Answers without a customer scope value are considered universally applicable and appear in all readouts where their Horn type and content are relevant.

Evidence Links : A list of URIs attached to every approved answer that point to the sources supporting the answer. Evidence links may reference source transcript artifacts, Confluence pages, Jira issues, or other verifiable documents. At least one evidence link is required for registry insertion — a missing evidence link raises a ProvenanceError. Evidence links appear in both Markdown and JSON-LD export formats.

Flow A : The primary intake path for candidates where both a question and an answer are present in the source transcript. The answer text is extracted directly from the relevant transcript segment. Flow A candidates enter the validation queue carrying answer text from a human speaker in context. See Flow A vs Flow B.

Flow B : The intake path for candidates where a question was raised in the transcript but not answered in the session. Flow B candidates carry only question text. A work item must be submitted to the AGWMP generation pipeline to produce a candidate answer from internal knowledge sources (Confluence, Jira, existing registry answers via Weaviate). Both flows converge at the validation queue. See Flow A vs Flow B.

Generated Candidate : A candidate answer produced by the AGWMP pipeline for a Flow B work item. A generated candidate includes the generated answer text, the RAG sources used in generation, the F2 score, and the model parameters applied. Generated candidates enter the standard validation queue and are subject to the same approval requirements as Flow A candidates. Validators should apply elevated scrutiny to generated candidates and verify all citations.

Horn Type : One of nine information categories defined by Robert Horn's Information Mapping methodology. The nine types are: FACT, CONCEPT, PROCEDURE, PROCESS, PRINCIPLE, REFERENCE, TROUBLESHOOTING, RECOMMENDATION, and OPEN_ISSUE. The assigned Horn type governs who can approve the answer, how it is stored, and how it participates in retrieval and contradiction detection. See Horn Information Types.

Known Answer : An existing approved answer in the registry that semantically matches a Flow B question at Weaviate similarity ≥ 0.92. When a known answer is found, the AGWMP pipeline returns it directly without generating a new candidate. This prevents the accumulation of redundant candidates for questions the registry has already resolved.

Legal Basis : A GDPR Article 6 declaration attached to every source artifact that specifies the lawful ground for processing personal data in the transcript. Valid values are: CONSENT, LEGITIMATE_INTEREST, CONTRACT, LEGAL_OBLIGATION. The value NOT_ASSESSED blocks the artifact from advancing past the intake stage. Legal basis must be declared at ingest — it cannot be added retroactively without re-ingesting the artifact.

Open Issue : A candidate classified as OPEN_ISSUE — a question that has no validated answer available. OPEN_ISSUE is the one Horn type that cannot receive an APPROVED decision. All OPEN_ISSUE candidates are automatically escalated to the specialist queue. They serve as a formal registry of knowledge gaps and require manual resolution by the governance lead.

Owner Role : The role accountable for an approved answer's accuracy. The owner role is set to the approving validator's role at the time of approval and is stored as a provenance field on the registry record. Owner role is required for registry insertion — a missing owner role raises a ProvenanceError.

Provenance : The complete record of where an approved answer came from, who approved it, and what evidence supports it. In Raw to Knowledge, provenance is enforced as a registry insertion requirement via three mandatory fields: validation_record_id, owner_role, and evidence_links. See Privacy, Scope, and Provenance.

RAG Context : The set of retrieved documents assembled by the RAGContextBuilder for a Flow B generation task. RAG context draws from four source tiers ranked by relevance: existing approved answers from the registry, Confluence pages, Jira issues, and other configured sources. A minimum of two qualifying sources is required before generation proceeds. If fewer than two sources are found, the work item is escalated rather than attempted.

Readout : A customer-scoped, pre-meeting briefing assembled from approved answers in the registry. Readouts are generated on demand and filtered by customer scope, Horn type preferences, and recency. Answers within 30 days of their review-due date are flagged in readouts. Disputed and retired answers are excluded. Readouts are a primary consumption surface for consultants and account leads.

Registry : The PostgreSQL table of approved answers (ApprovedAnswer). The registry is the authoritative, governed, production-ready body of knowledge in Raw to Knowledge. Only answers that have passed human validation enter the registry. The registry is write-once per answer version (immutable after insert). Query the registry via GET /v1/registry/answers.

Review Due Date : The date by which an approved answer must be re-examined and either re-approved, superseded, or retired. Review due dates are set at approval time based on configurable intervals per Horn type. Answers within 30 days of their review-due date are flagged in readouts and the dashboard. Answers past their review-due date are not automatically retired but are marked overdue.

Source Artifact : The ingested source file or payload. A source artifact record captures the original content, its format (VTT, SRT, TXT, Markdown, HTML, PDF-derived text, or JSON), its privacy class, its declared legal basis, and the ingest timestamp. All downstream records (segments, candidates, classification records) are traceable to their source artifact.

Supersession : The process by which a new version of an approved answer replaces an older one. Supersession requires a full validation cycle for the new version — the old answer is not modified, and no edit-in-place occurs. When the new version is approved, the system automatically links the new record to the old via supersedes_id and sets the old record's status to SUPERSEDED. The full supersession chain is traversable in the Neo4j graph and via the API.

Transcript Segment : A discrete unit of transcript text extracted during intake. Each segment carries a speaker identifier, a timestamp range, and the segment text. Segments are the atomic unit for all downstream extraction and analysis. Q/A pair detection, privacy tagging, and evidence links all operate at the segment level.

Validation Authority : The role-based permission to make binding validation decisions on candidates of a given Horn type. Authority is defined in the KGS (Knowledge Governance System) authority table. A validator without authority for a given type can review the candidate but cannot approve or revise it — they can only escalate or reject. See Roles and Responsibilities for the full authority matrix.

Validation Record : A database record capturing a single validator decision. Each validation record stores the decision type (APPROVED, REVISED, REJECTED, ESCALATED), the validator's role, the timestamp, any revision text provided, and the reason for the decision. Validation records are immutable audit records — they are never deleted. The validation record ID is required for registry insertion.

Version Chain : The linked sequence of approved answer records that have superseded one another over time. Each approved answer carries a supersedes_id pointing to the previous version. The chain can be traversed backward to the original version. Version chains are visible in the Neo4j graph via SUPERSEDES relationships and queryable via the registry API.

Work Item : A task record submitted to the AGWMP generation pipeline for a Flow B candidate. A work item captures the question reference, the submission timestamp, and the current status (PENDING, IN_PROGRESS, COMPLETED, ESCALATED, FAILED). Work items are processed by the raw_to_knowledge_generation Celery worker. Completed work items produce a generated candidate that enters the validation queue.