ROI
The intelligence layer your AI estate is missing.
grāmatr℠ is the reasoning infrastructure that runs before every model your teams touch. Five functions on every request: classification, context delivery, governance, cost attribution, and compounding intelligence. Context delivery is the core: the right organizational context assembled for this specific request, just in time — so the model returns a better answer for fewer tokens. Every output is gated against typed quality criteria, every PASS/FAIL recorded with evidence that compounds. Governance is one of the five. The productivity floor moves and stays — and procurement, legal, and audit get the verifiable record they have been asking for.
The spending is climbing. The ROI is not.
AI spending is up 44% year over year. Forrester projects 25% of that spending will be deferred — because fewer than one-third of enterprises can link their AI investments to tangible financial growth.
That is not a technology problem. It is a context-engineering problem.
Every AI request your teams run starts cold. No record of what worked yesterday. No knowledge of what another team figured out last week. No verifiable trail that any output ever met the quality bar. Just isolated, expensive interactions — repeated across hundreds of seats, with nothing compounding and nothing auditable.
Better answers for fewer tokens. Every one measured.
The thing that flips an AI vendor evaluation from skeptical to signed is not a feature list. It is whether the CFO can see a number, the CIO can show a record, and the General Counsel can answer a question. grāmatr answers all three from the same architecture — the five functions it runs before every model call: classification, context delivery, governance, cost attribution, and compounding intelligence. Context delivery is the heart of the cost story: the right context delivered at the right moment means the model returns a better answer for fewer tokens — not a compression trick, a precision improvement. Concretely: 150K context-loaded tokens on a mid-tier model can beat 1M ungoverned tokens on a frontier model — illustrative, pending your own baseline, but that is the shape of the saving. Cost attribution tracks every token to its session and operator as it runs. The savings are computed on every request and exposed as an audited number your CFO can put on a slide.
Typed quality gates — the audit record that compounds
This is grāmatr's fifth function — compounding intelligence — made auditable. Before any request runs, grāmatr sets the quality criteria the output must satisfy — not as suggestions, as typed gate definitions with specific, evaluable standards. The output either meets each criterion or it does not ship. Every PASS or FAIL is recorded with an evidence artifact — a file path and line number, a command output, a diff snippet. That recorded ledger is two things at once: the answer to 'how do we know the AI did acceptable work?' in a format your audit team can query, export, and present — and the training signal that sharpens the next classification. The audit record is not a byproduct; it is what compounds.
Token economics as a verifiable per-request metric
Each turn through the Loop costs measurably less than an equivalent cold-start request — redundant context, discernment overhead, and retry cycles are removed before the model runs. The savings are computed on every request, the same way every time, and exposed as an audited number your CFO can put in a budget review. For the mechanism behind the reduction, see /how-it-works. The number on your invoice is real, per-request, and verifiable — not a marketing claim.
Compliance treated as code, not as a binder
Every governance policy, every control mapping, every evidence link in your grāmatr deployment lives in a versioned, reviewed, audited artifact. Compliance status is a git history, not a PDF. Your SOC 2 evidence pack exists in the repository, updated continuously.
Illustrative, pending your baseline: 1M ungoverned tokens on Opus cannot match 150K context-loaded tokens on Sonnet with grāmatr — not because the task was simpler, but because grāmatr loaded the context the operator would not have thought to provide. Fewer tokens, a cheaper model, a better outcome. The exact figure on your invoice is computed per request against your own usage; this contrast shows the shape of the saving, not a contractual number.
Defensible math your CFO will actually run.
For an enterprise running ten teams of eight practitioners at a blended professional-services rate of $200/hour, a 2× sustained throughput floor across 80 AI-augmented seats is on the order of $24–48 million per year in recovered billable capacity. Not a one-time productivity win. An ongoing operating-cost shift, computed against your team's actual baseline. Reviews compound. Conventions persist. New hires onboard at week one with the same context the team built over months.
The budgetable range is a 1.5× to 3× sustained throughput multiplier for a disciplined team running the full Loop — throughput here means completed, quality-gated work delivered per seat, quantified against engineering output; applying it to legal, research, or operations is a projection on the same mechanism. The multiplier is conservative by design: it is bracketed by the pre-Loop build phase and held well below the ceiling a fully disciplined operator can sustain. One input stated plainly, not hidden: the illustrative figure assumes 100% of the seat's billable hours are AI-augmented; at 50%, it halves. Scale it by your team's actual AI-augmented share — the number moves linearly. Methodology and derivation are on /proof for due diligence review.
| Input | Value |
|---|---|
| Teams | 10 |
| Practitioners per team | 8 |
| AI-augmented seats | 80 |
| Blended rate | $200 / hour |
| Sustained throughput multiplier | 2× |
| Recovered billable capacity | $24–48M / year |
Ongoing operating-cost shift, not a one-time win — computed against your team's actual baseline. Budgetable range is 1.5×–3×; this example uses a 2× floor.
You control what propagates. The architecture makes it enforceable.
The question every CISO asks: "Who controls what behavior, at what level, across our organization?" grāmatr answers it with a five-level governance hierarchy enforced at the database level — not at the application layer.
System level
Global skills, standards, and agent definitions are maintained by grāmatr and versioned independently. Row-level security at the database level, encryption at rest, full isolation between tenants by architecture — not by application-layer filtering.
Enterprise level
Enterprise administrators control organizational directives — policies, compliance rules, and cross-team standards. Visibility into what was promoted, when, and by whose authorization. Every governance event is logged.
Team level
Team administrators decide what propagates across the team and what stays scoped. Coding conventions, project terminology, workflow patterns, composable agents — governed at the team boundary, with audit history.
User level
Each user's preferences, decisions, and corrections stay scoped to them by default — isolated by row-level security at the database layer, with all interaction data encrypted at rest. Promotion to team or enterprise scope requires explicit authorization.
Project level
Intelligence scoped to specific projects — decisions, milestones, and context that belong to a codebase or initiative, not an individual. When the project moves teams, the intelligence moves with it under the same governance.
Cross-tier promotion of any directive, convention, or capability requires explicit authorization at the user, team, and enterprise levels. Nothing propagates automatically. Every event is logged, auditable, and reversible.
Security is not a feature. It is the architecture.
Row-level security
Every query is scoped to its authenticated user via per-transaction session variables enforced by Postgres row-level security at the database layer. Isolation is at the row granularity — a misconfigured service cannot leak another user's data because the database itself refuses to return it. The integrity check sits below your application code, not on top of it.
Encrypted at rest with row-level isolation
All interaction data is encrypted at rest at the storage layer, with row-level isolation across both the vector and object databases. Cross-user access requires explicit database authorization — enforced at the storage layer. The architecture eliminates an entire class of leak conditions: a misconfigured application can't expose what the database won't return.
Single Sign-On (SSO) Roadmap
OIDC / JWT integration planned. Your identity provider, your access rules. Targeted for the enterprise tier launch.
On-premises deployment Sep 1, 2026
Run grāmatr entirely within your infrastructure. Your data never leaves your network. Committed availability: September 1, 2026 — licensing and install path ready by then.
Bring Your Own Keys Roadmap
Use your own KMS-managed encryption keys. Full key-management integration planned.
Data residency Private cloud / on-prem
EU, UK, and country-scoped deployments run on private cloud or on-premises — infrastructure you control. Committed September 1, 2026, in line with the on-premises availability date.
Roadmap items are flagged honestly. Architecture was designed from day one to support them; formal availability ships with the enterprise tier. We will not claim what we have not delivered.
Where we stand today. Where we are headed.
Every control documented. Every evidence link version-controlled. Every policy change reviewed. The full compliance program is a working repository — available for enterprise due diligence under NDA, not a marketing PDF assembled the night before. We are transparent about where we are in the certification process, and we will not claim certifications we do not hold.
SOC 2 Type I
Targeting October 15, 2026Compliance program runs out of the gramatr/soc2-coordination repository — every control mapping, every evidence link, every policy version-controlled and tracked through pull requests since the program's first commit. The architecture was designed to meet SOC 2 controls from day one. We are targeting Type I audit completion on October 15, 2026.
SOC 2 Type II
Targeting April 15, 2027Type II requires a defined observation period after the controls are in operation. Data collection begins following Type I completion. We are targeting Type II audit completion on April 15, 2027. Current compliance status and evidence pack available for enterprise due diligence under NDA — maintained continuously as code.
HIPAA
Architecture alignedArchitecture is designed to support BAA-covered workloads. PHI-covered workloads run on private cloud or on-premises only; the deploying organization or implementation partner executes the BAA. grāmatr does not process PHI on its cloud infrastructure and is never a party to the BAA. For healthcare prospects, current status and target dates available under NDA.
GDPR / CCPA
Aligned todaySee the Privacy Policy for our lawful bases for processing, data-subject rights, retention, and the standard contractual clauses we rely on for international transfers.
Data residency
RoadmapRegional deployment for jurisdictional requirements. Roadmap commitment; architecture is in place. Talk to us about your specific requirements.
One intelligence layer. Every AI tool your teams use.
Your organization does not use just one AI tool. The intelligence layer should not be tied to any of them.
grāmatr delivers the same classification, the same context, the same cost attribution, and the same organizational intelligence — whether your team is working in Claude, ChatGPT, Gemini, Cursor, Codex, VS Code, or any platform that supports the Model Context Protocol. The Loop is fully portable across the model layer.
When a Frontier vendor releases a model tomorrow that is better for a particular workload, your team uses it — and the context delivery, the audit trail, the policy enforcement, and the compounding institutional intelligence travel with them. No vendor lock-in on the model layer. No per-tool configuration. No context loss between platforms.
Institutional capability that gets sharper with use.
grāmatr does not just carry existing knowledge forward. The flywheel detects patterns across your organization and surfaces them for review.
When multiple teams independently develop similar workflows, the system identifies the pattern and recommends formalizing it into a shared, governed capability — available across the org under your existing approval process. One team's hard-won efficiency becomes the organization's baseline, with the audit trail showing exactly which inputs informed the new capability.
The longer your organization runs the Loop, the more it identifies, the more it recommends, and the more verifiable signal feeds back into the classifier. AI investment that gets measurably sharper with use — not because you bought more seats, because the mechanism compounds.
Procurement-grade questions, direct answers.
What compliance certifications does grāmatr have today?
We have an active SOC 2 program with fully integrated and automated documentation, targeting Type I completion on October 15, 2026, and Type II on April 15, 2027 following the required observation period. HIPAA architecture is aligned; formal attestation on the roadmap. GDPR and CCPA: aligned today, see the Privacy Policy for lawful bases and rights. We will not claim certifications we do not hold; current compliance status and evidence pack are available under NDA.
Can we deploy on-premises?
On-premises deployment has a committed availability date of September 1, 2026 — licensing and install path ready by then. The full Loop runs within your network. If on-prem is a requirement, talk to us about scoping your environment ahead of availability.
How does grāmatr handle data residency requirements?
Data residency is on the roadmap. The architecture is designed to support regional deployment — EU, UK, country-scoped, or your own infrastructure. Talk to us about your specific jurisdiction and timeline.
What happens to our data if we cancel?
Your data is yours. Upon cancellation, you receive a full export of your organization's data — intelligence configurations, skill definitions, governance records, and audit logs. After export confirmation, all raw data is permanently deleted from grāmatr systems within 30 days. A certificate of deletion is available on request. Aggregated model improvements derived during your active subscription are retained as grāmatr IP and are not reversed; deletion is prospective.
How does pricing work for enterprise?
Enterprise pricing is based on your organization's size, deployment tier (multi-tenant cloud, private cloud, on-premises, or air-gapped), and support requirements. Every enterprise's needs are different. Talk to our team and we will scope a plan that matches your requirements — typically within one conversation.
What does integration actually involve?
For teams using MCP-compatible tools (Claude Code, Cursor, ChatGPT, Gemini, VS Code): one baseURL change in your AI tool configuration. No rip-and-replace. No new infrastructure to provision. The Loop runs within your existing AI workflow — production-ready in hours, not a six-month implementation project. For platform integrations (SaaS, enterprise applications): a standard REST API with API key authentication. You POST a request, you receive a classified intelligence packet. The integration surface is intentionally small. How the Loop works →
Can we audit individual outputs?
Yes. Every output passes through typed quality gates set before the request runs; each gate produces a PASS or FAIL with evidence. The gate log is queryable per-user, per-team, per-project, and per-time-range. The typical use case is for compliance review or post-incident investigation; the system supports it natively.
Better outcomes. Lower token cost. Every session on the record.
If your organization is spending on AI tools and struggling to show ROI — or your procurement and audit functions cannot yet sign off on how your teams are using them — we should talk.
Want to dig deeper first? See the public timeline and methodology, how the Loop works, the governance architecture, the security posture, or partner-assisted deployment.