Architecture / Elite
The executive walkthrough path from Discovery MCP to Fortress scope.
The Elite architecture is a buyer journey: run Discovery MCP locally, approve a metadata-only Discovery Signature, review a synthetic equivalent demo, scope the Fortress pilot boundary, and discuss the included local/private open-source model route and outcome-review rhythm where approved.
Core layers
How Elite is structured
01
Local Discovery MCP
The buyer runs discovery in their own AI workspace and reviews the safe metadata categories before approving any handoff.
02
Metadata-only signature
The Discovery Signature captures source-system families, connector types, safe field categories, governance notes, and demo preference.
03
Synthetic equivalent demo
KynticAI builds a synthetic demo against equivalent connector families so the executive story feels specific while the customer-owned data boundary stays intact.
04
Open-source model route
The walkthrough shows how checked JSON can be explained by a customer-controlled open-source model where approved, avoiding hosted-model token costs.
05
Fortress and Elite route
The walkthrough clarifies whether the next commercial step is a scoped Fortress pilot or an Elite executive walkthrough where approved.
Operating flow
The request path through the product
Inject
Systems stay where they are
SQL, CRM, ERP, SharePoint, email engagement, cookies, web events, support, billing, usage, and outcome systems remain under customer control.
Store
Relationships gain attribution
Scout stores each item in PostgreSQL/pgvector for inspectable proof. Fortress uses the Rust/LanceDB runtime when the relationship memory needs high-load enterprise relationship traversal.
Explain
The right model gets JSON, not data sprawl
Fortress feeds the customer's approved model endpoint; the Elite path can show how local/private open-source model routing would fit where approved.
Example signal path
A metadata-only Discovery Signature becomes an executive walkthrough
Illustrative synthetic sample only. Elite scope is approved per engagement; customer operational data stays in the customer environment by default.
01 / Source
Example fields
targetWorkflow = support triage
sourceSystemFamilies = support + product usage + billing metadata
approvedForSyntheticDemoBuild = true
02 / Evidence
What KynticAI creates
syntheticDomain = professional-services
demoConnectors = equivalent connector families
fortressPilotBoundary = workflow + governance + model route
03 / Action
What the business does
review synthetic demo
scope Fortress pilot
discuss open-source model route
Operating model
How the product stays useful at enterprise scale
Identity
Access follows enterprise roles
Fortress patterns align evidence access with customer identity, role boundaries, and local administration.
Audit
The source trail stays visible
Governance control surfaces and export paths focus on what was read, why it was used, and which policy applied.
Sovereignty
Customer data plane owns operational data
KynticAI can manage licences, support, updates, and aggregate posture while the customer data plane owns operational data.
Integration points
Where it connects to the wider stack
Scout
Free open source
Scout proves the Context Engine data-plane mechanics with source registration, selectors, snapshots, relationship facts, PostgreSQL/pgpath-weight storage, JSON output, and APIs before enterprise deployment.
Enterprise
Rust/LanceDB engine
Enterprise adds the proprietary Rust relationship, weighting, traversal, and LanceDB outcome path matching engine plus private runtime controls and sovereign storage patterns.
Operate
KynticAI operations layer
KynticAI manages commercial metadata, licences, downloads, support, aggregate posture, and updates without raw customer records.