SaibleDocs
Context

The context of each application

Read from the application's own sources, confirmed by a person and signed. A change waits for a decision.

Readrepository, accounts,traces, MCP serversProposea signed manifesthashes in the clearDriftcompared with theconfirmed manifestConfirmowner or admin+ codeBwidening: an adminSigned revisioncarries its hashgateway: not yet usedContext APIa signed receiptfor its agents↺ read again every night;sooner after a GitHub push or a Bedrock change
From an application's sources to a confirmed context manifest · sources are read, never written to
  • Repository
    prompts, coding-agent instructions, tool schemas, MCP configs · GitHub push
  • Amazon Bedrock
    agents, prompts, knowledge bases, guardrails · EventBridge
  • Snowflake
    Cortex Search, Cortex Agents, column tags
  • OpenAI
    projects, models used, Assistants, vector stores
  • Databricks
    serving endpoints, AI Gateway, vector search
  • Your traces
    what the application was observed to call, by hash
  • MCP servers
    Confluence, SharePoint, Salesforce, Google Drive, any
  • The registration
    purpose, team, approved models and what the team declared
Sources of context · tick: accepts change events · no reader has yet run against a live account
Resolvesubjects, session,application keyFreshnesseach source'srate of changePrecedenceauthority first,never silentQuarantineagent writes waitfor an adminBReceiptsigned; avoidedclaims and tokens
Live context · what is true about a subject now · API, with a card on the application's Context tab
  • 72.3%System of record, else the first source: how context was chosen before live context. Silent errors 27.7%.
  • 82.0%Live context. Silent errors 7.3%, and no poisoned agent write served at a 20% poison rate.
  • chars / 4How avoided tokens are estimated, and the answer says so. Not a tokenizer's count.
Live context on Saible's synthetic evaluation set · right answers, five seeds · not a customer measurement
  • In the clearHashes, structure and signatures: the models, the prompts by hash, the tools by schema hash, and the knowledge sources with their tags.
  • Kept encryptedThe text of a prompt and the full manifest. They are kept in your own bucket under your KMS key when you set one, otherwise in Saible's store under your organisation's key.
  • Never keptThe body of a change event: no commit message, no author and no request parameters. Only names and ids are kept.
Context data Saible keeps for an application
Steps
  1. 1An organisation admin connects a source with POST /api/v1/context/sources. The console has no form for it yet.
  2. 2On Context, under Connected systems (MCP), an organisation admin registers a server and clicks Attach to assign it to an application.
  3. 3On the application's page, click Read now and compare the proposed context manifest with the confirmed one.
  4. 4Click Confirm v…, either as the application's owner after MFA or as an organisation admin through the review queue.
  5. 5Open Ontology to see every context element, where it is read from and which applications use it.
For your agents

This topic is also documented as Agent Skills that your agents can load: context-layer, live-context, context-events, mcp-connected-systems, business-ontology, ontology, ontology-sources, context-health, ontology-api. Request them from Saible.

Next · Control Plane · AgentsConnect an agent to Saible over MCP →