The Foundation Partner program
The floors are published. Foundation Partners lock the rate.
grāmatr is the intelligence layer in the AI request path, priced per application. Three published floors — one for each deployment tier — so a CFO can size the engagement from this page before a single call. grāmatr Cloud from $60,000 per application, per year. Private cloud and on-premises from $120,000. Air-gapped on-premises from $300,000.
These are the Foundation Partner floors: a limited founding cohort of enterprises who build on grāmatr now lock in at these rates and help shape the intelligence layer they deploy on. As SOC 2 certifies and each tier reaches general availability, the rates rise for those who come after. Foundation Partners keep the rate they locked. The exact number is scoped in a 45-minute review across four inputs — no checkout, no self-serve, but no black box: take these floors to your finance team today.
Three floors. One per deployment tier. Locked for the founding cohort.
Pricing scales with your security posture, not with seats or per-box licensing. Each floor is the Foundation Partner rate for its deployment tier — the entry point for a limited founding cohort of enterprises who build on grāmatr now. These rates rise for those who come after the foundation cohort, as SOC 2 certifies and each tier reaches general availability. Foundation Partners keep the rate they locked.
grāmatr Cloud
Multi-tenant, fully managed, row-level isolated. The fastest path to the full intelligence layer in production — classification, context delivery, and cost attribution running before your first sprint.
Private cloud & on-premises
Runs in your cloud account or inside your network perimeter. Your data residency, your security boundary.
Air-gapped on-premises
Zero external connectivity. The full five-function architecture — classification through compounding intelligence — inside a fully air-gapped perimeter.
Priced per application — not per seat, not per box.
An application on grāmatr is a single AI estate running the full five-function architecture under one attribution and audit trail. Anneal is one such application, in production today. The CPP financial-governance application, in active development, is a second. Each licenses against the Foundation Partner floor for the deployment tier it runs in — so the price you size is the price for the thing you are actually running.
A firm standardizing grāmatr across multiple applications — the pattern a Deloitte or a PwC follows when governance becomes the house standard — negotiates a single group volume agreement, not a stack of per-application licenses. The published floors size one application; a portfolio is a conversation about leverage, and the per-application number comes down with scale.
Every floor is a from — the exact number is scoped in the 45-minute architecture review across four inputs: deployment tier, session volume, governance configuration, and integration surface. The floor is what a CFO sizes internally today; the architecture review is what makes it precise.
Every tier. One architecture. No re-architecture when you move between them.
Your security posture determines where grāmatr runs. The five-function request path — classification, context delivery, governance, cost attribution, compounding intelligence — is identical across every tier. Deployment model is a configuration decision, not an architecture trade-off.
grāmatr Cloud
Multi-tenant. Fastest path to the full intelligence layer
grāmatr hosts and operates the full infrastructure layer. Multi-tenant by design — tenants isolated at the database row level, never commingled. All five functions run on grāmatr infrastructure before your AI estate sees a request: classification, context delivery, governance, cost attribution, and compounding intelligence. SOC 2 Type I targeting October 15, 2026.
Appropriate for organizations that need the intelligence layer in production immediately and are satisfied with grāmatr's data residency and security controls. Scoping determines session volume tiers and retention configuration.
Private Cloud
Your cloud account, your data residency
The grāmatr infrastructure layer runs in your cloud environment. Your cloud account. Your data residency controls. Your security boundary. grāmatr manages the infrastructure and classification layer; your team controls the environment it runs in.
Appropriate for organizations with strict data residency requirements that are not satisfied by shared cloud tenancy, but do not require full on-premises operation. Session data does not transit grāmatr's environment at any point.
On-Premises & Air-Gapped
Full network perimeter — up to fully air-gapped
The full grāmatr architecture runs within your network — or, when the posture demands it, fully air-gapped with no external connectivity at all. No external data transit. No external dependencies in the request path. Financial services, healthcare, government, and defense organizations with strict data sovereignty requirements deploy this model.
On-premises (connected) has a committed availability date of September 1, 2026; the fully air-gapped variant has a committed availability date of January 1, 2027. Licensing and install path are ready by each date. The architecture conversation, scoped during the engagement, determines what "on-premises" means for your specific security posture and what the implementation scope includes.
Four variables determine what the engagement looks like.
No two enterprise deployments are identical. These four dimensions determine configuration complexity, session volume requirements, and what the implementation engagement includes. We map each against your organization in the scoping conversation.
Deployment model
grāmatr Cloud, private cloud, on-premises, or air-gapped on-premises. This is the first decision and it constrains everything downstream — data residency, SLA configuration, implementation timeline, and the engineering surface that scoping covers. If you do not yet know the answer, the scoping conversation surfaces it.
Session volume
How many requests per month does your AI estate route through grāmatr? Each request is classified, governed, and logged before the model responds. Volume determines infrastructure configuration and the classification layer's training surface. More volume means more organizational intelligence accumulated under the same audit trail.
Governance configuration
How many policy layers, approval workflows, and audit retention windows does your organization require? A regulated industry deployment with a General Counsel, a compliance function, and a board-level reporting requirement has a different governance configuration than a technology organization with a single policy owner. Both are fully supported. The configuration determines the implementation scope.
Integration surface
How many model endpoints, internal applications, and team deployments does grāmatr run before? A single-team deployment testing the architecture is a different integration scope than an enterprise-wide rollout across multiple model providers and dozens of applications. The integration surface determines what the implementation engagement includes and how long it takes to reach the production request path.
Five functions. All five. In the request path. Every time.
grāmatr is not a modular stack where governance is an add-on and attribution is a premium tier. The five-function architecture runs as a single unit — classification, context delivery, governance, cost attribution, and compounding intelligence — in every deployment, on every request, before the model responds. No pillar is optional. No pillar is an upgrade.
Classification
Intent classified before anything loads. Patent-pending architecture. Every request is triaged before context assembly begins. Classification determines what the request needs — not after the fact, in the request path.
Context delivery
The right organizational context assembled for this specific request. Not everything your organization knows. What this request needs, at the moment it needs it, based on classification output.
Governance
Policy evaluated before the model responds — not as a review layer after. Policy is enforced and context delivered in the request path, every call classified and attributed; the output is logged and accounted for, never unattributed.
Cost attribution
Every session attributed to its actor at the moment it happens. Not aggregated after the fact. The attribution record exists at the time the session runs — which means the CFO can run the number at any time and it is accurate.
Compounding intelligence
Every routed request trains the classification architecture. The system gets more accurate with use — not because it fine-tunes a model, but because the classifier learns organizational patterns. The longer it runs, the more precisely it routes.
Real applications run on grāmatr.
Memories assembled and delivered in production. 38,000+ classifications. 56,000+ learnings. 128,000+ knowledge graph entities. 20,000+ relationships. Real applications, real load.
Real applications run on grāmatr in production — Anneal first, the CPP (Covington Place Partners) financial-governance application in active development as the second. Every session and outcome runs through the same five-function architecture being sold here. The full production record is on the proof page.
This is not a testimonial. It is a production record. The same classification architecture that runs your requests runs the applications already on the platform. The audit trail you are evaluating exists for those applications before it exists for yours.
When we tell you grāmatr adds sub-100ms latency, fails open, and logs every session with RLS isolation — those are specifications we operate against, not claims from a spec sheet.
Three steps from this page to a proposal.
Enterprise infrastructure is not self-serve. The scoping conversation is not a sales call. It is the mechanism through which we determine whether grāmatr is the right fit for your organization, what the deployment looks like, and what the engagement costs.
Scoping conversation
45 minutes. We map four inputs: deployment model, session volume, configuration scope, and integration surface. You learn how classification, context delivery, and cost attribution run in your specific request path. We determine whether the engagement is the right fit. No obligation past this call.
Architecture review
For organizations past the scoping call, we map the full request path against your existing AI estate — model endpoints, applications, teams, governance requirements, and data residency constraints. This is a technical engagement, not a pitch. The output is a documented architecture diagram showing exactly where grāmatr runs in your stack.
Scope-specific proposal
A proposal built against the four scope inputs — deployment model, session volume, governance configuration, integration surface. Not a rate card with a tier selected. A document that matches the architecture review output. Includes implementation timeline, SLA terms, and the governance audit trail your procurement and legal functions will ask for.
Book a scoping conversation.
45 minutes. Deployment model, session volume, context delivery scope, and cost attribution requirements. We determine the fit and return a proposal built against your specifics. No rate card. No checkout. No soft ask.