Practical answers about working with Ridian.

Both, where it makes sense. Most engagements start by deploying a focused, grounded assistant on top of your existing content and tools — not a custom model. We build custom orchestration (Ridian OS, Meridian) when standard tooling cannot give you the structure, traceability, or routing your workflow needs.

A scoped Knowledge Assistant deployment. One use case, one content surface, one branded interface. Typically the fastest way to prove value and get an honest read on whether broader orchestration is worth pursuing.

Yes — and we recommend it. A short pilot lets us validate scope, data quality, and adoption with low commitment. If it works, we expand. If it does not, you have not paid for a giant build.

It is grounded on your real content. Every answer comes from approved sources you provide — public website pages, internal documents, policies, knowledge bases — and every answer is rendered with linked sources back to the page it came from. No invented facts, no hallucinated links.

Public web pages, PDFs, handbooks, policies, support articles, wikis, and structured knowledge bases. Sources are reviewed and approved before they enter the retrieval layer.

Embedded on your public site, inside an internal portal, or as a customer-facing knowledge experience — whichever surface your people already use. Branding, tone, and scope are configured per deployment.

It will say so honestly. The system prompt instructs the model to refuse to invent facts and to suggest contacting Ridian for anything outside its grounded sources.

Approved content is indexed into the retrieval layer that serves your assistant. No content is silently uploaded to a third party — we work with you on what gets indexed, where it sits, and who has access.

Provider API keys, OAuth client secrets, and any user OAuth tokens stay server-side. The browser only ever sees status metadata. Secrets are never logged.

Not by Ridian. Provider behavior depends on your contract with the provider (OpenAI, Google, Microsoft). For Microsoft 365 / Copilot and Vertex AI deployments, your enterprise terms typically exclude prompts from training by default — we'll confirm this against your environment before deployment.

The default chat panel keeps history in the browser session only. Persistent storage of conversations is opt-in and configured per deployment, with retention rules that match your policies.

Ridian OS is the agentic spine — the workspace where human direction becomes coordinated agent work. It captures intent, structures it into a plan, routes steps to specialized agents, and surfaces visible next actions for human approval.

Meridian is the delivery and routing layer for approved Ridian OS outputs. It connects approved work to real destinations — local exports, cloud storage, client folders, email drafts, GitHub, APIs, and project knowledge stores — while preserving human approval gates and traceable delivery records.

No. Most teams start with a Knowledge Assistant only. Ridian OS and Meridian enter the picture when knowledge work expands into multi-step execution — drafting artifacts, routing approvals, and delivering approved outputs back to systems of record.

Typically a few weeks from kickoff to a deployed, branded assistant grounded on your approved content. Speed depends most on how organized the source content already is, not on the AI work.

Brief intake → scoped proposal → content review → assistant build with you → deployment to your chosen surface → tuning pass after first usage. We confirm acceptance criteria at the start so success is not a moving target.

A clear problem statement, the content the assistant should ground on, and a single decision-maker who can approve scope. The Start an AI Project intake captures all of this in one pass.

Yes. For teams new to working with AI, a short literacy and prompting workshop sharply increases the value people get from the assistant. We tailor content to the actual deployment so training is not generic.

Per deployment: assistant usage volume, share of questions answered with a grounded source, and qualitative feedback from end users. We don't pretend a vanity metric is a business outcome.

Bad answers are usually a content gap or a retrieval-tuning issue, not a model issue. We treat them as inputs to the refinement pass — adjusting grounding, scoping, and retrieval rather than swapping models.