How it works

Authorised data in.A source-traced next-task brief out.

KynticAI Context Engine is a five-step mechanism: load approved signals, store them as attribution paths, match those paths to known outcomes, return schema-validated JSON, and let an approved model or human team explain the brief. This page is the canonical description of that process.

Read the processScout · Fortress · Elite
Canonical process · one system

  1. 01

    Load

    Authorised signals

  2. 02

    Store

    Attribution path

  3. 03

    Match

    Outcome paths

  4. 04

    Return

    Checked JSON

  5. 05

    Explain

    Model or team

Canonical process

Load → Store → Match → Return → Explain

One mechanism. Five stages. Every product layer (Scout, Fortress, Elite) implements this same chain at a different operating depth. If a diagram elsewhere on the site shortens the story, this section is the source of truth.

01 · Load

Bring in authorised signals from systems you already run

Context Engine starts with data items the customer has approved: not a free crawl of the estate, and not an unbounded paste into a model context window.

  • Connectors, APIs, files, and approved one-off imports map emails, cookies, browser events, CRM rows, tickets, usage, billing, documents, and outcome records into a consistent item shape.
  • Each item keeps identity hooks (account, email, cookie, object id), event type, timestamps, and source system — enough structure to join later without copying the whole source database into the product.
  • Load is purpose-scoped: only fields and systems agreed for the workflow enter the path. Credentials and bulk raw extracts stay under customer control.

Technical note. Load produces structured data items, not prose dumps. The system is preparing operational memory, not stuffing a prompt.

02 · Store

Keep the attribution path — order, source, and object

Signals are not stored as a flat pile of documents. For each customer, email, cookie, account, or case, the system stores what happened, in what order, and which source proved it.

  • An attribution path is an ordered trail: event A → event B → event C, with provenance on each hop.
  • Relationship facts (same email, same account, same product interest, linked ticket) sit with the path so later matching is structural, not keyword search alone.
  • Scout stores this trail in an inspectable PostgreSQL/pgvector proof store for developer and lower-load use. Fortress moves the same conceptual path into a private high-scale store for enterprise load.

Technical note. If the trail is not durable, every downstream step re-derives history from tribal knowledge. Store is the difference between “we have logs” and “we have relationship memory.”

03 · Match

Compare the current path with journeys that already finished

Matching is not “find similar text.” It compares the current attribution path with historical paths that converted, retained, escalated, delayed, or lost — weighted by outcome, not by cosine distance alone.

  • The current path is scored against prior relationship sets that share structure (same sequence shape, same object types, same commercial or operational pattern).
  • Outcome labels matter: converted vs not converted, saved vs churned, stabilised vs failed. Those labels turn history into guidance for the next task.
  • Fortress runs the proprietary path-weight analysis (Rust path engine with LanceDB-backed path storage) inside the customer-controlled estate. Scout can demonstrate the shape of the match at proof scale.

Technical note. The unit of comparison is the path and its relationship set — not an isolated ticket subject line or a single CRM stage field.

04 · Return

Emit a schema-validated task brief as JSON

The product output is a checked packet: strongest examples, path weights or ranks, confidence, caveats, missing data, and ordered next-task options for a stated goal.

  • JSON is validated against an agreed schema before it crosses any model or workflow boundary.
  • Each recommendation is expected to carry enough provenance that a human can ask “why this?” and land on source-backed path evidence, not a free-form story.
  • The packet is purpose-scoped to the question asked (for example: convert this enquiry, reduce churn risk on this account, stabilise this exception). It is not a dump of the entire relationship store.

Technical note. The model does not receive the source database. It receives a bounded, audited brief. That boundary is intentional.

05 · Explain

Hand the brief to an approved model, workflow, or human owner

Explanation is translation, not invention. The consumer — model or person — turns the structured brief into language, tickets, or actions. It does not invent the route from scrap text.

  • Approved model boundaries (internal model, gateway, or customer-approved adapter) may explain the packet in plain language for the operator.
  • Human teams can consume the same JSON in a console, queue, or existing workflow without calling a model at all.
  • When outcomes are reviewed and approved, they feed the path store so future matches improve. That closes the loop without changing the five-step mechanism.

Technical note. Elite packages this handoff for leadership review: discovery, synthetic demo, pilot scope, packet boundary, and outcome rhythm — still the same process, made reviewable.

Architecture diagram · end-to-end data flow

Production visual direction: horizontal swimlane on dark field; monospaced stage labels; copper connectors; no vendor mascots. Customer-estate boundary drawn as a continuous dashed frame around Load → Store → Match → Return. Explain sits on the boundary edge.

Sources

  • CRM
  • Email
  • Tickets
  • Billing
  • Usage
  • Web
  • Outcomes

Load

  • Authorised items
  • Identity hooks
  • Purpose scope

Store

  • Attribution path
  • Provenance
  • Relationship facts

Match

  • Path weights
  • Similar sets
  • Known outcomes

Return

  • Schema JSON
  • Examples
  • Tasks + caveats

Explain

  • Model boundary
  • Human workflow
  • Outcome feedback

Control rule: raw source systems stay put. Paths and packets move. Models receive packets, not databases.

Operating principles

Rules the mechanism is built to obey

These are not marketing slogans. They constrain how data is stored, compared, and handed off.

Data sovereignty

Operational records, connector credentials, and historical paths stay in a customer-controlled data plane by default. KynticAI product operations cover accounts, licensing, updates, support, and aggregate commercial metadata — not ownership of the customer’s operational state.

Visual direction

Attribution paths

The atomic unit of memory is the ordered trail for an object: what happened, when, linked to which identity, and which source proved each hop. Without order and provenance, relationship intelligence collapses into disconnected fields.

Visual direction

Freshness vs source reliability

A recent weak signal is not automatically more important than an older high-reliability source. Paths carry both recency and source trust so matching and task ranking can prefer durable evidence over noisy last-touch events.

Visual direction

Relationship comparison

Comparison is path-to-path and set-to-set: similar sequences, similar linked objects, similar commercial or operational patterns, differentiated by known outcomes. It is algorithmic traversal and weighting of relationship structure — not retrieval of the nearest paragraph.

Visual direction

Structured JSON output

Everything that crosses the model or workflow boundary is schema-validated: examples, caveats, confidence, missing data, and ranked tasks. Prose explanation is optional and subordinate to the packet. The brief is auditable; free generation is not the control plane.

Visual direction

Implementation layers

Scout, Fortress, and Elite are layers of the same system

They are not three different products with three different logics. They deepen deployment, scale, privacy, and leadership review around one process.

Implementation stack · same process, increasing operating depth

Elite

Operating model: discovery, demo, pilot scope, leadership review

Fortress

Private runtime: connectors, Rust path weights, LanceDB path store

Scout

Proof runtime: PostgreSQL/pgvector paths, inspectable JSON packet

Shared core: Load → Store → Match → Return → Explain

Proof layer

Scout

Free · open source

Run the same mechanism locally at proof scale. Load authorised items, store attribution paths on PostgreSQL/pgvector, produce a checked JSON packet, and let engineers inspect the shape before any commercial commitment.

  • Developer validation and first-source pilots
  • Lower-load paths where inspectability matters more than peak concurrency
  • Clear upgrade criteria when path volume or performance needs Fortress
Open Scout →

Private runtime layer

Fortress

Enterprise · private

Same process, private enterprise depth: connectors under your control, Rust path-weight analysis, LanceDB-backed path storage, and deployment inside the boundary your security team accepts.

  • High-volume path matching and concurrent traversal
  • Sovereign deployment with customer-owned operational state
  • Schema-validated packets to your approved model boundary
Open Fortress →

Operating model layer

Elite

Leadership path

Still the same system. Elite adds the commercial and review path around it: discovery, synthetic demonstration, Fortress pilot scope, strict packet boundary for leadership, and an outcome-review rhythm executives can follow.

  • Buyer rooms that need the full operating story in one sitting
  • Scoped pilots with explicit success criteria
  • Walkthroughs that keep model use subordinate to evidence
Open Elite →

Output use

How the brief is used — without inventing the plan

The packet is the control surface. Models and people are consumers of that surface.

Approved models

The model receives the schema-validated packet and may translate it into operator language, ticket text, or a short rationale. It is not free to invent the plan from unscoped estate text. If the packet is incomplete, caveats and missing-data fields travel with the answer.

Human teams

The same JSON can drive a queue, console, or existing workflow. Operators see ranked tasks, supporting examples, and provenance without requiring a generative step. Review remains human where policy demands it.

Outcome loop

When a task result is approved (won, lost, saved, escalated, resolved), that outcome attaches to the path. Future matches gain sharper weights. The five-step process does not change; the memory compounds.

Boundary. The model explains the brief. It does not invent the route from unscoped text. If your organisation does not want a model in the path, the same JSON still stands for human review.

Related pages

This page explains the mechanism. Use the links below only when you need problem context, product depth, or proof boundaries — not a second process story.

The problemContext EngineProof boundariesPlatform architecture

Visual production notes are embedded above as diagram specifications so design and engineering share one technical, high-trust direction: dark process fields, copper structure lines, monospaced labels, no sales theatre graphics.