> ## Documentation Index
> Fetch the complete documentation index at: https://koreai-agentplatform-dev.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# General settings
General settings govern project membership, authentication keys, model availability, runtime behavior, data lifecycle, compile-time variables, and localization assets.
## Members
The **Members** page controls who reaches your project and what they can do inside it.
**Navigation**: **Project** -> **Settings** -> **Members**
The page lists every project member with their name, email, role, and join date. Select **Add Member** to grant access to an existing workspace member, then assign a role. Removing a member revokes their access at once rather than at their next sign-in.
### Project roles
A role bundles the permissions a member holds everywhere in the project. Assign the narrowest role that still lets someone do their job, since the roles differ less in what they can see than in what they can change.
| Role | Capabilities |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Admin** | Manages members, settings, agents, and deployments. Assign it to the people who own the project's configuration, since this role can change anything the other three roles depend on. |
| **Developer** | Creates and modifies agents, tools, workflows, imports, and project resources. This is the working role for anyone building the agent. |
| **Tester** | Reads project resources, creates and reads sessions, runs simulations, and views analytics. It lets someone exercise the agent thoroughly without risking the configuration they're testing. |
| **Viewer** | Reads project resources, sessions, and analytics. Use it for stakeholders who need reporting rather than the build. |
***
## API keys
The **API Keys** page issues and revokes the credentials that carry programmatic access to the project runtime.
**Navigation**: **Project** -> **Settings** -> **API Keys**
| Tab | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SDK Keys** | Credentials that client-side SDKs and web widgets present to the project runtime. These travel to browsers and devices, so treat them as public and scope them accordingly. |
| **Platform Keys** | Credentials for server-to-server integrations and administrative API access. These stay on infrastructure you control and carry broader authority than SDK keys. |
Select **Create Key**, name it descriptively, and optionally set an expiration date. Each entry shows the key name, a masked prefix, and the date something last used it. The last-used date is the field that matters during an audit, because it identifies keys you can revoke without breaking anything.
Deleting a key revokes it permanently and immediately. Anything still presenting that key stops working, so confirm the last-used date before you delete.
Issue a separate key for each environment and rotate them on a schedule. A single shared key means one compromise forces you to rotate everywhere at once.
***
## Models
The **Models** page decides which models this project can use and which model serves each platform feature. It carries two tabs: **Model Configs** sets the pool, and **Feature config** routes work within that pool.
**Navigation**: **Project** -> **Settings** -> **Models**
### Model Configs
This tab defines the project's selected models. Selection is an allowlist rather than a preference. Only selected models appear in the project's model pickers and feature routing, so nothing downstream can reach a model you haven't selected here.
Two counters at the top compare the models you selected with the models your workspace makes eligible. The gap between them tells you how much of the workspace catalog this project deliberately excludes.
Each selected model shows its provider, whether the workspace shares it, and a readiness status. A model reports ready once its connection resolves, and a model that stops being ready takes every feature bound to it down with it.
**Project default.** The default applies to this project only and doesn't change the workspace. Features that don't carry a tier binding or an override resolve to it, which makes it the fallback for the widest set of operations on the page.
Select **Add models** to bring eligible models into the project, and **Save selection** to apply the change.
**Model access rollout.** A banner appears while the project still holds references to models outside the selected set. Until you resolve those references, the project can't move to enforcing selection only. Treat the count in the banner as work remaining before enforcement, not as an error in the current configuration.
### Feature config
This tab routes individual platform features to models. It exists because a project runs many different operations, and matching each to a model sized for it costs less than sending everything to one capable model.
**Per-operation routing** switches the page between two ways of working. With tier routing, each feature runs on the model bound to its tier, so changing one tier moves every feature on it. Per-operation routing lets features diverge from their tier. Start with tiers and reach for per-operation routing only where a specific feature justifies it, since divergence you set once is easy to forget later.
#### Tier bindings
Four tiers draw from the project's selected models. The tier names describe the trade the model makes rather than a fixed capability level, so rebind them as your model pool changes.
| Tier | When to bind a model here |
| ------------ | --------------------------------------------------------------------------------------------------------- |
| **Fast** | High-volume mechanical work where per-call cost dominates and a weaker answer costs little. |
| **Balanced** | The everyday workload, where neither cost nor judgment is the binding constraint. |
| **Powerful** | Work where judgment quality justifies the slowest and most expensive option. |
| **Voice** | Realtime speech-to-speech conversation, which needs a model built for it rather than a strong text model. |
A tier with no model bound leaves every feature on it unresolved. The page warns you before release when a binding is missing or a connection needs repair, because an unresolved feature fails at runtime rather than falling back silently.
#### Feature table
Features group by the part of the platform they serve: authoring and diagnosis, live conversation runtime, knowledge processing, conversation insights, evaluation, and ingestion pipelines. Each row carries the feature's stable key, which is the identifier to use when you discuss routing with support rather than the display name.
| Column | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Tier or override** | Sets whether the feature follows its default tier or binds directly to a model. Overrides draw only from the project's selected bindings, so you can't route a feature to a model the project hasn't selected. |
| **Resolves to** | Shows the model the feature actually reaches after tier bindings and overrides apply. Read this column rather than the tier column when you're diagnosing behavior, because it reflects the outcome rather than the intent. |
| **From** | Shows where the resolution came from, which distinguishes a deliberate binding from a fallback to the project default. |
| **Status** | Reports whether the feature can run. Ready means it resolves to a working model. Not configured means the resolution path ends without a model. Unavailable means the platform doesn't yet offer the feature for execution, so no binding will make it run. |
Select **Why this model?** on a row to see the resolution path that produced the result. Select **Save feature config** to apply changes.
***
## Runtime configuration
The **Runtime Configuration** page holds the behavioral controls that govern how the project's agents read input, handle multiple requests in one turn, fill in unstated values, occupy callers during waits, expose their own activity, protect personal data, and bound their own tool use.
**Navigation**: **Project** -> **Settings** -> **Runtime Config**
Changes here apply to every agent deployment in the project, so treat this page as project-wide policy rather than per-agent tuning. Each group appears as a collapsible card. Select **Save** to apply changes, or **Reset to defaults** to return every setting on the page to its factory value.
### Extraction pipeline
This section decides how the runtime turns a raw user message into structured field values.
| Field | Description |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Extraction Strategy** | Chooses which extraction stages run and in what order. Pattern matching costs nothing and handles predictable formats; model-backed extraction catches what patterns miss but adds latency and cost to every turn that needs it. Change it when your fields sit at one extreme or the other, either structured enough that the model call is waste, or conversational enough that patterns alone leave fields unfilled. Language detection and resolution run under every strategy. |
### Multi-intent recognition
This section handles messages that ask for more than one thing at once. Without it, the runtime acts on the first request it recognizes and the rest of the message goes unanswered.
| Field | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable Multi-Intent** | Turns on detection of several intents in one message. Leave it off for narrow transactional flows, where a second detected intent is more often a misread than a real request. |
| **Strategy** | Sets the order in which the runtime works through detected intents. The choice decides whether the user gets a fast answer to their first request or waits while the agent works the whole message. |
| **Unknown Relationship Strategy** | Chooses the fallback for same-turn supervisor routing when relationship data isn't available. Relationship data normally decides ordering, so without it the runtime needs a standing instruction rather than a judgment. |
| **Max Intents** | Caps how many intents the runtime acts on in one turn. Each additional intent comes from a less certain reading of the message, so raising this raises the chance of acting on something the user didn't ask for. |
| **Confidence Threshold** | Sets the minimum classifier confidence needed to act on a detected intent. Raise it when the agent answers requests the user didn't make, and lower it when the agent ignores genuine second requests. |
| **Queue Max Age (ms)** | Sets how long a queued intent stays eligible for handling. It stops the agent from returning to a request the user has since abandoned or resolved another way. |
**Multi-intent strategies**
| Value | Behavior |
| --------------- | ----------------------------------------------------------------------------------------------------------------- |
| `primary_queue` | Handles the first intent immediately and queues the rest, addressing them in sequence once the primary completes. |
| `sequential` | Addresses intents one at a time in detection order, finishing each before starting the next. |
| `parallel` | Dispatches all intents at once and resolves them concurrently. |
| `disambiguate` | Asks the user which request to handle first. |
| `auto` | Lets the runtime choose based on the intent relationship and conversation context. |
**Unknown relationship strategies**
| Value | Behavior |
| -------------- | ------------------------------------------------------- |
| `sequential` | Addresses the intents one at a time in detection order. |
| `parallel` | Handles the intents concurrently. |
| `disambiguate` | Asks the user which intent to prioritize. |
[Learn More](/agent-platform/abl-reference/nlu#multi-intent-handling-multi_intent)
### Field inference
This section lets the runtime infer values the user hasn't stated, which shortens conversations at the cost of occasionally guessing wrong.
| Field | Description |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Confidence Threshold** | Sets the minimum confidence needed to accept an inferred value. Inference trades accuracy for fewer questions, and this field is where you set that trade. |
| **Require User Confirmation** | Presents inferred values to the user before the agent applies them. Keep it on wherever a wrong inference costs money or changes a record, since confirmation is far cheaper than reversal. |
| **Model Tier** | Selects the tier that serves inference calls. Inference runs often and on small decisions, so this choice affects per-turn latency more than most model settings. |
| **Max Fields Per Pass** | Caps how many fields one inference call attempts. Fewer fields per pass means more calls, each of them more reliable. |
### Currency conversion
This section decides where exchange rates come from when an agent quotes or converts an amount. Agents that never handle money can leave it alone.
| Field | Description |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Currency Mode** | Selects whether the runtime converts currency using rates held in the platform or rates fetched live. Held rates keep results reproducible across a conversation and across environments. Live rates keep them current. Choose on whether your users compare quotes over time. |
### Reasoning pipeline
The reasoning pipeline runs a lightweight classifier ahead of each reasoning turn so the runtime can route programmatically and narrow the tool set before the main model call.
**Experimental feature. Read before enabling.**
* The pipeline needs a configured `tool_selection` model. Without one it skips silently rather than reporting an error.
* It adds one model call ahead of each reasoning turn.
* After three consecutive pipeline model failures, a circuit breaker bypasses the pipeline temporarily so the failure doesn't add latency to every turn.
| Field | Description |
| --------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable Pipeline** | Runs the classifier ahead of reasoning to enable short-circuit routing and tool filtering. Everything else in this section depends on it. |
| **Execution Mode** | Decides whether the classifier and tool filter run together or one after the other. Running them together costs less time. Running them in sequence lets the classifier result decide whether the tool filter is needed at all. |
| **Pipeline Model** | Selects the model that performs intent classification. The pipeline runs on every turn, so this choice sets a recurring latency and cost floor for the whole project. |
| **Short Circuit** | Lets the runtime skip the reasoning loop when classifier confidence runs high. Most of the pipeline's latency saving comes from here, and so does most of its risk, because no reasoning step follows to catch a misclassification. |
| **Short Circuit Threshold** | Sets the confidence a classification needs before the runtime routes programmatically. Treat it as the safety margin on short-circuiting. |
| **Tool Filter** | Narrows the tool set sent to the model based on classifier analysis. Large catalogs degrade tool selection accuracy, so filtering helps most in projects that expose many tools. |
| **Max Tools** | Caps how many tools reach the reasoning loop. |
| **Keyword Veto** | Overrides classifier routing when specified keywords appear. Use it for terms where you'd rather not depend on a classifier judgment at all. |
| **Veto Keywords** | Holds the comma-separated keywords that trigger the veto. |
| **Intent Bridge** | Publishes classifier output into session state so WHEN conditions and multi-intent dispatch can read it. Without it, the classifier's work stays inside the pipeline and your authored logic can't act on it. |
| **Programmatic Threshold** | Sets the confidence needed for Tier 1 actions, where the runtime declines or routes without a model call. |
| **Guided Threshold** | Sets the confidence needed for Tier 2 behavior, where the runtime keeps the reasoning loop but shapes it by hiding tools and adding routing hints. Set it below the programmatic threshold, since guided actions leave the model room to recover and programmatic ones don't. |
| **Out-of-Scope Decline** | Declines out-of-scope queries programmatically. It removes a model call from every off-topic turn, which pays off most on public channels where off-topic volume runs high. |
| **Multi-Intent Signal** | Injects multi-intent hints into the reasoning turn when the classifier detects more than one intent. |
### Tool call policy
This section bounds the deterministic CALL actions that tool lifecycle hooks invoke. The limits apply only to those hook-driven calls. Side-effecting target tools still run through the normal confirmation flow, so this section doesn't weaken confirmation.
| Field | Description |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Boundary CALLs Enabled** | Allows tool lifecycle hooks to invoke another tool deterministically. Turning it off removes an entire class of chained behavior, so confirm nothing depends on it before you do. |
| **Max CALL Depth** | Caps nested boundary CALL depth in a single turn. The runtime clamps depth to five whatever you save, so use this field to set a stricter limit than the platform's own, not a looser one. |
| **Max CALLs Per Turn** | Caps boundary CALL fan-out across one runtime turn. The runtime clamps this to twenty whatever you save. Fan-out limits matter more than depth limits, because a single wide hook can issue far more calls than a deep chain. |
### Streaming safety
This section decides what the runtime does when a safety check fires on a response it has already begun sending. It's the one safety control where timing matters as much as outcome.
| Field | Description |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Safety Mode** | Decides how the runtime handles a final-output safety intervention on a response that's already streaming. The difficulty is timing: by the time an intervention fires, part of the response may have reached the user. Projects created before this setting existed stay on legacy passthrough until you change it here, so review the value explicitly rather than assuming the project runs current behavior. |
### Output item analytics
Runtime responses often carry repeated structures such as a list of results. Analytics rows don't store raw response JSON, so you have to declare anything you want to query later here first. A mapping tells the runtime which array to capture and which scalar fields inside it to record.
Mappings are project-scoped and additive, and they only take effect for responses produced after you add them. Declare a dimension before you need it, because you can't recover a field retrospectively.
| Field | Description |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Mapping key** | Names the analytics category this item family reports under. Queries group on this key, so keep it stable once collection starts. Renaming it splits your history into two unrelated series. |
| **Item array path** | Absolute path to the repeated array inside the response. |
| **Item key path** | Optional relative path that gives each item a stable identity across responses. Set it when you need to follow the same item over time rather than count occurrences. |
| **Max items** | Caps the rows captured per response for this mapping. It bounds what an unusually large response costs you in analytics writes. |
| **Description** | Author-facing note explaining what the repeated item represents. It's the only place a later reader learns why the mapping exists. |
| **Item dimensions** | Declares the scalar fields inside each item that the runtime records, each with a name, a path, and a type. The runtime doesn't store fields you don't declare, and no query can recover them later. |
### While the caller waits
This group configures what a caller experiences while the agent thinks or works: spoken filler phrases, background hold audio, or both together. The settings interact, so read the whole group before you change any one part.
#### Filler settings
Fillers are transient status messages the runtime emits while work is in progress. They exist because silence during a long turn reads as a failure, particularly on voice.
| Field | Description |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Fillers Enabled** | Master switch for the filler system. With it off, nothing else in this section emits anything. |
| **Chat Fillers** | Shows status update messages in chat clients. |
| **Voice Fillers** | Speaks status updates on voice channels. Voice needs fillers more than chat does, because a chat user can see that something is in progress and a caller can't. |
| **Chat Delay** | Sets the wait before a static chat filler appears. Set it above the time a normal turn takes, so fillers mark genuinely slow turns rather than interrupting fast ones. |
| **Voice Delay** | Sets the wait before a static voice filler is spoken. Callers tolerate silence for less time than chat users, so this typically sits below the chat delay. |
| **Cooldown** | Sets the minimum interval between static fillers. It stops a long turn from producing a stream of status messages that says nothing new. |
| **Max Per Turn** | Caps fillers emitted during one turn. |
| **Status Tags** | Uses the status tags the response model emits as fillers, which lets the model say what it's actually doing instead of emitting a generic wait message. |
| **Generated Fillers** | Uses a lightweight model call to produce contextual fillers. This makes the wait message specific to the conversation at the cost of a call on turns that are already slow. |
| **Include emitted filler in agent context** | Lets later same-turn voice reasoning account for a contextual filler the runtime already emitted. It doesn't add the filler to conversation history, so this changes what the agent knows within the turn rather than what the transcript records. |
| **Filler Model** | Selects the model that generates contextual fillers. |
| **Output Tokens** | Caps the response length for built-in contextual filler generation. Fillers should be short, and a low cap enforces that more reliably than the prompt does. |
| **Prompt Override Tokens** | Caps the response length when a filler prompt override is in use. Overrides usually ask for more than the built-in prompt does, which is why they carry a separate limit. |
| **Conversation History** | Sets how many recent messages the filler prompt includes. More history makes fillers more specific and each generation call more expensive. |
| **Previous Fillers** | Sets how many already-emitted fillers the prompt includes. Its purpose is avoiding repetition within a turn, so it matters most when the max per turn runs high. |
| **Filler Prompt** | Selects a prompt-library version that replaces the built-in filler prompt. Select **Clone built-in** to start from the platform's prompt rather than an empty one. The prompt accepts placeholders for the user message, the conversation history, and previously emitted fillers. |
#### Background audio
Background audio is looped hold music the voice gateway plays during compute waits. It covers silence without the agent having to say anything.
| Field | Description |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Background Audio Enabled** | Plays uploaded hold audio while the agent works. |
| **Audio File** | Holds the WAV or MP3 clip the gateway fetches. |
| **Start Delay** | Sets the silence before the audio begins. This is the field that most often stops background audio from working: a spoken filler interrupts the audio, so a filler that arrives first prevents the audio from starting at all. Either lower this delay or raise the spoken filler delay so one has room to begin before the other. |
| **When To Play** | Chooses the moments the gateway plays audio. Select at least one, or the audio never plays despite being enabled. Playing between sentences depends on the gateway, since some text-to-speech vendors send audio continuously and leave no gap to play into. |
#### Greeting audio
Greeting clips play as soon as a call connects, ahead of the agent's first turn. They cover the gap between answer and first response, which is the moment a caller is most likely to think the line is dead.
#### Activity updates
This section sets the visibility policy for what the runtime reveals about its own work. The policy is a ceiling rather than a guarantee, because channels apply only what they support.
The exposure settings deserve particular care. Tool, workflow, and agent names describe your internal architecture, and a name that helps an internal user diagnose a problem tells an external user how your system is built.
| Field | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Fillers** | Exposes the status messages generated while runtime work is in progress. |
| **Action Progress** | Exposes progress for memory, knowledge, workflow, tool start, and retry events. It's the safest form of progress reporting, since it says work is happening without saying what. |
| **Tool Preview** | Controls whether tool input and output previews are hidden or redacted. Previews can carry data the user supplied moments ago, so redaction and hiding aren't equivalent choices. |
| **Decisions** | Exposes safe decision labels as action progress. |
| **Thought Summaries** | Exposes model and step thinking summaries when the runtime emits them. Summaries explain reasoning that the agent may not stand behind in its final answer, so exposing them can raise questions the response then contradicts. |
| **System Notices** | Exposes authentication, approval, and waiting-for-input notices. These usually need to stay visible, because they tell the user that the agent is waiting on them rather than working. |
| **Debug Details** | Exposes redacted debug activity meant for internal review. |
| **Expose Tool Names** | Shows tool names in activity messages. |
| **Expose Workflow Names** | Shows workflow and step names. |
| **Expose Agent Names** | Shows agent names where the channel supports it. In multi-agent projects this reveals that a handoff occurred, which reads as competence internally and as confusion externally. |
| **Maximum Text** | Caps visible characters per activity update. |
### Voice no-input defaults
This section sets what happens when a voice caller goes silent. Silence is ambiguous, since it can mean the caller is thinking, has walked away, or didn't hear the prompt, and these settings decide how long the agent waits before treating it as a problem.
| Field | Description |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enabled** | Turns on no-input handling for voice sessions. |
| **Mode** | Chooses between authored prompts and contextual generated prompts. Generated prompts fall back to the authored and default prompts, so choosing them adds a behavior rather than replacing one. |
| **Timeout** | Sets the silence that must pass before a no-input prompt fires. Too short interrupts a caller who's reading something out, and too long lets a caller believe the call has dropped. |
| **Max Retries** | Sets how many no-input prompts the agent issues before it takes the terminal action. |
| **Relaxed Interval** | Sets the extended timeout interval used in dynamic mode. |
| **Play Order** | Sets the order in which no-input messages play. |
| **Play Style** | Sets how messages repeat across retries. Repeating the same prompt signals a system that isn't listening, so this choice affects how a stuck caller reads the failure. |
### Voice speech recognition
These are project-wide defaults. A channel connection can override them, so check the connection before you conclude the project value is what's running.
| Field | Description |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Default minimum STT confidence** | Rejects transcripts below this confidence and treats them as no-input. Confidence scores are provider-relative rather than absolute, so a value that works for one speech provider won't carry over to another. Calibrate in staging before you set it in production, and set it to zero to disable the gate entirely. |
### PII redaction
This section controls how the runtime handles personally identifiable information in conversations. Baseline credential and secret scrubbing protects logs and read APIs whether or not PII protection is on, so the settings here extend that protection rather than establishing it.
| Field | Description |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enable PII Protection** | Detects and redacts PII in conversations. It's the switch the rest of this section depends on. |
| **Redact Input** | Redacts PII in user messages before they reach the model. Redaction is context-aware and exempts fields the agent is actively gathering, so turning it on doesn't break a flow that legitimately asks for a phone number. |
| **Redact Output** | Redacts PII in agent responses before delivery. Its purpose is stopping the agent from echoing back PII the user already provided, which is a common way collected data reaches a transcript. |
| **Classify explicit DTMF using project PII patterns** | Matches a completed keypad entry to the project's enabled PII patterns, so a recognized value carries a type and a validation status while anything else stays a generic token. Raw digits never reach the model either way, so this setting changes how an entry is labelled rather than whether it's protected. |
| **Detection methods allowed** | Sets the ceiling on which detection engines the project's patterns may use. Each pattern still selects its own method on the PII Protection page, so this field decides what's available to them rather than what they do. |
### Lookup tables
Lookup tables are the reference data the runtime uses to validate field values and perform fuzzy matching during extraction.
Project lookup tables defined here are the canonical source for gather validation and fuzzy matching. Agent-local `LOOKUP_TABLES` remain available only as an experimental compatibility lane, so build new work on project tables.
| Field | Description |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Table Name** | Names the table for reference from field validation. |
| **Source** | Selects where the table's values come from, which decides whether you maintain them here or elsewhere. |
| **Values** | Holds the comma-separated values for an inline table. |
| **Case Sensitive** | Requires an exact case match. Leave it off for anything a user types, since typed input rarely matches your stored casing. |
| **Fuzzy Match** | Accepts near matches. It rescues misspellings and transcription errors at the cost of occasionally accepting a value the user didn't mean, so it suits voice input more than typed input. |
***
## Data retention
The **Data Retention** page sets how long evaluation and scoring data stays available to this project.
**Navigation**: **Project** -> **Settings** -> **Data Retention**
Retention is a deletion policy rather than a storage preference. Once a window passes, the data is gone and no longer available for trend analysis, so set these values around the longest comparison you expect to run rather than the storage you expect to use.
| Category | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Eval conversations** | Holds evaluation conversation transcripts. Transcripts are what let you re-read a failed evaluation rather than only seeing that it failed. |
| **Eval scores** | Holds evaluation score records. Scores outlive their usefulness more slowly than transcripts, since trend comparison needs the numbers rather than the conversations. |
| **Production scores** | Holds production scoring data, which is the basis for the quality trends in Insights. |
| **Synthetic eval runs** | Holds synthetic evaluation run data. These runs are reproducible on demand, which is why they carry the shortest window. |
The **Retention Windows** section below the summary sets the time-to-live in days for each category. Select **Save** to apply changes or **Reset** to restore defaults.
***
## Config variables
The **Config Variables** page defines key-value pairs that the platform resolves at compile time through `{{config.KEY}}` syntax.
**Navigation**: **Project** -> **Settings** -> **Config Variables**
Use config variables for values that several agents share and that change between environments, such as endpoints, feature flags, and persona-specific content. The alternative is repeating the value in each agent, which turns an endpoint change into an audit.
### Add a variable
Each variable is one key the platform substitutes wherever your agents reference it. The fields below define the key, its value, and the context a later reader needs.
Select **Add Variable**, then complete the fields.
| Field | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Key** | Uniquely identifies the variable and forms the reference used in code. Changing a key later breaks every reference to it, so settle naming before the value spreads. |
| **Value** | Holds what the platform substitutes at compile time. You can override it per deployment environment, which is the mechanism that lets one project target different endpoints. |
| **Namespaces** | Groups related variables so a large set stays navigable. |
| **Description** | Explains what the variable is for. It's the only context a later reader gets when deciding whether a variable is safe to change. |
Config variables resolve at compile time rather than at runtime, so a changed value reaches your agents only after recompilation.
***
## Localization
The **Localization** page manages locale JSON assets in Studio and syncs them through the project's Git integration.
**Navigation**: **Project** -> **Settings** -> **Localization**
The platform stores locale assets as project-level JSON files and exports them to Git under the same path contract that project import and export use. Keeping paths in the canonical shape is what lets assets round-trip cleanly, so a path you improvise here becomes a merge problem later.
Counters at the top report the assets, locales, and shared assets the project holds. A status indicator reports when Git isn't connected, with a link to **Open Git Settings**. Until you connect Git, assets stay in project storage and don't reach version control, which means no diffs and no review.
Search by locale, file path, or description, and narrow the list by locale or by scope when the asset count grows past browsing.
### Create a localization asset
An asset is one locale JSON file holding translated strings, either shared across the project or scoped to a single agent. Creating one here puts it under the same path contract Git and project export use.
Select **New Asset** to open the editor, then complete the fields and select **Create**. Saving writes the asset into project storage and keeps the Git export path aligned.
| Field | Description |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Relative Path** | Sets the locale file path in the canonical locale and asset shape. This path determines where the asset lands in Git and whether import and export find it again. |
| **Description** | Gives translators and reviewers the context the JSON itself doesn't carry. |
| **JSON Editor** | Edits the locale content directly. Select **Upload JSON** to bring in an existing file, or **Prettify** to reformat what's there. |