> ## Documentation Index > Fetch the complete documentation index at: https://docs.tied.com/llms.txt > Use this file to discover all available pages before exploring further. # Learning controls > Decide which of your connected apps Tied Teammate may learn from, what it may read in them, and who approves what it finds. Everything is off until you turn it on. Your business changes faster than anyone updates a knowledge base. A policy is reworded, a feature ships, a workaround stops being needed, and the answer Tied Teammate gives is one step behind. Learning closes that gap. With learning on, Tied Teammate reads what you choose in the apps you connected, works out what a customer could now be told, and writes it up as a **proposal**. A person on your team approves it, edits it, or rejects it. Nothing it finds changes an answer until someone approves it. **Learning is off for every workspace until you switch it on.** Tied reads nothing from any app, and does nothing with any app, until you have turned learning on for your workspace, turned it on for that app, and listed what it may read. Which apps can feed learning is announced in the [changelog](/changelog) as each one becomes available; an app appears in the Learning settings only once it supports learning. ## What learning does Learning proposes new facts for the [knowledge](/agents/knowledge) Tied Teammate answers from. Each proposal is a question a customer might ask and the answer your business would give, with a link to the record it came from. **Today an approved proposal adds a fact.** Proposals that would change or retire a fact you already have are not available yet. Learning will not quietly rewrite or delete anything you have. Three rules hold for every proposal: * **Proposals only.** Learning writes drafts. A draft is not used to answer anyone. * **Source text is data, never instructions.** If a page, ticket or message contains wording aimed at the assistant, it is read as text to be summarised, not as a command. * **Your workspace only.** What is read for you is used for you. Nothing read from your apps is used for another business. ## What it reads Learning reads only what all of these allow: * **Apps your workspace connected.** An app that each person connects with their own login is not read. * **Apps you switched on for learning.** Connecting an app is not consent to learn from it. * **The scope you listed.** For each app you name what may be read, such as a set of repositories, folders, projects or channels, depending on the app. An app with an empty scope reads nothing. It only **reads**. Learning never writes to, edits or deletes anything in your apps. Tied keeps a short extract of each record it used, plus a link back to the original, so you can see where a proposal came from. It does not keep the whole record. The extract is cleared once the proposal is decided, after 30 days at most, and in the next daily clean-up after you turn learning off for the workspace or the app. ## What it never reads A repository, folder, project or channel you did not list is not read. A scope entry that does not match exactly reads nothing, so a typo fails safe. Turning an app off stops reading it straight away. Turning learning off for the whole workspace stops reading every app. If an app connects through each person's own account, those personal credentials are never used for learning. Every record read, every extract stored and every proposal written belongs to one workspace and is only ever visible to it. ## Turn learning on You need to be an administrator. Connect it from [Integrations](/integrations) for the whole workspace, if it is not already connected. In the Orchestration tab, open **Settings** and then **Learning**. This is the master switch. It is off by default, and with it off no app is read. Switch on each app you want Tied Teammate to learn from, then list what it may read. The defaults are the safe ones: an administrator reviews everything. Change them only if you have a reason. Your settings are saved as a numbered revision each time you change them, with who changed them, so there is always a record of what was in force. ## Choose a scope Scope is the list of things an app may be read for. It is the control with the most effect on what you get, so start narrow. | If the app has | You can list | Tip | | - | - | - | | Repositories | The repositories to read | Start with the one that holds your customer-facing documentation. | | Folders or paths | Folders inside them | End a folder with a slash to include everything inside it. | | Projects, spaces or pages | The ones that describe how you work with customers | Leave internal planning spaces out. | | Channels | Only channels where your team answers customer questions | Leave private and personal channels out. | **Do not list anywhere that holds things customers must never be told.** The blocks below are a safety net, not a licence. A narrow scope that you chose on purpose is the strongest protection you have. ## The other controls | Control | Default | What it does | | - | - | - | | **Learning for the workspace** | Off | The master switch. Off means nothing is read from any app. | | **Learning for an app** | Off | Lets that one app be read, inside its scope. | | **Scope** | Empty | What the app may be read for. Empty reads nothing. | | **Approval** | An administrator reviews every proposal | Nothing goes live without a person. | | **How many times before it is proposed** | 3 | Something that appears once in a ticket or a thread may be a one-off. Learning waits until a pattern repeats this many times, from 2 to 50. | | **Proposals per day** | 10 | The most proposals added to your queue in a day, from 0 to 1000. Extra ones wait for the next day instead of being dropped. An app can lower this for itself but never raise it above the workspace limit. | An app can only narrow what the workspace allows, never widen it. If the workspace switch is off, no app setting can turn reading back on. ## How approvals work Every proposal arrives in **Orchestration, Knowledge, Proposals**. Only administrators can decide them. For each proposal you see the question, the proposed answer, and where it came from, with links to the records behind it. Then you choose: * **Approve.** The fact is added to your [Corrections](/agents/knowledge) with your name on it and a confidence flag, and Tied Teammate uses it from then on. * **Edit.** Change the wording and save. Saving writes a new revision and keeps the original in the history. You can then approve the edited version. * **Reject.** The proposal is closed and does not go live. You can give a reason, which is saved with it. If the same thing is proposed again from a new source, you see your earlier reason next to it. Nothing is added to your live answers without one of these decisions from a person. **Every proposal waits for a person today.** Automatic approval is not available. ## What is blocked Before a proposal reaches your queue, Tied checks it for things that must never be shown to your customers. A proposal that fails is dropped, not trimmed or masked, and Tied records the category that blocked it and never the text. | Blocked | Examples | | - | - | | **Personal details** | A person's name when it comes from the records, email addresses, phone numbers, card and bank account numbers, street addresses, and order, case, ticket or account numbers. | | **Security detail and secrets** | API keys, tokens, passwords, vulnerability identifiers, and wording that reads like a security incident or an embargo. Anything that only looks sensitive is sent to a person to look at rather than shown. | | **Internal names** | Your staff's names, project code names, internal hostnames, repository names and ticket prefixes. Tied reads staff names from your workspace, and a list of further terms can be kept for your workspace. | | **Unreleased features** | A change that is merged or planned but has not reached customers. If Tied cannot tell it has been released, it is held, not proposed. | Your own public contact details, such as the support email and phone number on your inboxes, are allowed, because a good answer often needs them. **The blocks catch common patterns. They do not replace review.** A person approving each proposal is what keeps something wrong or private from going live, so read what you approve. ## Turn learning off You can turn learning off for one app, or for the whole workspace, at any time from **Settings** and then **Learning**. * Reading stops straight away. * The stored extracts for the app, or for the workspace, are cleared in the next daily clean-up. * Proposals already in your queue stay there for you to approve or reject. * Knowledge you already approved stays. To remove a fact, remove it from your Corrections. Applies to learning from now on; models already trained are not changed. ## Next Where Tied Teammate's knowledge comes from and how it is searched. Where you review proposals and publish a version. How the agent is kept from being tricked, and from promising what is not true. Who can see and decide proposals. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.