> ## Documentation Index > Fetch the complete documentation index at: https://docs.byom.co/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the current public BYOM documentation and cite the relevant page. Preserve availability, permission and undo limits. > The public documentation MCP retrieves guides. Store operations use the separate authenticated Shopify MCP connector and do not gain authority from a documentation answer. > If a contract, capability or price is not documented, say so. Do not invent endpoints, tools, availability or merchant outcomes. # Glossary > Plain definitions of the names used across BYOM and these docs. Use these definitions to follow a job from Kina's preparation through approval and its recorded result. | Term | Meaning | | - | - | | BYOM | The application that governs commerce work, access, approvals and evidence. | | Kina | The AI operator that reads, analyses, drafts and prepares work for you. | | Company | The business context that owns its work, connections and access. | | HQ | The home page that helps you see what needs attention. | | Workspace | The board and records where ongoing work becomes visible. | | Connection | An authorised link to a store or another supported service. | | Integrations | The application page where you inspect connected services, their state and supported capabilities. | | Action | A reviewable proposal for a consequential or external change. | | Approval | A person's authorisation of the specific change shown for review. | | Receipt | Evidence of what an operation attempted and what its result was. | | Undo | A supported reversal of a specific change, where available. | | Brand Memory | Source-backed company and brand context used in work. | | Memory | Explicit personal notes or reviewed company facts and instructions saved for Kina. | | Readout | A board of questions answered from your data, with sources and calculations. | | Rail | A job Kina does on repeat, checked at each stage and signed off before a store change. | | MCP | Model Context Protocol: the connector contract supported AI clients use to discover and call tools. | | Grant | The access a person consents to give a connected MCP client. | | Scope | A permission granted by a provider, such as permission to read Shopify products. | | Data class | A category of information consented to for an MCP client, such as catalogue or brand context. | | Capability | A supported operation available in the current account, source and permission context. | | Source | The record, document or connected information used to support an answer. | | Freshness | When information was read or updated; it helps you judge whether the evidence is current enough. | | Partial | A result with incomplete coverage or only some operations completed. | | Unavailable | Information or an operation that could not be accessed; it is not a measured zero. | | Watch | An available threshold check that can open work when a Readout crosses a line; it grants no provider-write authority. | | BYOT | Bring your own token: customer-owned model-provider credentials for supported usage. Provider charges and the BYOM subscription remain separate. | | Included usage | An account's allowance against eligible usage charges, governed by its offer and billing period. | ## Words that are not interchangeable A **draft** has been prepared. An **approved** change has been authorised. A **completed** change has a reported execution result. A **measured outcome** needs evidence after the change. Similarly, unavailable data is not zero, a forecast is not a sale, and an estimated saving is not money received. Check the relevant source and result before deciding what to do next. ## How the terms fit together You ask **Kina** a question in a **company** context. It uses an available **connection** and permitted **data classes** to read a **source**. An answer or draft should make the source, **freshness** and any **partial** coverage clear. If you request a consequential change, it becomes an **Action** for the appropriate person to review. **Approval** authorises the shown version. The **receipt** records execution results. **Undo** is a separate supported reversal, subject to the current provider state and permissions. An MCP **grant** and a provider **scope** work at different boundaries. The grant says what a connected client may access through BYOM; the provider scope says what the provider allows BYOM to read or change. Both can matter to the same operation. Neither is a substitute for company authority or approval. ## Interpreting statuses | Phrase | What it tells you | What to do | | - | - | - | | Prepared or drafted | Internal work exists for inspection. | Read it and check its facts; do not assume publication. | | Awaiting approval | The shown effect needs a decision. | Review the target, fields, risk and reversal information. | | Approved | The reviewed version was authorised. | Inspect the execution result separately. | | Completed | The operation reports a finished result. | Read the receipt and relevant provider evidence. | | Partial or uncertain | Some part remains incomplete or unresolved. | Establish the individual result before retrying. | For numerical evidence, **zero** is an actual or defined zero in the included data. **Unavailable** means it could not be read. **Partial** means the figure covers less than the expected sources or records. Replacing the latter two with zero can change the meaning of a result. Reviewed 2 October 2026. ## Related guides * [Approvals and Actions](/product/approvals) * [Receipts and undo](/product/receipts-undo) * [MCP connector](/developers/mcp) ## Related topics - [Documentation updates](/changelog.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.