# Pradra Studio — ML and LLM in one place

> Pradra Studio (pradra.com) brings ML and LLM together in one place. AI Solution Lifecycle Platform. Build, deploy, and monitor AI capabilities around business solutions — datasets, training, evaluation, deployment, and monitoring in one governed, versioned platform. Bahasa Indonesia: Pradra Studio menyatukan ML dan LLM dalam satu tempat — satu platform AI untuk membangun, menerapkan, dan memantau model machine learning dan large language model (LLM).

- [Home](https://pradra.com/): product overview
- [Documentation](https://pradra.com/docs): full docs portal

## Docs

- [What is Pradra Studio](https://pradra.com/docs/01-what-is-pradra): Pradra Studio is a platform for building, deploying, and operating AI capabilities as part of a real business solution — not as isolated science experiments.
- [How the platform works](https://pradra.com/docs/02-how-the-platform-works): Pradra Studio takes an AI capability through one continuous life: define the problem, prepare the data, train and evaluate, deploy, and keep watching it in production. This page is the map; every stage links to its own section.
- [Quickstart](https://pradra.com/docs/03-quickstart): This guide walks a business problem all the way to a live, callable prediction — entirely inside the Studio UI. No SDK, no code, until the very last step where your application calls the finished endpoint.
- [Solutions](https://pradra.com/docs/10-solutions): An AI Solution represents a business problem inside the platform. It is the container that groups related capabilities so they can share data, governance, and operations — and it is where every piece of work in Pradra Studio starts.
- [Capabilities](https://pradra.com/docs/11-capabilities): An AI Capability is one reusable unit of intelligence inside a solution — one specific prediction or generation, with a clear contract. An Asset Intelligence solution might contain three: Predictive Maintenance, Remaining Useful Life, and Failure Prediction.
- [Acceptance criteria](https://pradra.com/docs/12-acceptance-criteria): This is the single most important governance control in Pradra Studio: no model ships without passing the gate, and no path around the gate exists.
- [Datasets](https://pradra.com/docs/20-datasets): A capability is only as good as the data behind it. Pradra Studio treats data as a first-class, versioned asset — never a loose file on someone's laptop.
- [Feature sets](https://pradra.com/docs/21-feature-sets): Raw data is rarely in the shape a model wants. A feature set is a versioned, model-ready view derived from a dataset version: the specific columns the model will learn from, any derived values, and — for supervised capabilities — the target you are predicting.
- [Connectors](https://pradra.com/docs/22-connectors): A connector pulls data from an external source into a dataset, so the data your models learn from stays fresh without anyone uploading files by hand.
- [Training](https://pradra.com/docs/30-training): This is where a capability learns. Pradra Studio runs the training for you and keeps a complete, tamper-proof record of how each model came to be.
- [Experiments](https://pradra.com/docs/31-experiments): Every training run is recorded as an experiment: an immutable record of the parameters used, the metrics achieved, the logs produced, the artifacts created, and the exact dataset and feature set versions it consumed. An experiment produces one candidate model.
- [Models & evaluation](https://pradra.com/docs/32-models-and-evaluation): A model is a trained, versioned artifact that backs exactly one capability at a time. This page covers how a candidate earns trust — evaluation — and how a trusted model reaches, and leaves, production.
- [Deployments](https://pradra.com/docs/40-deployments): A model only creates value once your applications can call it. A deployment is a running instance of a capability's production model, reachable as a stable, contract-checked endpoint. You create it once; the platform keeps it running and lets you update or stop it.
- [Real-time predictions](https://pradra.com/docs/41-realtime-predictions): Your application sends inputs to a deployed capability's endpoint and gets a result back immediately. The request is validated against the input contract; the response is shaped by the output contract; every call is logged to prediction history.
- [Batch predictions](https://pradra.com/docs/42-batch-predictions): When you need to score many records at once — tonight's whole customer base, this month's sensor readings — submit a batch prediction job instead of calling the endpoint row by row. The platform scores the rows asynchronously and gives you a downloadable result file.
- [Monitoring](https://pradra.com/docs/50-monitoring): Shipping a model is the start, not the finish. Once a capability is deployed, Pradra Studio watches it on several fronts — so the first person to know about a problem is you, not your users.
- [Drift & retraining](https://pradra.com/docs/51-drift-and-retraining): A model trained on last year's data can quietly become less accurate as the world changes. Drift detection notices the change; retraining responds to it — through the exact same quality gate as the original model.
- [Budgets & costs](https://pradra.com/docs/52-budgets-and-costs): Generative AI calls cost real money per token. Pradra Studio meters that spend on every call and lets you set monthly budgets that stop the spending — hard — when the limit is reached. Classic ML predictions carry no per-call provider cost and are not metered.
- [AI Studio](https://pradra.com/docs/60-ai-studio): Extraction deserves a highlight: its output is checked against the capability's output contract. A field the model failed to find comes back as an explicit null — never as an invented value passed off as data.
- [Prompts](https://pradra.com/docs/61-prompts): For a generative capability, the prompt is the specification: it tells the model what to do with each request. Pradra Studio treats prompts the way it treats models — versioned, evaluated, and gated — because changing a prompt changes production behavior just as surely as swapping a model.
- [Generative evaluation](https://pradra.com/docs/62-generative-evaluation): "It looked good when I tried it" is not a quality bar. Pradra Studio evaluates generative capabilities against a golden set — examples you curate, with known-good answers — and turns the results into named, numeric metrics that the same acceptance criteria machinery can gate.
- [Knowledge sources](https://pradra.com/docs/63-knowledge-sources): A language model only knows what it was trained on. A knowledge source lets a generative capability answer from your documents — policies, product manuals, past cases — by retrieving the most relevant passages and giving them to the model as context. The pattern is known as retrieval-augmented generation (RAG).
- [Fine-tuning](https://pradra.com/docs/64-fine-tuning): When prompting and retrieval aren't enough — the model needs your domain's vocabulary, your format, your judgment — fine-tuning trains the model itself on your examples. Pradra Studio runs it as a governed job with the same discipline as everything else: consent, budgets, and the same quality gate before anything serves.
- [Workflows](https://pradra.com/docs/70-workflows): A single capability answers a single question. A workflow chains capabilities and decisions into a business process: score the claim, and if the risk is high, extract the details and park it for a human to approve. Workflows are built and run inside Pradra Studio, with every run recorded step by step.
- [Agents](https://pradra.com/docs/71-agents): An agent is a capability that pursues a goal instead of answering a single question: given "resolve this billing dispute", it plans, calls tools, observes the results, and works toward an answer — deciding its own steps as it goes. Pradra Studio runs agents inside a strict harness: budgeted, fully traced, and gated like every other capability.
- [Agent tools & approvals](https://pradra.com/docs/72-agent-tools-and-approvals): An agent is only as dangerous as what it can touch. In Pradra Studio, everything an agent can touch is an agent tool — registered by an administrator, granted per capability, and classified by how much damage it could do. The riskiest class always requires a human signature.
- [Pradra as your product's AI backend](https://pradra.com/docs/73-developer-platform): Most of this portal describes building AI inside Pradra Studio. This section describes the other direction: your product keeps its own users, its own database and its own business logic, and calls Pradra for the AI parts — while letting Pradra call back into your code when the model needs something only your system knows.
- [Your own tools](https://pradra.com/docs/74-your-own-tools): A tool is a function in your codebase that an agent may call. Not a rewritten service, not a copy of your data — usually a three-line wrapper around something you already have.
- [Conversations](https://pradra.com/docs/75-conversations): A prediction is stateless: it answers what you asked and forgets. A session is the conversation primitive — it replays the recent transcript into the prompt so "and what about the other one?" means something, and it records every turn as it is served.
- [Streaming](https://pradra.com/docs/76-streaming): A long answer that appears all at once after eight seconds feels broken. The same answer appearing word by word feels immediate, even though it finishes at exactly the same moment. Streaming delivers a generative answer as it is produced, and an agent run as it progresses.
- [Organizations & workspaces](https://pradra.com/docs/80-organizations-and-workspaces): Pradra Studio is built for teams. Two containers keep work organized, isolated, and safe.
- [Users & roles](https://pradra.com/docs/81-users-and-roles): Access in Pradra Studio is controlled by roles: a member's role determines what they can see and do in an organization or workspace — from read-only viewing through to full administration. The platform enforces roles on every action, in the UI and the API alike.
- [API tokens](https://pradra.com/docs/82-api-tokens): Your application shouldn't sign in with a person's password. An API token is a long-lived credential made for machines: create one, put it in your service's configuration, and call deployed capabilities with it.
- [Secrets](https://pradra.com/docs/83-secrets): Connectors need database passwords; generative capabilities need provider API keys. Secrets is the organization's central, encrypted store for those credentials — so one database password lives in one place, is rotated in one place, and is never scattered across a dozen connector forms.
- [Plugins](https://pradra.com/docs/84-plugins): One growing consumer: a plugin can back an agent tool, giving agents a governed way to call your custom logic — still subject to grants, side-effect levels, and the approval queue.
- [Subscription & plans](https://pradra.com/docs/85-subscription-and-plans): Every organization is on a subscription plan, and the plan sets entitlements: how many solutions, capabilities per solution, workspaces, and members the organization may create. Plans are about how much you can build; the money-per-token side of generative AI is a separate mechanism — see Budgets & costs.
- [Governance & audit](https://pradra.com/docs/86-governance-and-audit): An AI prediction can drive a real decision — a loan, a repair, an alert. That only works if you can trust the system that produced it. Pradra Studio builds that trust into the platform rather than leaving it to discipline.
- [Self-hosting](https://pradra.com/docs/87-self-hosting): You can run the entire Pradra Studio platform on your own server instead of using the hosted service — for data residency, network isolation, or latency. Self-hosting is available to any organization on a paid plan (see Subscription & plans), and it is tied to your subscription by a license key.
- [Glossary](https://pradra.com/docs/90-glossary): The core vocabulary of Pradra Studio, in plain terms.
- [FAQ](https://pradra.com/docs/91-faq): Short answers to common questions. Follow the links for detail.
- [SDK overview](https://pradra.com/docs/100-sdk-overview): This section is a step-by-step track for putting Pradra inside your own application. Work through it in order and you will have: a first prediction, a tool of your own that an agent can call, a conversation that remembers, a streaming answer, and documents your model can cite.
- [Quickstart](https://pradra.com/docs/101-sdk-quickstart): Ten minutes from nothing to a prediction served by your own code path. Each step states what you should see before moving on.
- [Serving your own tools](https://pradra.com/docs/102-sdk-tools): This is the step that turns Pradra from an API you call into the AI backend of your product. You will expose one function from your codebase, let an agent call it, and read the trace of what happened.
- [Conversations & streaming](https://pradra.com/docs/103-sdk-conversations-streaming): Two features that are usually wanted together: an assistant that remembers the last question, and an answer that appears as it is written instead of after a silent pause.
- [Documents & retrieval](https://pradra.com/docs/104-sdk-knowledge): Give a capability your own documents to answer from — policies, manuals, past cases — set up entirely from code, so it runs on every deploy instead of being clicked once and forgotten.
- [Webhook tools](https://pradra.com/docs/105-sdk-webhooks): The same tool definitions as a worker, reached the other way: Pradra calls an HTTPS endpoint you expose. Your handler code does not change — only how the call arrives.
- [API surface](https://pradra.com/docs/106-sdk-reference): Every export of @pradra/sdk in one page. For the underlying HTTP endpoints, see the API reference.

## API & SDKs

- [Getting started / SDKs](https://pradra.com/docs/sdk)
- [API reference](https://pradra.com/docs/api)