Roles and Responsibilities
Raw to Knowledge assigns responsibilities by role. The role a user holds determines which types of candidates they can review, which decisions they can make, and which system surfaces they interact with most. This topic defines each role and maps it to approval authority.
Role summary table
| Role | What they do in Raw to Knowledge | Horn types they can approve | Primary API surfaces | Read first |
|---|---|---|---|---|
| Consultant / Account Lead | Retrieve approved answers for pre-meeting readouts; query by customer scope; export knowledge for presentations | None (consumers only) | GET /v1/retrieval/search, GET /v1/readouts/ |
What Raw to Knowledge Is and Is Not |
| Validator / SME | Review candidate answers; approve, revise, reject, or escalate; provide corrected text for REVISED decisions | FACT, CONCEPT, PROCEDURE, PROCESS, REFERENCE, TROUBLESHOOTING, RECOMMENDATION | GET /v1/validation/assignments, POST /v1/validation/assignments/{id}/decide |
Validation Authority and Lifecycle |
| Technical Writer / Content Strategist | Export registry answers in Markdown or JSON-LD; apply Horn-type guidance to content planning; manage answer lifecycle review cycles | CONCEPT, PROCEDURE, PROCESS, REFERENCE | GET /v1/registry/answers, GET /v1/retrieval/answers/{id}/export |
Horn Information Types |
| Support Engineer | Query troubleshooting knowledge; inspect contradiction flags; identify post-meeting knowledge gaps; submit Flow B work items for generation | TROUBLESHOOTING, RECOMMENDATION | GET /v1/retrieval/search, GET /v1/graph/answers/{id}/contradictions, POST /v1/generation/work-items |
Flow A vs Flow B |
| Knowledge Architect / Governance Lead | Govern the full knowledge lifecycle; manage escalation queues; monitor quality metrics; configure review-due policies; declare supersessions and retirements | All types including ESCALATED queue | GET /v1/dashboard/metrics, GET /v1/validation/assignments?state=ESCALATED, POST /v1/registry/answers/{id}/retire |
Privacy, Scope, and Provenance |
| Platform Admin / Integration Developer | Configure ingest connectors, Celery workers, Weaviate and Neo4j sync; manage API access; monitor Prometheus metrics; resolve infrastructure errors | None (platform layer; no answer approval authority) | GET /metrics, GET /v1/health, all admin endpoints |
System Surfaces and Data Stores |
Role descriptions
Consultant / Account Lead
Consultants and account leads are consumers of the registry. Their work begins where the pipeline ends: they retrieve answers that have already been validated and approved, filtered to the customer scope relevant to their engagement. In practice, this means querying for pre-meeting readouts before a customer call, downloading a Markdown export to incorporate into a briefing document, or running a semantic search when they need a specific claim.
Consultants do not submit content to the pipeline, do not review candidates, and do not have authority to approve or reject answers. Their trust in the system depends on the rigor applied by validators and governance leads upstream.
Validator / SME
Validators are the human checkpoint between extracted candidates and the approved registry. A candidate arrives in the validation queue carrying a classification, an assertion grammar (for FACTs), and provenance metadata. The validator's job is to read the source transcript segment, assess whether the answer is accurate, complete, and appropriately typed, and then record a decision: APPROVED, REVISED, REJECTED, or ESCALATED.
For REVISED decisions, the validator provides corrected answer text. The revised candidate re-enters the classification pipeline before returning to the queue — this ensures that a validator's correction does not bypass the typing step.
Validators hold authority for most Horn types. Their authority is bounded by the KGS authority table: some high-stakes fact subtypes, and all PRINCIPLE answers, may require governance-lead sign-off depending on deployment configuration.
Technical Writer / Content Strategist
Technical writers interact with Raw to Knowledge as a structured source of truth that feeds their content work. They export approved answers in formats suitable for documentation tools, apply Horn-type reasoning to identify gaps in existing content, and participate in lifecycle management by flagging answers approaching their review-due dates.
Technical writers may also serve as validators for CONCEPT, PROCEDURE, PROCESS, and REFERENCE types — the categories most directly relevant to documentation.
Support Engineer
Support engineers are both consumers and contributors. As consumers, they query the retrieval endpoint for troubleshooting knowledge during active support cases. As contributors, they identify questions from support conversations that produced no answer (Flow B candidates) and submit generation work items so those gaps can be addressed.
Support engineers also use the graph endpoint to inspect contradiction flags — situations where two approved facts assert incompatible claims about the same subject. Identifying a contradiction early in a support case prevents incorrect guidance from reaching a customer.
Knowledge Architect / Governance Lead
The governance lead is accountable for the overall quality and integrity of the knowledge registry. This role manages the escalation queue — the cases too complex or too sensitive for a standard validator decision. They configure policies for review-due intervals, oversee answer lifecycle transitions (including supersession and retirement), and use the dashboard to monitor queue health, classification confidence distributions, and answer aging.
The governance lead is the only role authorized to retire answers — removing them from active retrieval while preserving them in the audit history.
Platform Admin / Integration Developer
Platform admins keep the pipeline running. They configure the ingest connectors and source formats (including VTT, SRT, plain text, Markdown, HTML, PDF-derived text, and JSON), manage the Celery worker queues, monitor Prometheus metrics, and coordinate Weaviate and Neo4j sync jobs. When a generation task fails or a sync job falls behind, the platform admin is the first responder.
Important: Platform admins do not approve answers. Separation of duties is enforced — the platform layer and the governance layer are distinct. A platform admin who also needs approval authority must hold an additional role assignment in the validation system.
Approval authority matrix
The KGS (Knowledge Governance System) authority table maps each Horn type to the role authorized to approve it. The matrix below reflects the default configuration.
| Horn Type | Approving role(s) | Notes |
|---|---|---|
| FACT — EXISTENCE | Validator / SME | Standard validator decision |
| FACT — CAPABILITY | Validator / SME | Standard validator decision |
| FACT — CONFIGURATION | Validator / SME | Standard validator decision |
| FACT — STATE | Validator / SME | Standard validator decision |
| FACT — CONSTRAINT | Validator / SME | May require governance-lead review if constraint is customer-contractual |
| FACT — TEMPORAL | Validator / SME | Standard validator decision |
| CONCEPT | Validator / SME, Technical Writer | Both roles can approve |
| PROCEDURE | Validator / SME, Technical Writer | Both roles can approve |
| PROCESS | Validator / SME, Technical Writer | Both roles can approve |
| PRINCIPLE | Knowledge Architect / Governance Lead | Elevated authority required; principles apply broadly |
| REFERENCE | Validator / SME, Technical Writer | Both roles can approve |
| TROUBLESHOOTING | Validator / SME, Support Engineer | Support engineers can approve in their domain |
| RECOMMENDATION | Validator / SME | Standard validator decision |
| OPEN_ISSUE | Cannot be approved | Always escalates; governance lead manages the escalation queue |
Note: OPEN_ISSUE is the one type that can never receive an APPROVED decision. When a candidate is classified as OPEN_ISSUE, the validation system routes it to ESCALATED status. A specialist must either source a valid answer (creating a new candidate of the appropriate type) or formally record that the question is unresolved. The OPEN_ISSUE record itself remains in the candidates table for audit purposes.