Get Access and Prepare Your Workspace
Before you begin
This task applies to all new users regardless of role. You need network access to the host where Raw to Knowledge is deployed. Have your governance lead available to confirm your role assignment before you start.
Assumed state: Raw to Knowledge has been deployed by a platform administrator. You have been told the service URL.
Steps
1. Confirm the service is running
Send a GET request to the /health endpoint. No authentication body is required.
curl -s http://localhost:8000/health
A healthy service returns HTTP 200 with a JSON body similar to:
{
"status": "ok",
"version": "1.0.0"
}
If you receive a connection error or a non-200 response, contact your platform administrator before proceeding. Do not attempt to ingest data against an unhealthy service.
Note: If your organization deployed Raw to Knowledge on a custom host or port, replace
http://localhost:8000with your configured base URL throughout all examples in this guide.
2. Confirm your assigned role with your governance lead
Raw to Knowledge enforces role-based access for validation and registry operations. Your governance lead maintains the role roster. Confirm which of the following roles has been assigned to you:
| Role | What you can do |
|---|---|
| validator | Claim and decide validation assignments; publish approved answers |
| consultant | Generate readouts; read registry answers |
| support_engineer | Ingest transcripts; review candidates; read classifications |
| content_strategist | Classify candidates; manage answer lifecycle |
| admin | All operations including scope management |
Know your role before you attempt any write operations. The service returns 403 Forbidden if your role lacks the required permission.
3. Verify the OpenAPI documentation UI
Open the following URL in a browser:
http://localhost:8000/docs
The Swagger UI lists every available endpoint, expected request bodies, and response schemas. Use this as your primary API reference during onboarding. If the UI does not load, confirm the service is healthy (step 1) and that your browser can reach the host.
4. Review accepted transcript formats (if you will ingest conversation sources)
If your role includes ingesting meeting transcripts or support conversations, confirm which file format applies to your source system:
| Format | source_type value |
Common source |
|---|---|---|
| WebVTT caption file | vtt |
Zoom, Microsoft Teams |
| SubRip subtitle file | srt |
Various conferencing platforms |
| Plain paragraph text | plain_text |
Pasted notes, support tickets |
| Structured JSON transcript | json |
Custom integrations, API exports |
Prepare sample files in the correct format before your first ingest. Mismatched source_type values cause segmentation errors.
5. Confirm your customer_scope assignment (if applicable)
If your organization uses scope isolation — where each customer account or project has its own knowledge boundary — ask your governance lead for the customer_scope identifier assigned to your accounts.
The customer_scope value is a short string identifier (for example, acme-corp or project-atlas). It controls:
- Which ingest artifacts you tag
- Which registry answers are visible to you in readouts
- Which validation assignments appear in your queue
If your organization does not use scope isolation, this field is optional and can be omitted from all API calls.
Result
You have a confirmed, healthy endpoint. You know your assigned role and the operations you are permitted to perform. You can view the OpenAPI documentation. If you will ingest transcripts, you know the correct source_type for your files. If your organization uses scope isolation, you have your customer_scope identifier.
You are ready to begin working with the Raw to Knowledge system.
See also: Ingest a Conversation Source; Review Extracted Candidates; Horn Information Types