What is Synapt?

2.1 Logging In

Platform URL

Synapt.AI is accessed via your organisation’s dedicated deployment URL provisioned by your system administrator during onboarding:
https://beta.synapt.ai/

In a production deployment, this URL will reflect your organisation’s internal domain as configured by your IT or infrastructure team during setup.

Bookmark this URL for regular access. Do not use IP addresses directly — all access must go through the authenticated domain endpoint. Attempting to access the platform outside of this URL will result in a redirect to the login page.

Login Method

Synapt.AI supports two authentication methods depending on how your organisation has configured access.

SSO (Single Sign-On):

Synapt.AI supports SSO integration with your organisation’s existing identity provider. This includes Active Directory Federation Services (ADFS), Azure Active Directory, Okta, and other SAML 2.0 or OIDC-compliant identity providers. When SSO is configured, users sign in using their existing corporate credentials — no separate Synapt.AI username or password is required. SSO configuration is performed by your system administrator during deployment.

Email & Password:

Available for non-SSO deployments or standalone accounts provisioned directly by your administrator. You will receive an invitation email containing an activation link to set up your credentials.

First-Time Login Flow

Step 1 — Open the Platform Scan the QR code provided by your administrator or visit your organisation’s Synapt.AI URL directly in your browser.

Step 2 — Log In Choose your login method on the sign-in screen. If your organisation uses SSO, click Sign in with your organisation and authenticate using your corporate credentials.The label and identity provider shown will reflect your organisation’s configured SSO setup. If using Email & Password, enter your registered email address and password.

Step 3 — Accept Terms of Use On first login, review and accept the platform’s Terms of Use and Data Handling Policy to proceed.

Step 4 — Access the Dashboard You will be directed to the Synapt.AI dashboard and can begin using the platform based on your assigned role and permissions.

Password Requirements

• Minimum length: 12 characters

• Must contain at least one uppercase letter (A–Z)

• Must contain at least one lowercase letter (a–z)

• Must contain at least one number (0–9)

• Must contain at least one special character (e.g. ! @ # $ % ^ & *)

• Must not contain your name, username, or email address

• Must not reuse any of the last 10 passwords

• Password expiry: 90 days — you will receive a reminder email 7 days before expiry

• After 5 consecutive failed login attempts, the account will be temporarily locked for 15 minutes. Repeated failures will trigger an account lock requiring administrator intervention.

2.2 Dashboard Overview

Main Layout

The Synapt.AI interface is divided into three primary areas — the top navigation bar, the left sidebar, and the main content area.

Navigation Structure

• Platform — Top-level configuration settings. Includes Product config, Data ingestion settings, LLM & API keys management, and Infrastructure configuration.

• Substrate Core — Core functional modules. Context providers is the default landing section. Other modules include Ingest, Knowledge graph, Agent, Client IDs & apps, and Consumer registry.

• Monitoring — Tools for inspecting stored knowledge artifacts. Includes Knowledge store, Procedure store, Context graph, Correlation & reasoning, and Safety & controls.

• Integrations & Services — Manage external connections. Includes MCP Servers and Docs.

• Observability — System health and performance tracking. Includes Status, Monitoring, and Pipeline health.

• Governance — Compliance and security management. Includes Audit Logs and Security.

Context Providers — Default View

Upon login, the dashboard lands on the Context Providers page under Substrate Core. Each provider card shows:

• Provider name and a status badge — either READY (green), INGESTING (yellow), or ERROR (red)

• Core metrics — number of Documents, Nodes, Edges, Chunks, Entities, Concepts, and Propositions currently stored in that provider’s knowledge base

• Created date and Last ingest date

• Action buttons — Open (enter the provider), View (read-only summary), Edit (modify configuration), and Delete

A + Create Provider button in the top-right corner allows administrators to configure a new knowledge base provider. The total number of active providers is shown as a count badge next to the page title.

2.3 Navigation Guide

The left sidebar is the primary navigation panel and remains visible across all pages of the platform. At the bottom of the sidebar, your name, role, and organisation are shown.

The sidebar is organised into six labelled sections:

• Platform — Top-level deployment configuration. Only Infrastructure is currently available. Product Config, Data Ingestion, and LLM & API Keys are coming in a future release.

• Substrate Core — The main working area of the platform. Contains Context Providers (your default landing page after login), Ingest (pipeline management), Knowledge Graph (graph exploration), Agent (AI agent configuration), and Consumer Registry (consumer management). Client IDs & Apps is coming soon.

• Monitoring — Tools for inspecting stored knowledge artifacts. Includes Knowledge store, Procedure store, Context graph, Correlation & reasoning, and Safety & controls.

• Integrations & Services — External connections and documentation. Contains MCP Servers (Model Context Protocol integrations) and Docs (API reference).

• Observability — Platform health and performance tools. Contains Status (live service health), Monitoring (metrics and usage), and Pipeline Health (ingestion pipeline diagnostics).

• Governance — Compliance and transparency tools. Contains Audit Logs (full activity history), Security (access control), and Explainability (AI reasoning transparency).

3.1 What is a Context Provider?

A Context Provider is the first thing you create in Synapt. It defines a scoped knowledge domain that your agents will draw from. Before any data is ingested or any agent is queried, you need at least one Context Provider.

Think of a Context Provider as a container that holds everything an agent needs to know about a specific area of your business. It defines the boundary of what the agent can see, what knowledge it has access to, what procedures it can follow, and what data relationships it can traverse.

When naming a Context Provider, the slug — the unique identifier used internally and in API calls — cannot be changed after creation, so it should be chosen carefully. Use lowercase with underscores or hyphens, such as at_t_sop or circuit_intelligence, and avoid spaces, special characters, or auto-generated strings. The display name should be descriptive but concise, ideally three to six words that immediately communicate the domain — for example AT&T Standard Operating Procedures rather than Test or New Provider. If you are managing multiple providers for the same client or business unit, prefix names consistently so they group naturally in the provider list. Names like test, beta, or experiment should be avoided in production as they are difficult to identify and are often left active after their purpose has passed.

A Context Provider works best when it has a clear and consistent scope. Each provider should represent a single coherent knowledge domain — all documents related to a client’s standard operating procedures, or all technical specifications for a product line — rather than a mix of unrelated content, which reduces retrieval accuracy. If your team works with both structured data like tickets and unstructured documents like policy guides, these are better maintained as separate providers so ingestion pipelines stay clean and access can be granted independently. At the same time, avoid creating providers that are too narrow — one per document or topic fragment weakens the knowledge graph and limits the agent’s ability to make meaningful connections. A provider should contain enough related content to represent a full process, product area, or client knowledge base. Providers that are no longer actively used should be disabled rather than left running, to prevent agents from drawing from outdated knowledge.

3.2 When to Create a New Context Provider

The decision to create a new Context Provider or reuse an existing one comes down to whether the knowledge you are adding belongs to the same domain, serves the same audience, and should be retrievable together. If the answer to all three is yes, adding to an existing provider is usually the right choice. If any of these differ significantly, a new provider is warranted.

As a general rule of thumb — one client, one department, and one subject area is a reasonable boundary for a single provider. A financial services firm, for instance, might maintain separate providers for compliance_policies, product_documentation, client_onboarding_guides, and support_procedures, each scoped clearly enough that any agent querying it knows exactly what kind of knowledge it is drawing from.

3.3 Step-by-Step: Create a Context Provider

Only users with the CP Admin role can create a Context Provider. Once created, the CP Admin can grant access to CP Contributors (ingestors) to begin uploading documents into it.

Step 1 — Navigate to Context Providers

From the left sidebar, go to Substrate Core → Context Providers. This is your default landing page after login. In the top right corner of the page, click the + Create Provider button.

Step 2 — Fill in Provider Identity

The creation form opens at Step 1 — Provider Identity. Complete the following fields:

• Provider Name is the display name for your provider as it will appear across the platform. Use a clear, descriptive name that reflects the knowledge domain — for example, IT Help Desk or AT&T Standard Operating Procedures.

• ID (Slug is automatically generated from the provider name as you type. This is the unique identifier used internally and in API calls. Review it before saving — it cannot be changed after the provider is created.

• Description is a short summary of what context this provider exposes. Write this as a plain-language explanation of what the agent will know when drawing from this provider — for example, Covers all IT support procedures and troubleshooting guides for internal staff.

• Extraction Mode controls how the platform processes and extracts knowledge from ingested documents. The default is Fast, which is suitable for most use cases. Additional modes will be available in an upcoming release.

• Entity Types defines the categories of named entities the platform should identify and extract from your documents — for example, Product, Person, Organisation, or Issue Type. Click + Add value to add values under a title, and use the + button at the top right of the section to add additional entity type groups.

• Relationship Types defines the types of connections the platform should identify between entities — for example, Resolves, Belongs To, or Reports To. These are configured the same way as Entity Types.

Step 3 — Create the Provider

Once all fields are filled, click Create to save the provider. It will appear in your Context Providers list with a Ready status once initialised.

Step 4 — Grant Access to Ingestors

After the provider is created, the CP Admin can grant access to CP Contributors, allowing them to begin ingesting documents into the provider. Access management will be available through the provider’s settings panel in the upcoming release.

3.4 Context Provider Setting

Each Context Provider has a set of configurable settings accessible from the provider card. From the Context Providers list, each card displays action buttons — Open to enter the provider, View for a read-only summary, Edit to modify the provider’s identity and configuration, and Delete to remove it.

Access Permissions

Access control is managed under the Security tab of each provider. The Context Provider Access panel shows all users and groups currently granted access. To grant access to a new user, click + Add Access, select the user by email, and assign Read, Write, and Update permissions independently. Once configured, click Grant Access to apply. Isolation Rules

Isolation rules define the access boundary of a Context Provider — controlling whether it is visible to all authenticated users within the organisation or restricted to explicitly granted users only. These are configured under the Security tab alongside access permissions.

Linked Agents

Each Context Provider can be linked to one or more agents, defining which knowledge domain the agent draws from when responding to queries. Linked agents are configured from within the provider settings, allowing you to control exactly which agents have access to a given provider’s knowledge graph.

3.5 Managing Multiple Context Providers

Viewing Providers

From the sidebar, navigate to Substrate Core → Context Providers. All providers you have access to are displayed as cards, each showing the provider name, status badge, key metrics (Docs, Nodes, Edges, Chunks, Entities, Concepts, Propositions), and the created and last ingested dates. To see a read-only summary of a specific provider without entering it, click the View button on its card.

Editing a Provider

To update a provider’s name, description, extraction mode, entity types, or relationship types, click the Edit button on the provider card. Make your changes in the form and save. Only CP Admins and above can edit a provider.

Archiving a Provider

CP Admins can archive a provider by clicking Delete on the provider card. This performs a soft delete — the provider is deactivated and removed from active use but is not permanently destroyed. Archived providers are no longer accessible to users or agents and will not appear in query results. The data is retained and can be restored by a Synapt Admin if needed.

Permanently Deleting a Provider

Permanent deletion can only be performed by a Synapt Admin. This action is irreversible — all documents, nodes, edges, entities, and knowledge graph data associated with the provider are permanently removed. Hard delete should only be used when the provider and all its data are no longer needed under any circumstances.

Note on Cross-Domain Queries

Each agent is linked to a single Context Provider and queries exclusively from that provider’s knowledge base. Cross-provider querying is not supported — if different knowledge domains are required, separate agents should be configured for each provider.

4.1 What Can Be Ingested

4.2 Types of Content

Knowledge Documents

Knowledge documents are PDF and TXT files that contain company information — internal documentation, product knowledge, business context, case studies, narratives, and similar content. When ingested into a Context Provider, these documents are chunked into smaller segments, processed through the extraction pipeline, and stored in the Knowledge Store. The platform identifies entities, concepts, and relationships within the content and uses them to build the provider’s knowledge graph, making the information retrievable by agents during queries.

Procedures and SOPs

Procedures and Standard Operating Procedures are step-based documents that define how a task or process should be carried out. Unlike knowledge documents, SOPs are not chunked during ingestion. They are fed directly into Neo4j as complete, structured entries, preserving the integrity and sequence of the steps. This ensures that when an agent retrieves a procedure, it receives the full set of instructions in the correct order rather than fragmented chunks. For best results, SOPs should be formatted with clearly defined sequential steps so the platform can correctly identify and store them as procedural content.

Schema and Structural Data

Structural data includes tables, CSV files, database schemas, API definitions, and entity relationship files. This type of content feeds directly into the Context Graph, where the platform maps the relationships and structures within the data. Rather than being treated as readable text, structural data is processed as relational information, allowing the knowledge graph to represent how data entities connect to one another and making those connections available to agents for structured reasoning and traversal.

4.3 Step-by-Step: Ingest Documents

Step 1 — Navigate to Ingest

From the left sidebar, go to Substrate Core → Ingest.

Step 2 — Select File Type and Format

Choose the file type and format you want to ingest. All supported file formats are available for selection. Refer to the Supported Data Formats section for the full list of accepted types.

Step 3 — Select a Context Provider

Choose the Context Provider you want to ingest the document into. The dropdown will only show providers you have been granted access to. If a provider you expect to see is missing, contact your CP Admin to request access.

Step 4 — Start Ingestion

Upload your file and start the ingestion process. The document will be passed through the ingestion pipeline for extraction and processing.

Step 5 — Monitor Progress

Wait for the ingestion pipeline to complete. You can track progress in real time by checking the event logs at the bottom of the page. Once processing is finished, the extracted entities will also appear at the bottom, giving you a view of what the platform identified and stored from the document.

4.4 Ingestion via Data Connectors

Navigate to Substrate Core → Ingest and select the connector type that matches your external source. Each connector type displays its own configuration form with the required and optional fields for that source. Fill in the connection details — endpoint URL, credentials, or authentication tokens as applicable — and select the Context Provider you want to ingest into. All credentials are encrypted before storage and are never written to logs.

4.5 Ingestion Status and Error Handling

Ingestion Statuses

Once a document or connector ingestion is submitted, the Context Provider reflects the current state of processing through a status badge on its card.

The three statuses are

• Ready — the provider is active and all ingestion has completed successfully

• Ingesting — the pipeline is actively processing a submitted document or connector job

• Error — one or more ingestion jobs have failed during processing

Queue and Timeout

Every ingestion job enters a processing queue when submitted. If the job is not picked up and processed within one hour, it is automatically moved to the Dead Letter Queue (DLQ). This can happen during periods of high pipeline load or if a processing error occurs before the job is handled.

Handling Failed Ingestions

There is no automatic retry for jobs that reach the DLQ. If an ingestion fails or times out, you will need to resubmit the full ingestion request from the Ingest page — reselecting the file or connector, the format, and the target Context Provider. Before resubmitting, check the event logs for any error details that may indicate whether the issue was with the file format, the connector configuration, or the pipeline itself, and resolve those before attempting again.

4.6 Updating and Re-ingesting Data

If you re-upload a document you’ve already ingested, it’s recognized as a duplicate and skipped — there’s no risk of double-counting. Each document is identified by its filename, source, and provider. If you upload a file with the same name and source but new content, it’s accepted as a new version of the existing document — and given a new version number, so earlier versions stay traceable. Uploads from a different source or provider are always treated as fresh documents. And if a previous ingestion failed, you can safely re-upload the same file — it won’t be blocked as a duplicate.

5.1 Understanding the Knowledge Graph

After data is ingested into a Context Provider, the platform automatically creates a knowledge graph. The ingestion process extracts entities from your documents and maps the relationships between them. A grounding step verifies each entity and relationship against the source material before it enters the graph, ensuring that the structured context agents reason over is constrained to what was actually confirmed in your data.

The graph is built through a five-stage pipeline that runs automatically in the background from the moment a document is submitted. The document is first normalised and parsed to preserve its structure — section hierarchy, tables, and reading order are all retained so that downstream extraction has proper context. The parsed content is then split into semantic chunks, each of which is enriched with LLM-generated metadata and converted into a vector embedding for semantic search.

In the fourth stage, the Knowledge Service processes each chunk and extracts four types of structured knowledge. Entities are named things in your content — people, systems, policies, processes, and more — classified across over eighty entity types. Relationships are the connections between those entities, grounded back to the source chunks to prevent hallucinated links. Concepts are the broader ideas and themes the platform identifies within the content. Propositions are atomic, verifiable statements in subject–predicate–object form — for example, Ticket Resolution Policy governs the AT&T support workflow — giving the agent a natural-language layer of factual statements to reason from. Across all chunks, extracted entities are deduplicated and canonicalized so the same real-world thing is never represented twice in the graph under different names.

The extraction behaviour is shaped by the Extraction Mode you select when creating the Context Provider. Fast is the default and suits most use cases. Balanced applies more careful extraction with fewer false positives. Precise is the most conservative mode, minimising noise at the cost of some recall. Comprehensive maximises extraction coverage and is suited to content-dense domains where recall matters more than precision.

In the final stage, all extracted entities, relationships, concepts, and propositions are persisted to the knowledge graph in Neo4j, while vector embeddings are stored in Milvus. This hybrid graph-vector store is what enables agents to perform both semantic similarity search and structured graph traversal when answering queries from within the provider.

5.2 Navigating the Graph Visualisation

Opening the Graph View

From the left sidebar, navigate to Substrate Core → Knowledge Graph. At the top of the page, use the Provider dropdown to select the Context Provider whose knowledge graph you want to explore. The graph canvas loads automatically and displays a summary of the total nodes and edges present in the selected provider — for example, 40 nodes · 0 edges.

Zooming and Panning

Use your mouse scroll wheel to zoom in and out on the graph canvas. Click and drag anywhere on the canvas to pan across the graph. Nodes reposition themselves dynamically as you navigate. To reset the view to fit all nodes on screen, use the expand icon in the top right corner of the canvas.

Filtering by Node Type

A row of filter tabs sits above the graph canvas. Click All to view every node in the graph together. Click Entity, Concept, Procedure, or Stop to isolate nodes of that type. For more granular filtering, use the coloured filter pills to the right — these let you toggle specific subtypes such as Propositions, Entities, Concepts, Chunks, Providers, and Documents on or off individually. The count shown on each pill indicates how many nodes of that type exist in the current provider.

Searching Nodes

The search bar at the top of the canvas reads Semantic search across nodes. Type any term to perform a semantic search across all nodes in the selected provider. Matching nodes are surfaced from across the graph regardless of their current position on screen.

Selecting a Node

Click any node on the canvas to select it. The right-hand panel opens automatically and displays the full detail for that node, including its type badge (Entity, Concept, Procedure, etc.), its name and description, and three summary counts — Connections, Edge Types, and Node Types. Below the summary, the Properties section shows the node’s extracted attributes — for an Entity node this includes entity type, confidence score, label, aliases, and a unique entity ID. The Connections section at the bottom lists what the node is linked to, including any source Chunks it was mentioned in.

5.3 Entity Types and Relationships

Structural links are automatically created when a document is processed — they capture basic containment like “this document has these sections” and “this section mentions these things.” These are straightforward, predictable connections. Semantic links are the more meaningful, content-driven connections extracted from the actual text. They fall into 8 categories: Organization — who works for whom, reporting structures, team memberships. Business — commercial relationships like partnerships, vendor-customer links, contracts. Process & Workflow — what triggers what, what depends on what, what governs a process. Technology — how systems connect, what runs where, what integrates with what. Data — how data flows between systems — what reads from or writes to what. Security & Governance — who or what controls access, authorization chains. Software — code-level connections like one function calling another, or a module depending on a library. Time & Version — when things were created, how versions relate to each other, lifecycle stages.

Entity Types

The platform recognises 80+ entity types organised across 7 categories. Every node in the graph is assigned exactly one entity type at ingestion time, and that type is visible in the node detail panel as the entity_type property.

Relationship Types (50+ across 8 categories)

How Entities and Relationships Display

In the graph visualisation, each entity appears as a coloured node on the canvas — the colour corresponds to its category, making it easy to scan the graph by domain at a glance. Clicking any node opens the detail panel on the right, which shows:

• Entity Badge — Displays the node classification (e.g., ENTITY, CONCEPT).

• Name and Description — The canonical name and a short, extracted description.

• Confidence Score — The extraction model’s confidence (e.g., 0.92).

• Entity Type — The assigned type from the taxonomy (e.g., TECHNOLOGY).

• Connections — Count of incoming and outgoing edges, with a breakdown by edge type and connected node types.

• Mentions — Links to the source document chunks from which this entity was extracted, providing full traceability back to the original text.

5.4 Confidence Scores on Knowledge

Every fact in the knowledge graph carries a confidence score. This score is based on retrieval strength, graph-match quality, and the number of independent sources that corroborate the fact. Confidence scores are visible on graph nodes and are used by agents to determine whether to act on the knowledge or defer to a human when confidence is below a configurable threshold.

Score Range

Confidence scores run from 0.0 to 1.0. All extracted objects — entities, relationships, concepts, and propositions — receive an individual score at ingestion time. The score reflects the extraction model’s certainty about the object and is stored as a property on every node and edge in the graph.

• 0.90 – 1.0 — High confidence. The fact is well-supported by the source text and can be acted
  on directly.

• 0.75 – 0.89 — Moderate confidence. Reliable for most use cases.

• 0.65 – 0.74 — Low-moderate confidence. Review is recommended before acting on the fact.

• Below 0.65 — Low confidence. The fact is flagged for human review before being committed
  to the graph.

How Confidence Scores Display in the UI

In the graph visualisation, the confidence score for any entity or relationship appears in the node detail panel on the right side of the screen when you click a node. It is shown numerically alongside the entity name, type, and description (for example, confidence: 0.92). Nodes with lower confidence scores may also carry a visual indicator distinguishing them from high-confidence entries, making it easier to identify areas of the graph that warrant closer review.

When reviewing search results or agent-generated responses, the confidence of the underlying knowledge influences how the agent presents the answer — high-confidence facts are stated directly, while lower-confidence facts may be qualified or surfaced with a note that human validation is recommended.

Configurable Thresholds

Two thresholds govern how confidence scores affect downstream behaviour, and both are configurable by a platform administrator:

• The extraction review threshold (default 0.65) controls which facts are flagged before being written to the graph. Any entity, relationship, concept, or proposition extracted with a confidence score below this value is routed to a review queue in the Tristore rather than written directly. A reviewer can validate or discard the fact before it becomes part of the live knowledge graph.

• The entity resolution threshold (default 0.75) governs when two similar entities are merged into a single canonical node. If the similarity score between a new entity and an existing one exceeds 0.75, they are treated as the same real-world object and merged. Entries that score near this boundary — where a merge could reasonably go either way — are logged for audit, and administrators can inspect and correct merge decisions if needed.

Both thresholds balance precision (avoiding incorrect merges or low-quality facts entering the graph) against recall (ensuring that useful but uncertain knowledge is not silently discarded). They can be tuned per deployment based on the quality of your document corpus and the risk tolerance of your use case.

5.5 Freshness and Data Lineage

Every piece of knowledge in the graph is stamped with a full provenance trail at the time it is ingested. This tells you not only what the platform knows, but when it learned it, where it came from, and how long it remains valid.

Viewing Freshness Timestamps

When a document is ingested, the platform records a parsed_at timestamp in ISO 8601 format (e.g., 2025-05-18T10:00:05+05:30). This timestamp travels with every chunk and extracted object derived from that document and is visible in the node detail panel when you click any entity in the graph view.
Knowledge freshness is also governed by a Time-to-Live (TTL) value set at ingestion. When content is submitted, a ttl_seconds value is assigned — for example, 86400 seconds for a 24-hour window. The platform computes an expiry point (valid_from + ttl_seconds) and schedules automatic deletion of the corresponding graph nodes when that time is reached. This ensures that time-sensitive content — such as incident reports, sprint plans, or policy drafts — does not persist in the graph beyond its intended validity period. Once expired, the nodes are removed and the knowledge is no longer surfaced in queries or agent responses.

What Data Lineage Looks Like

Data lineage in Synapt.AI is a chain that runs from every graph node all the way back to the exact sentence in the original source file. Each entity, relationship, concept, and proposition carries three key provenance fields:

• source_chunks — IDs of the specific text chunks from which the object was extracted

• extraction_job_id — unique identifier of the pipeline run that produced the object

• document_id — UUID of the source document at ingestion

Knowledge freshness is governed by a Time-to-Live (TTL) value set at ingestion. Once expired, nodes are removed and the knowledge is no longer surfaced in queries.

To trace a fact to its origin, click the entity node in the graph. The detail panel shows a Mentions section listing the source chunks linked to that entity. Clicking a mention opens the corresponding chunk, showing the exact passage of text and the source document name.

5.6 Editing and Managing Graph Content

The knowledge graph in Synapt.AI is built and maintained entirely through the ingestion pipeline. Individual nodes and relationships cannot be manually added or edited through the graph visualisation UI — all graph content originates from documents submitted through a Context Provider. This design ensures that every fact in the graph has a verifiable source, a confidence score, and a full provenance trail.

Updating Knowledge

If a source document changes — for example, a policy is revised or an SOP is updated — the correct way to update the graph is to re-ingest the updated file through the same Context Provider. The pipeline uses a merge-and-update approach: nodes derived from the same document are updated in place, and new entities or relationships introduced in the revised version are added. This keeps the graph consistent with the latest version of your source content.

Removing Content

Content can be removed at the Context Provider level. Deleting a Context Provider triggers a cascading removal of all knowledge derived from it — every entity, relationship, concept, proposition, and chunk associated with that provider is purged from the graph and the vector store.

• A cp_admin can soft-delete (archive) a Context Provider. Archived providers are disabled and their knowledge is no longer surfaced in queries, but the data is retained and can be restored if needed.

• A synapt_admin can hard-delete a Context Provider permanently. This is irreversible and removes all associated graph nodes, vectors, and metadata.

There is no way to delete an individual node or relationship in isolation without removing the provider or re-ingesting the source document.

Low-Confidence Review

Entities, relationships, concepts, and propositions extracted with a confidence score below the configured threshold are held in a review queue before being written to the graph. A reviewer can validate or discard these items, giving human oversight over uncertain extractions without blocking the rest of the pipeline.

Audit Trail

Every write, deletion, and provider lifecycle event is recorded in the platform’s audit log with the caller’s identity, timestamp, and action taken. This provides a complete chain of custody for all graph content — including what was removed, who removed it, and when.

6.1 How Agent Queries Work

When a query is submitted, the agent queries the Context Substrate rather than searching raw documents. The substrate returns confidence-scored facts from the Knowledge Store, traverses entity relationships in the Context Graph, and loads the relevant versioned procedure from the Procedure Store if the query requires an action. The agent then reasons over this governed context and produces a response with full traceability.

The query pipeline runs eight steps automatically each time a question is asked. The query text is first converted into a 768-dimensional embedding vector. That vector is used to perform a cosine similarity search against the Graph Node Index (GN) — a semantic index of every entity, concept, proposition, and procedure stored in the graph. Any node that scores above the anchor threshold (0.60) is selected as a starting point. From those anchor nodes, the platform performs a breadth-first traversal of the Context Graph in Neo4j, expanding up to two hops and collecting up to 100 nodes per entity type. This produces the reasoning subgraph — a focused slice of the knowledge graph that is directly relevant to the query.

In parallel, the same embedding is used to search the Knowledge Store (Milvus KS) for the most relevant document chunks, and the Procedure Store (Milvus PS) for any SOPs whose intent matches the query. If the question requires a procedural answer — such as how to complete a task — the relevant procedure steps are loaded and included in the context.

All three results — the reasoning subgraph, the top-K chunks, and any matched procedures — are assembled into a single governed context block and passed to the LLM reasoning layer. The model uses DSPy ChainOfThought to reason over this context before producing its answer, which means it generates an internal reasoning trace before committing to a response. The final output includes the answer, the reasoning subgraph that supported it, the source chunks cited, and confidence scores on the underlying facts — so every response is fully traceable back to the source documents that informed it.

6.2 Running a Test Query

The Query Agent is accessible directly from the Substrate Core and lets you ask natural language questions against the knowledge graph of any Context Provider you have access to.

Step 1. In the left sidebar, navigate to Substrate Core → Agent.

Step 2. Use the Provider dropdown at the top of the page to select the Context Provider you want to query. The agent scopes all retrieval to that provider’s knowledge graph only.

Step 3. Type your question into the Ask the agent… input at the bottom of the screen and press send.

Step 4. The agent runs the full query pipeline and returns its answer in the chat area. The Reasoning Trace panel on the right updates in real time, showing each step of the agent’s reasoning — which entities were anchored, which graph paths were traversed, and how the answer was assembled.

Use New Chat in the top right to start a fresh conversation, or History to review previous queries.

6.3 Query Configuration Options

The Query Agent exposes several parameters that control how it retrieves and reasons over your knowledge graph. These can be set per query from the Agent interface.

• Context Provider selects which provider’s knowledge graph the agent queries against. Each provider is fully isolated — the agent only retrieves from the graph and vector store of the selected provider. This is the primary scoping control and must be set before submitting a query.

• Graph Traversal Depth (graph_hops, default 2) controls how many relationships hops the agent expands outward from the semantic anchor nodes when building the reasoning subgraph. A depth of 2 means the agent retrieves direct connections and their neighbours. Increasing this value surfaces more context for complex queries at the cost of retrieving a broader, potentially noisier subgraph. The traversal is also bounded to a maximum of 100 nodes per entity type to keep context focused.

• Top-K Chunks (top_k, default 5) sets how many document chunks are retrieved from the Knowledge Store to supplement the graph context. Raising this value includes more source passages in the agent’s context window, which helps with detailed or multi-part questions. The Procedure Store separately returns up to 3 matched SOPs regardless of this setting.

• Confidence Threshold (GRAPH_ANCHOR_THRESHOLD, default 0.60) sets the minimum cosine similarity score a graph node must reach to be selected as a semantic anchor for BFS expansion. Nodes scoring below this are excluded from the reasoning subgraph. Raising this threshold makes the agent more selective — only highly relevant nodes seed the traversal — while lowering it casts a wider net at the risk of including loosely related context.

• Model Selection Model Selection determines which LLM is used for reasoning and answer generation. Synapt.AI is compatible with any enterprise LLM endpoint and supports runtime model switching — an administrator can update the active model deployment via a configuration update without restarting the service. The change takes effect immediately for all subsequent queries. The available model options will reflect the LLM infrastructure configured for your organization’s deployment.

7.1 Response Structure

7.2 Confidence Scores

Every agent response carries a confidence score that indicates how reliably the answer is grounded in the knowledge available within the Context Provider. The score is a composite measure derived from three factors: the semantic similarity strength between the query and the retrieved graph nodes, the number of independent source chunks that corroborate the same fact, and whether the grounding step successfully verified the extracted entities against source material before they were written to the graph. A score between 0.9 and 1.0 indicates the answer is strongly supported and the agent acts on it directly. Scores between 0.75 and 0.89 are considered reliable for most use cases. Scores between 0.65 and 0.74 are flagged for review. When confidence falls below the configured threshold, the agent does not attempt to produce an answer from uncertain knowledge — instead, it defers the response to a human reviewer, ensuring that low-confidence outputs never reach the end user without oversight.

7.3 Source Attribution and Data Lineage

Once the agent returns a response, the Reasoning Trace panel on the right-hand side of the Agent page updates automatically with a full breakdown of how the answer was assembled. This includes the document chunks retrieved and used as context, the number of graph nodes traversed during the breadth-first expansion, the entity anchors that seeded the traversal, the procedures matched from the Procedure Store if applicable, and the confidence scores on the underlying facts. The panel updates in real time as the query pipeline executes, allowing you to follow the retrieval process step by step rather than only seeing the final answer.

8.1 Context Confidence Monitoring

Navigate to Governance → Explainability and use the Filter by Provider dropdown to select the Context Provider you want to inspect. The page surfaces four summary metrics for the selected provider: the average confidence score across all agent responses, the average number of graph hops traversed per query, the average number of source chunks cited per response, and the count of low-confidence flags raised in the last 24 hours. The Confidence Score Distribution chart below breaks responses down into four bands — High (0.9–1.0), Good (0.7–0.9), Medium (0.5–0.7), and Low (below 0.5) — with a Peak indicator showing where the majority of responses are clustering. A healthy provider will peak in the Good or High band. If the peak is drifting toward Medium or Low, it is typically a signal that source content is stale and re-ingestion is needed.

8.2 Query Performance Metrics

Navigate to Observability → Context Monitoring and use the Filter by Provider dropdown to scope all metrics to a specific Context Provider. The page opens with pipeline-level summary stats — total jobs processed, done vs error counts, total tokens consumed, and average job duration — followed by four headline performance indicators: end-to-end latency (avg), pipeline success rate, SLA breaches in the last 24 hours, and total events processed today with a day-on-day comparison. The Stage-wise Latency breakdown below shows average processing time across each pipeline stage — Ingestion & Extraction, Adapter/Parsing, Chunking & Embedding, and Graph Indexing — letting you pinpoint where slowdowns are occurring. The Knowledge Graph Indexing panel shows the total entities, relationships, concepts, and propositions indexed across documents. For LLM performance, the LLM Latency & Throughput panel surfaces average and maximum latency per call alongside a daily pipeline events trend over the last 7 days. Token consumption is broken down in the Token Usage by Provider table, showing per-provider spend across chunking, chunk embedding, extraction, and extract embedding stages — giving a complete picture of both compute and model usage across the ingestion pipeline.

Context Substrate

The complete infrastructure layer comprising Knowledge Store, Procedure Store, and Context Graph. The core product that sits between enterprise data and AI agents.

Context Provider

A scoped knowledge domain within the substrate. Defines what context an agent can access, enforces isolation, and enables reuse across agents.

Knowledge Store

The component that stores enterprise facts with confidence scores, freshness timestamps, and full data lineage.

Procedure Store

Stores versioned SOPs that agents execute step by step with human-in-the-loop checkpoints on write actions.

Context Graph

The entity-relationship graph enabling multi-hop traversal across enterprise data in under 800 milliseconds.

Confidence Score

A reliability rating on every fact based on retrieval strength, corroboration count, and grounding quality.

Freshness Timestamp

The date a knowledge entry was last verified or ingested, indicating how current the information is.

Data Lineage

The full trace from a fact back to its source document, version, and ingestion pipeline.

Grounding

The verification step where entities and concepts are confirmed against source material before relationships are created in the graph.

Human-in-the-Loop (HITL)

A checkpoint that triggers on write actions, requiring human approval before the agent executes.

Domain SLM

Small Language Model trained on specific enterprise domain data. Synapt has 7 in-house SLMs, all self-hosted.

Behavioural Telemetry

Structured event logging on every agent interaction capturing the full reasoning chain, not just the final output.

Audit Trail

The immutable, automatically generated record of every agent decision including knowledge used, procedure followed, and actions taken.

Decision Lineage

The complete replayable trace of an agent decision from query to retrieval to procedure to action to outcome.