01 / AUTHORITATIVE
Live Data Systems
Databases, SaaS platforms, documents, change feeds, credentials, and source ownership keep operational facts current.
Multi-domain expansion · assessed separately
Operational Context Mesh
An Operational Context Mesh connects independently owned business domains through a governed query layer. Live source systems stay authoritative, each domain publishes a permissioned Context Pack, workflows act on approved context, and the Unified Context Layer searches only what the verified person or service is allowed to use.
The four-layer operating model
This model separates where information is authoritative, how a domain publishes usable context, where actions happen, and how permitted context is discovered across domains.
02 / DOMAIN-OWNED
Context Packs
Versioned, independently owned data products define schema, retrieval, lineage, quality, permissions, freshness, and retention.
03 / ACTION
Workflows
Governed agents, human reviews, delivery steps, and approved external actions use bounded context without becoming the source of truth.
04 / ACCESS
Unified Context Layer
Identity, permission-first routing, entity resolution, cross-pack retrieval, ranking, provenance, cited answers, REST, and MCP access.
Domains remain independent
Sales, Support, Finance, and Operations can keep different systems, owners, definitions, refresh rules, and access policies. A Context Pack is the governed contract for one domain—not a request to flatten every source into a shared schema.
Source systems remain authoritative
Croox records the exact approved source, schema, policy, and snapshot versions. A pack never silently replaces its source.
Published versions are explicit
Changed sources or policies create a new version. A failed refresh preserves the last good snapshot instead of exposing a partial update.
Entities cross domains by review
Exact source identities can be linked to a canonical customer or project. Confidence-ranked suggestions require human approval before they merge evidence.
Evidence stays attributable
Results carry safe excerpts, timestamps, freshness, source type, and access-gated citations so a user can inspect the supporting provenance.
Hybrid freshness: materialized and federated
Materialized packs
Replay-safe scheduled or incremental refreshes create immutable snapshots and indexes when the approved retention, deletion, legal-hold, and residency policy permits storage.
Federated packs
Policy-filtered live retrieval queries the provider using the correct provider identity. Provider content remains ephemeral and is not retained in a durable shared cache.
Every result reports whether its evidence is complete, partial, or stale. If a live provider is unavailable, Croox does not present an old or incomplete result as current.
Permission-first means denial happens before retrieval
Effective access is the intersection of the provider credential and scopes, reliable source-item access controls, and Croox policies for organization, environment, pack, purpose, operation, field, and row. Those constraints are resolved before an adapter or index is invoked.
Client owners can administer grants without receiving implicit access to every pack. Interactive workflows use the intersection of the caller's grant and the released workflow's grant; scheduled work uses an exact scoped service identity.
One query, bounded evidence
- Verify. Resolve the principal, organization, environment, purpose, and current grants.
- Select. Consider only authorized, published Context Packs.
- Resolve. Use approved canonical entities and source aliases.
- Retrieve. Route to materialized snapshots or federated providers with field and row constraints already applied.
- Rank. Normalize, fuse, and deduplicate evidence by canonical entity and source identity.
- Return. Produce a bounded context envelope with freshness and provenance.
- Synthesize only when approved. An exact client-approved model profile may create a cited answer. If citation validation fails, the evidence envelope is returned without an answer.
Retrieved content is untrusted data. It cannot become an agent instruction simply because it appeared in a document, email, message, or search result.
Retrieval and action stay separate
The Operational Context Mesh is a read-only context boundary. Workflows can use its evidence to prepare a recommendation, route a review, or assemble a delivery. External writes remain separately authorized workflow actions through reviewed action adapters, with their own credentials, approval rules, and audit evidence.
Deployment follows the client boundary
Isolated design-partner stack
An approved design partner may begin on a separately keyed, stored, cached, indexed, and worked stack on managed Hostinger infrastructure.
Managed OCI data plane
A production client can move to a dedicated Croox-managed OCI environment with separate encryption keys, data stores, workers, quotas, backups, and health evidence.
Client private VPS or VPC
Where policy requires it, the data plane can run in an approved client-controlled private VPS or VPC while Croox retains the governed control-plane contract.
Verified migration
Migration pauses sync and query, verifies a signed encrypted export, restores and tests isolation, then atomically rebinds the environment with a read-only rollback target.
Why this is not one giant AI database
Centralizing every record would erase the ownership, permissions, freshness, and source semantics that make operational information trustworthy. The Mesh keeps the domains separate and makes only their approved Context Packs discoverable through a shared access contract. Croox can combine authorized evidence without pretending every user, workflow, or model should see the same data.
Scope, price, and availability gate
One-domain Context Foundations start at $25,000. An Operational Context Mesh is the multi-domain expansion: source packages, policies, isolation, migration, query surfaces, and live acceptance requirements are assessed and separately scoped.
Candidate packages for the initial reviewed B2B source stack are PostgreSQL, Google Drive, Gmail, Slack, HubSpot, and Stripe. Provider-specific acceptance gates must pass before any package is offered for a production scope. Croox does not treat a generic connector or a mocked test as proof of live isolation.
This is not the first purchase for most teams. Croox normally begins with one measurable workflow; a one-domain Foundation or multi-domain Mesh follows only when the operating evidence justifies the larger boundary.
Operational Context Mesh questions
Is this one giant AI database?
No. Source systems remain authoritative and each domain keeps an independently owned Context Pack. The Unified Context Layer searches only the packs and fields allowed for the verified principal and declared purpose.
Does every source get copied into Croox?
No. Materialized packs use governed snapshots when storage is approved. Federated packs retrieve live evidence without retaining provider content. The mode is part of the published pack policy.
Can the Mesh write back to a source system?
Not through context query. External writes remain separately authorized workflow actions with distinct adapters, credentials, approval rules, and audit evidence.
How does this relate to Context Intelligence and a Context Foundation?
Context Intelligence defines what reliable action needs. A one-domain Context Foundation establishes governed context for one business domain. The Mesh connects several independently owned Context Packs through one permission-first access layer.
Is Operational Context Mesh a standard package?
No. Multi-domain work is assessed and separately scoped. Provider packages and the target data plane must pass their applicable security, isolation, restore, freshness, and live-provider acceptance gates.