Use Cases

OIKB is the pipeline that feeds your content into Hrida.ai. Hrida.ai indexes it into a Knowledge Base, and every assistant, agent or search built on that Knowledge Base answers from your current content, with citations.

Use case	Sources	Trigger	OIKB mode	Value
Internal knowledge assistant	Confluence, GitHub wiki	Every hour	Daemon + schedule	Instant answers from company docs
Codebase copilot	GitHub repo	Git push	Daemon + webhook	AI always reflects the current code
Customer support agent	Zendesk, Confluence, S3	Nightly	Daemon + cron	Faster ticket resolution
Live sync for writers	Local folder	File save	Watch mode	Docs live seconds after saving
Enterprise knowledge hub	6 sources	Mixed schedules	Daemon + schedule	One assistant with full company context
CI/CD deployment gate	GitHub repo	Release	CLI in CI	Docs always match the released version

Credentials stay in the environment

In the examples below, connector credentials (GITHUB_TOKEN, CONFLUENCE_TOKEN, ZENDESK_TOKEN and so on) are set as environment variables, for example in .env. Don't put them in an entry's token: key: that key overrides the Hrida.ai API key for that entry.

---

1. Internal knowledge assistant

Scenario: Engineering runbooks, product specs and HR policies live in Confluence and a GitHub wiki. Employees want to ask plain-English questions instead of searching.

.hrida-oikb.yaml

sources:
  - name: internal-wiki
    source: confluence:ENG
    kb-id: ${KB_INTERNAL_DOCS}
    interval: 1h
    filter:
      exclude: ["drafts/**", "archive/**"]

  - name: github-wiki
    source: github:your-org/handbook
    kb-id: ${KB_INTERNAL_DOCS}
    interval: 1h
    filter:
      include: ["**/*.md"]

Benefit: answers always come from the latest version of your docs. New Confluence pages reach the assistant within the hour, with no copy-pasting.

---

2. Codebase copilot (webhook-driven)

Scenario: A development team wants an assistant that answers questions about their code: endpoints, function signatures, architecture decisions. It must update on every push.

.hrida-oikb.yaml

sources:
  - name: api-codebase
    source: github:your-org/api-repo
    kb-id: ${KB_CODEBASE}
    webhook: true
    github_secret: ${GITHUB_WEBHOOK_SECRET}
    filter:
      include: ["src/**/*.py", "src/**/*.ts", "docs/**/*.md"]
      exclude: ["**/__pycache__/**", "**/node_modules/**", "**/*.min.js"]

In GitHub, add a webhook to https://oikb.example.com/webhooks/github with the same secret. See Webhooks.

Benefit: the copilot reflects main within seconds of each push, so nobody gets answers about deprecated APIs.

---

3. Customer support agent

Scenario: Thousands of resolved Zendesk tickets, a help centre in Confluence and product manuals as PDFs in S3. An AI agent should suggest answers to new tickets from past resolutions and documentation.

.hrida-oikb.yaml

defaults:
  interval: "0 2 * * *"      # nightly at 02:00

sources:
  - name: zendesk-tickets
    source: zendesk:your-subdomain
    kb-id: ${KB_SUPPORT}

  - name: help-centre
    source: confluence:HELP
    kb-id: ${KB_SUPPORT}

  - name: product-manuals
    source: s3://your-bucket/manuals/
    kb-id: ${KB_SUPPORT}

One Knowledge Base, several sources

Hrida.ai decides which files a sync deletes by comparing that source's file list with the Knowledge Base, so files from another source in the same Knowledge Base can be treated as deleted. The safe pattern is one Knowledge Base per source, all attached to the agent. If you do share a kb-id, run --dry-run for each entry first and check the deleted count.

Benefit: the agent surfaces the right past resolution or manual page automatically, and support engineers spend their time on new problems.

---

4. Live sync for content writers

Scenario: Technical writers edit Markdown locally and want every save to appear in Hrida.ai immediately, with no uploads or batch jobs.

bash

hrida-oikb watch ./docs --kb-id kb-product-docs \
  --url https://studio.company.com --token sk-... --debounce 2.0

Benefit: a zero-friction loop. Content is live in the assistant seconds after Save.

---

5. Enterprise knowledge hub

Scenario: One assistant with full company context: code, wikis, tickets, chat, finance reports and CRM, each synced on its own schedule.

.hrida-oikb.yaml

defaults:
  concurrency: 4
  notify:
    url: ${SLACK_WEBHOOK_URL}
    on: error

sources:
  - name: codebase
    source: github:your-org/main-repo
    kb-id: ${KB_CODE}
    interval: 30m

  - name: confluence-wiki
    source: confluence:ENG
    kb-id: ${KB_WIKI}
    interval: 1h

  - name: jira-tickets
    source: jira:ENG
    kb-id: ${KB_TICKETS}
    interval: "0 6 * * 1-5"

  - name: slack-engineering          # one entry per channel
    source: slack:C0123ENGINEERING
    kb-id: ${KB_CHAT}
    interval: 2h

  - name: slack-product
    source: slack:C0456PRODUCT
    kb-id: ${KB_CHAT_PRODUCT}
    interval: 2h

  - name: azure-reports
    source: az://reports-container/
    kb-id: ${KB_FINANCE}
    interval: "0 3 * * *"

  - name: salesforce-crm
    source: "salesforce:"
    kb-id: ${KB_CRM}
    interval: "0 7 * * 1-5"

Attach all of these Knowledge Bases to one assistant in Hrida.ai. Any failed sync posts to Slack.

Benefit: leadership can ask "What did engineering ship last sprint?" and get one answer citing Jira tickets, GitHub changes and Confluence specs.

---

6. CI/CD deployment gate

Scenario: After every release, sync the release docs and fail the pipeline if the sync didn't fully succeed, so stale docs never reach production.

hrida-oikb sync exits with status 1 if any file fails, so the CLI itself is the gate:

.hrida-oikb.yaml

sources:
  - name: release-docs
    source: github:your-org/api-repo
    path: docs/
    kb-id: ${KB_API_DOCS}

.github/workflows/release.yml (steps)

- name: Sign in to the Hrida AI registry
  run: echo "${{ secrets.HRIDA_GHCR_TOKEN }}" | docker login ghcr.io -u "${{ secrets.HRIDA_GHCR_USER }}" --password-stdin

- name: Sync release docs to Hrida.ai
  run: |
    docker run --rm -v "$GITHUB_WORKSPACE:/data" \
      -e HRIDA_AI_URL -e HRIDA_AI_API_KEY -e GITHUB_TOKEN -e KB_API_DOCS \
      ghcr.io/hrida-ai/hrida-oikb:1.0.3 sync --name release-docs
  env:
    HRIDA_AI_URL: ${{ secrets.HRIDA_AI_URL }}
    HRIDA_AI_API_KEY: ${{ secrets.HRIDA_AI_API_KEY }}
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    KB_API_DOCS: ${{ secrets.KB_API_DOCS }}

Why not POST /sync on the daemon?

POST /sync/{name} starts the sync in the background and returns {"triggered": true} straight away, before anything has been uploaded, so it can't tell you whether the sync succeeded. To gate on a running daemon instead, trigger the sync and then poll GET /health until that source's status is success (not partial or error).

Benefit: the assistant's API documentation always matches the released version. The pipeline guarantees it.