Key facts
| Embeddings | Live embeddings API for versioned SOP and policy retrieval |
| Generation | OpenAI-compatible chat completions with JSON mode for decisions (live) |
| Pipeline | Ingest, version, embed, retrieve, decide, execute, log |
| Models | 30+ models; routine routing on plugsky-micro or plugsky-lite |
| Versioning | Store document version with each vector so decisions cite the live policy |
| Pricing | Flat monthly self-serve plans with no per-token charges on self-serve |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
| Roadmap | Files and batch endpoints are coming soon; ingest documents in your pipeline today |
TL;DR
- Retrieve the current policy for the trigger before deciding anything.
- Return structured decisions that cite the rule and its version.
- Keep deterministic steps in code; let retrieval own policy knowledge.
- Re-index on document changes and expire superseded versions.
- Replay historical cases after every policy or prompt update.
How it works, step by step
- List the process triggers and the policies or SOPs each one depends on.
- Ingest documents with version, jurisdiction, process and effective-date metadata.
- Chunk on sections and clauses, then embed and index them for filtered retrieval.
- At trigger time, retrieve the applicable clauses and pass them with the case context.
- Require a structured decision naming the rule, version and next action.
- Execute deterministic steps in code and gate risky ones behind approval.
- Log trigger, retrieved clauses, decision and outcome, and audit decisions when policies change.
Try it yourself
Open the RAG architecture builder →
Policy retrieval drives the branch
Automation that encodes business rules in prompts rots quickly because policies change and the prompt does not. RAG flips that: keep the rules in versioned documents, retrieve the clauses that apply to each case, and let the model select the branch with the evidence attached. When a policy changes, you re-index instead of rewriting prompts.
Retrieval must be scoped. Filter by process, jurisdiction, product and effective date before ranking so an old policy version cannot leak into a decision. Store the document version with every vector, because an automated decision's audit trail is only as good as the policy text it relied on.
Structured decisions with citations
Ask for a decision object, not prose: the chosen action, the rule id and version that supports it, any exceptions applied, and a confidence value. Validate that object against your own rule engine before executing, because the model is proposing, not authorising.
{action, rule_id, rule_version, exceptions[], confidence}makes decisions machine-checkable.- Reject decisions citing superseded or out-of-scope clauses.
- Route low-confidence or exception-heavy cases to a human queue with the cited clauses shown.
- Keep an immutable log of the retrieval set used for each decision.
Testing, versioning and change management
Build a replay set from historical cases with known correct outcomes and run it after every policy update, prompt change or chunking tweak. Track decision accuracy, citation validity, exception rate and human override rate; the override rate is the clearest signal that retrieval or prompts have drifted.
Treat the policy corpus as a product with owners: documents get effective dates, review cycles and deprecation, and the index follows. The free plan with plugsky-micro and plugsky-lite is enough to build and test the pipeline, and the 14-day full-access trial covers stronger models for complex rule sets; the live pricing page lists plans.
Honest comparison
| Concern | RAG workflow on Plugsky | Hard-coded rules engine | Prompt-only automation |
|---|---|---|---|
| Policy changes | Re-index documents | Code release per change | Prompt edits |
| Traceability | Cited rule and version per decision | Rule ids in code | None |
| Edge cases | Retrieved clauses plus escalation | Explicit exception code | Inconsistent answers |
| Coverage | Any documented process | Only encoded logic | Only memorised rules |
| Model choice | 30+ models behind one endpoint | Not model-driven | One model |
Frequently asked questions
Why use RAG instead of rules in code?
Rules in code are precise but slow to change and easy to duplicate. RAG keeps the authoritative policy in documents, retrieves the applicable clauses at decision time, and cites them, so updates are a document review rather than a code release.
How do I prevent stale policies from leaking?
Store effective dates and versions with every vector, filter retrieval by process, jurisdiction and date, and reject decisions that cite superseded versions.
What output should the model return?
A structured decision object with the action, supporting rule id and version, exceptions and confidence. Validate it against your rule engine before executing anything.
How do I test automated decisions?
Replay historical cases with known outcomes and measure decision accuracy, citation validity, exception rate and human overrides after every change.
Which models should make decisions?
Route routine classification and routing to plugsky-micro or plugsky-lite, and use stronger tiers for complex or high-value cases. All 30+ models are available behind one OpenAI-compatible endpoint.
Can the workflow pause for approval?
Yes. Treat approval as a deterministic step in your orchestrator: the model proposes, your code checks, and a human approves anything above the risk threshold.
Can I start for free?
Yes. The free plan includes plugsky-micro and plugsky-lite with no card, and a 14-day full-access trial is available for stronger models.
Where do documents live?
In your storage. Plugsky provides the embedding and generation calls; parsing, versioning, index and audit data stay in your systems.