# zaimler — Full Content > Full Markdown content of all public pages on https://zaimler.ai. > Navigation, headers, footers, and other UI chrome are excluded — content only. --- # Home URL: https://zaimler.ai/ Last updated: 2026-08-07 ## Unified business context for your agents zaimler is the enterprise context layer that makes AI agents reliable for industries where accuracy, continuity, and security aren't optional. ### Ensure your agents avoid mistakes - Get a holistic ontology of your business - Map how your data across systems is related - Understand where data conflicts across silos ### Provide your AI with data that's current - Provide agents context at runtime - Avoid stale snapshots - Minimize answer latency ### Ensure data coverage - Bring in every cloud and data source - Unify each source into a common data model - Give your agents the full context ### Guarantee data stays in your walls - Your data never leaves your environment - Keep your ontology away from vendors - Get audits at the access layer ## Built for enterprises where deterministic outcomes are non-negotiable ### INSURANCE - Pay out only on real policy, claim, and insured links, never hallucinated - Decide with the whole account across claims, underwriting, billing, and your CRM - Settle a claim's full context in minutes - Audit every decision while your underwriting data stays inside your walls ### ASSET MANAGEMENT - Grounds every answer in your real holdings, mandates, and allocation history - Reasons across portfolio, client, market, and risk as one book - Answers on today's live positions and exposures - Keeps your data and your edge inside your environment ### BANKING - Alerts on real entity links between accounts and transactions - Joins core banking, transactions, KYC, and risk into one case - Screens every transaction live and in full context - Clears model-risk review with every decision audited and access-controlled ### HEALTHCARE - Care decisions grounded in real patient, diagnosis, and claim links - Patient context unified across EHR, claims, and operations - Prior authorization resolved at the speed of care - PHI kept in your environment, HIPAA-defensible by design ### TELCO - Acts on the real links between customer, plan, device, and network - Sees the whole subscriber across billing, CRM, network, and support - Resolves the issue live, while the customer is still on the line - Scales automation on data that never leaves your environment ### LOGISTICS - Agents that reason over the live network, every shipment, asset, and route - Reasoning that spans fleet, freight, maintenance, and scheduling as one operation - Routing that adapts the moment a delay or exception hits the network - Decisions that stay auditable, on data you never cede to a vendor --- # About URL: https://zaimler.ai/about Last updated: 2026-07-30 ## We build the context your agents run on Built by data & ML leaders from Meta, Visa, LinkedIn, Apple, and Branch Metrics - zaimler builds your context layer automatically, across all data sources, and keeps it yours. ## Built by the pioneers of enterprise data and knowledge systems The team behind knowledge graphs, data federation, and semantic platforms at LinkedIn, Meta, Snowflake, Apple, and Visa. Now building the context layer that gives enterprise data meaning. ## Our story For twenty years we were the person who knew what the data meant. We built zaimler so your agents can have that person built in. ### We were the data people Every data system we built at Visa, LinkedIn, and Branch Metrics ran on the same unwritten dependency: a person who knew that "policy" joins to "claim" through a table nobody documented, and that "customer" means three different things in three different systems. When an answer had to be right, someone walked over to that person. For most of our careers, we were that person. And we met at Branch Metrics. ### We saw this coming We saw it again and again. Every company, every ML system, hit the same gap: models that worked in testing degraded in production. What starved them was the business context around them, thin and stale and barely curated. So teams kept fixing it by hand, building one more version of the same data curation layer. Then agents showed up, and the gap got worse. ### We proved it before talking We built the company the way our buyers evaluate software: prove it first, then talk. Engineers put the product into design partners' environments in 2025; by winter a Fortune-scale customer was paying for it. We were SOC 2 certified before we had a website worth visiting, because in regulated industries that is the right order. ## Our Offices Headquartered in *San Mateo*, with engineering in *Bangalore* and teams in *New York and Texas*. --- # Careers URL: https://zaimler.ai/careers Last updated: 2026-08-06 ## Build the context layer for enterprise agents zaimler is the context layer for production agents. We build an ontology automatically from the data an enterprise already has, federate it across every warehouse and app, and resolve it at query time, so agents reason on what's true, not what's similar ## Meet the team Engineers and researchers from Meta, LinkedIn, Apple, Snowflake, and Atlassian, across San Mateo, New York, Texas, and Bangalore. ### Biswajit Das — Co-Founder & CEO Co-founder and CEO of zaimler. Previously VP of Engineering at Truera through its Snowflake acquisition, founding Chief Architect of Visa's AI Platform, and lead of Data Platform and Infrastructure at Branch Metrics through 0-to-100x growth. Expert in distributed systems, data platforms, and AI/ML infra. BE from NIT, India. ### Sofus Macskássy — Co-Founder & Chief Scientist Co-founder and Chief Scientist; owns zaimler's technical and scientific direction. He built LinkedIn's Knowledge Graph Foundation team and led Ranking & Search there, then ran data science at HackerRank and worked at Meta. zaimler's knowledge graph and semantic layer architecture comes from his research and production work. ### Ed Hernandez — Account Executive Founding AE at zaimler, helping shape GTM strategy with 15+ years of enterprise sales experience, most recently at Atlan supporting strategic Fortune 500 customers. He serves CDOs, CAIOs, and Heads of AI, helping take enterprise AI from pilot to production. He believes AI can be a real partner in the work that matters. ### Joe Lopez — Account Executive Joe is a founding GTM/AE at zaimler and brings a sales background spanning SAP, Oracle, Tableau, Neo4j, and AtScale. He has sold to the enterprise his entire career, with a focus on solutions based selling and solving real problems his customers face. AI has always intrigued him, and he's excited about how zaimler can change the game in how he helps his customers do amazing things. ### Colin Goyette — Forward Deployed Engineer Founding forward-deployed engineer at zaimler. He has spent the last ten years architecting and implementing AI and ML solutions in the enterprise, building on prior roles in enterprise IT and semiconductor manufacturing. He cuts through hype-cycle noise to produce real value from cutting-edge tech. ### Eric Wu — Forward Deployed Engineer Forward-deployed engineer at zaimler. After graduating from Carnegie Mellon, Eric spent over a decade in various product and engineering roles. Outside the office, you'll likely find him at the gym, playing Dota 2, or stacking coupons at his local grocery store. ### Ana Ordonez — Executive Assistant & Operations Supports the co-founders and manages scheduling, events, and business operations across zaimler. She previously spent six years at Apple, resolving high-priority executive escalations and leading projects with cross-functional teams. ### Caleb Burns — Talent & Operations Founding operator at zaimler, building the people and ops foundation. He also handles compliance, immigration, and business operations, and before that spent time at TruEra where he helped grow the team from 10 to 45, up until its acquisition. Outside of work he's a private pilot, distance runner, and proud dad. ### Jonathan Tom — MTS zaimler's first engineer, building from day one and touching most of the core platform. Previously a founding engineer at Hive and an early engineer at both Branch Metrics and TruEra. ### Viswadeep Veguru — MTS Deep brings years of building enterprise data platforms at Zuora, Cisco (DNA Center Foundation team), Anaplan, and Atlassian. One of the most experienced systems engineers on the team, he has shaped much of zaimler's infrastructure from the ground up. ### Weili Gu — MTS An engineer who loves solving hard distributed systems problems and making complicated things work at scale. She enjoys building reliable systems and debugging weird issues. Outside engineering she's into art, music, games, and animation, often thinking about databases and color composition at once. ### Aidan Lawford-Wickham — MTS Owns zaimler's query engine infrastructure and customer deployments. Previously worked on data infrastructure for AI/ML observability at TruEra (acquired by Snowflake). Holds a degree in engineering science from the University of Toronto. Outside work, he spends most of his time surfing. ### Jay Mishra — MTS A software engineer from the Bay Area, Jay went to UCLA and works on the data infrastructure team at zaimler. In his free time he likes bird watching, going to concerts, and trying new coffee shops. ### Kanishka Pratap Singh — MTS An engineer from India who speaks fluent Java, Go, and 'Soccer.' He's building pioneering tech at zaimler and trying not to break the build. Outside the office he's either framing the perfect shot or scoring goals, always after the best light and the cleanest code. ### Raj Yadav — MTS Founding Cloud Infrastructure Engineer on the Bangalore team, building resilient multi-cloud infrastructure from the ground up. He architects scalable systems across AWS, Azure, and GCP and manages GPU infrastructure for AI/ML workloads, focused on automation, reliability engineering, and performance at scale. ### Amer Alsabbagh — MTS Amer is an AI/ML engineer at zaimler, specializing in ontology, mapping, extraction, suggestions, and agentic workflows. In addition to his core AI/ML work, he contributes to data ingestion and query services, providing him with a broad understanding of the platform. His background in AI and natural language processing (NLP), combined with full-stack engineering experience, enables him to develop end-to-end intelligent systems. ### Mansi Rana — MTS Founding ML Engineer at zaimler, working on the multi-agent system that turns fragmented enterprise data into structured, AI-ready knowledge. She holds an economics degree from SRCC (University of Delhi) and a data science graduate degree from the University of Chicago. Previously on the research team at Uniphore. ### Sharvari Deshpande — MTS Senior AI/ML Engineer with a background in applied ML, computer vision, and generative AI. She has built AI-driven products across domains, focused on practical, impactful problems. At zaimler she works on AI and data initiatives that improve how users interact with information. Outside work she explores new tech trends. ### Padigender Reddy — MTS Software Engineer specializing in backend and distributed systems, building the data layers, storage, and infrastructure other teams ship on. Most recently at Snowflake, working on platforms for ML training and AI agent evaluations. At zaimler he builds systems that connect intelligent components into high-leverage platforms. ### Sachin Dabas — MTS Founding product designer at zaimler, with experience across multidisciplinary design studios and early-stage startups in the US, India, and Europe. He studied design at Carnegie Mellon University and IAAC, Barcelona. ### Mohit Palan — MTS Frontend engineer known for polished, user-first experiences with exceptional attention to detail. Previously at PayU Payments, he built products serving millions and earned multiple awards, including the Rising Star Award. He specializes in 0-to-1 products and leading high-impact initiatives. ### Arpit Soni — MTS Frontend Engineer with 8+ years building scalable, user-focused web applications at companies including Directi, Ola, and Walmart, across startups, mid-sized firms, and large enterprises. He has led a team of four engineers. At zaimler he works across the frontend, helping build and scale the user experience. ### Sarvesh Elanchezhian — MTS Intern ### Bhaskar Bikkina — MTS Intern ### Nikhita Kadam — MTS Intern ### Apurv Gude — MTS Intern ### Sricharan Ramesh — MTS Intern ### Ellis O'Dowd — MTS Intern ## Graphs in production, not papers. Our founders spent two decades on the problem we solve now: entity resolution at Visa and Branch, the skill graph at LinkedIn. That work is now knowledge graphs that resolve entities at runtime and run in production inside some of the largest institutions in the world. ## Teach enterprise AI how to work Small team, full ownership. ### Why this problem Every enterprise was promised agents. Most got pilots, because the agent never knew the business: what a claim is, how exposure rolls up, which "customer" is the real one. That knowledge lives in people's heads, and agents cannot ask a person. We build the layer that turns that knowledge into software. ### The problems you'd solve Ontology automation. Runtime graph traversal. Entity resolution at runtime. Federation, zero-copy. Governance in the access path. ### How we work No split between strategy and execution. You scope the problem and ship it. ### Who thrives here You've been the person the dashboard depended on, pulled into other teams' problems because you knew where the data was buried. Researchers who want their graph in production with real claims paying out against it, not sitting in a paper. GTM people who'd rather hand a chief architect the keys to break the platform than read them a pitch. ### Where we are San Mateo, with teammates in Bangalore, New York, and Texas. Join us If the open roles don't fit but the problem does, write to us anyway --- # Security URL: https://zaimler.ai/security Last updated: 2026-08-06 ## Your data, models, and context. Inside your walls. zaimler auto-infers live runtime context, entirely inside your perimeter. Zero egress. Governed by your enterprise identity controls ### Cloud-Native Deployment Self-contained and Kubernetes-native, deployed alongside your data ### Data Privacy by Design In a self-hosted deployment, no customer data transits zaimler-managed systems ### Full Tenant Isolation Tenant-resident: the whole platform, data and control, lives in your environment ### Runtime Access Governance Access is governed at the moment of retrieval. Every request, from a person in the console or an agent over MCP, clears role and attribute checks synced from your identity provider. Workspaces isolate departments, domains, and use cases inside a tenant, each with its own roles and data connections. Every create and update lands in an audit log. ### End-to-End Encryption AES-256 at rest, TLS in motion, Istio mTLS between every internal service ### On-Premise AI Models Self-hosted models, with no external model API calls ### Secrets Management Source credentials encrypted in the zaimler secret store, never exposed in transit, validated at every step ### Identity Federation SSO through Active Directory, LDAP, OIDC, or SAML, with SCIM provisioning ### Role-Based Access RBAC and ABAC, enforced with Keycloak and CEDAR, scoped to tenant or workspace ### Audit Trail Append-only audit log: every record carries the user and its origin, UI, API, or SDK, readable by tenant admins and exportable to CSV [ 03 · COMPLIANCE & SOVEREIGNTY ] ## Sovereign by design, certified by audit The platform is built to meet GDPR, HIPAA, and 23 NYCRR 500 requirements. Sovereignty is structural: because the deployment is self-contained, a regional deployment keeps the data, the models, and the ontology in that region. The attestation confirms what the architecture already enforces. - SOC 2 Type II, report shared under NDA - ISO 27001; GDPR, HIPAA, and 23 NYCRR 500 requirements - Residency follows the deployment itself - Full detail at [trust.zaimler.ai](https://trust.zaimler.ai) ### SOC 2 Type II Certified ### ISO 27001 Certified ### GDPR Certified ### HIPAA Certified ### 23 NYCRR 500 Certified ## FAQ ### What is zaimler? zaimler is the context layer for production agents. It builds the context AI agents need automatically, from the data an enterprise already has, and keeps it owned by the customer, so agents operate in production: accurate, real-time, complete, and governed. It runs today inside regulated enterprises, where a wrong answer is a mis-paid claim. ### Ontology automation Tools like Cortex Analyst rely on hand-written YAML semantic files you maintain yourself. zaimler's ontology is auto-inferred from your data with confidence scores, then validated by your team, in days rather than the quarters a hand-built model takes. All inputs and outputs are your intellectual property ### Your data, your IP. Always. Everything zaimler learns about your business belongs to you. In a self-hosted deployment, it never leaves your environment, and it’s never used to train models. --- # Explorer URL: https://zaimler.ai/product/explorer Last updated: 2026-08-03 ## Ask anything. Get answers you can trust Explorer walks your domain model and hands you an accurate answer, along with detailed explainability into how it was computed. WHY THIS EXISTS Most agents give you different answers to the same questions Explorer resolves one governed answer against your Unified Domain Model and shows the exact path it walked. HOW IT WORKS ## Ask, recognize, steer, save ### Ask in natural language Explorer shows the entity types, relations, and cypher it used, and returns the answer with PII masked. ### Recognize your vernacular Explorer checks your business knowledge first. Ask for "FPA" and it knows you mean Fraud Payment Analysis, the metric your team defined, and runs that definition. ### Steer it yourself Explorer ranks the entity types your question could use by confidence and pre-checks the top ones. ### Save and reuse Save any query straight from the run that produced it, as a query, a template, or a metric. WHAT EXPLORER DOES ## Reliable answers across all your data ### Certified Metrics Define a metric once, certify it with your data owners, and it returns the same value no matter who asks. ### Path & Lineage Every answer traces to the source rows behind it, with the exact path you can check. ### Graph Traverse Browse the model and walk the real relationships, across every source it touches. ### Multi-Surface Ask from the Console, API, or MCP. Same governed model, same access rules, same answer. ### Governance Each query clears your access rules first, and resolves against the model you own, inside your perimeter. ## FAQ ### Do I need to write SQL? No. Ask in plain language and Explorer resolves it against your model. Prefer code? The API returns the same answer, the same way. ### How do I know the answer is right? Every answer comes with the exact path it took, against a certified definition. You check the work instead of trusting it. ### What is a certified metric? A metric with one definition, signed off by your data owners, that returns the same value no matter who asks. ### Can execs use it, or just engineers? Anyone who asks a question about the business. Plain language in the browser, code over the API, same governed answer. ### How is this different from keyword or vector search? Keyword matches strings. Vector search returns lookalikes. Explorer resolves the actual entity and hands back the path it walked. ### Can agents get the same answers? Yes. Agents hit the same governed model over MCP and get the same certified answers, same path. --- # Governance URL: https://zaimler.ai/product/governance Last updated: 2026-08-07 ## Govern your AI estate Tag the data that matters, set the policy once, and watch every agent access it. WHY THIS EXISTS An agent on your core data is a new access path. Security asks the same three questions: who can it reach, what did it touch, where did the data go. zaimler governs where the data resolves, so every query clears your policy. HOW IT WORKS ## Tag, govern, watch ### Tag your sensitive data Pick the tags you govern, PII, SPII, PHI, and zaimler tracks them across every dataset they touch. ### Set a policy Write a policy once and attach it to the groups and roles it governs. Every query they run clears it first. ### Watch every access event See every access event on your governed data in the dashboard by tag, accessor, channel, and entity. THE CONTROLS ## Enforcement for your agents ### RBAC and ABAC Assign people to roles, then attach attribute-based policies. ### Policy Controls Column masking, export limits, retention rules. Each one a policy on the model, enforced where the data sits. ### Single Boundary The same policy governs an analyst today, and is built to govern an agent the moment it reaches the model over MCP. ### Audit Logs Keep a record of access to your governed data, alongside the dashboard. ### Identity & SSO Bring your own identity provider and SSO, so roles map to the directory you already run. ### Zero Egress Every query resolves inside your perimeter. No copy leaves your walls. ## FAQ Questions security asks ### How is this different from bolting a permissions layer onto our agent? A wrapper around the outside is a boundary an agent can route around. zaimler governs in the resolution path, so every query clears your policy before an entity resolves. ### What access-control model do you support? Role-based and attribute-based. Assign people to roles, then attach attribute-based policies (masking, export limits, retention) to the model, enforced where the data sits. ### How do you govern an agent's access? An agent reaches the model over MCP and clears the same policy as a person before an entity resolves. ### Can I see who accessed what? Yes. The dashboard measures access to your governed data by tag, accessor, and entity. ### Where does our data go? Nowhere. It resolves inside your perimeter, nothing copied out, no third-party model in the path. ### Are you certified? SOC 2 certified, ISO in process. Built to clear the CISO and procurement review before the first agent touches core data. --- # Ontology URL: https://zaimler.ai/product/ontology Last updated: 2026-08-06 ## Your business concepts. Automatically modeled zaimler reads across all data sources and automatically infers a Unified Domain Model. WHY THIS EXISTS With no model, your AI guesses An agent does not know that a policy joins to a claim through an undocumented table, or that the same customer in Salesforce and SAP is one company. A confident wrong guess can result in high costs and unhappy customers. HOW IT WORKS ## Suggest, understand, map, and trace ### Suggest the ontology zaimler proposes the entity types from your data, each with a confidence score. Accept them in bulk or one at a time. ### Understand the reasoning Every suggestion shows the top datasets and columns that drove its confidence score. ### Map the model See every source-to-domain mapping. Accept, adjust, or auto-approve mappings above your confidence threshold ### Trace it in the model Open any entity and see it fully mapped: exactly which datasets and columns resolve to its identifier. WHAT'S DIFFERENT ## A model grounded in your business domain ### Unified Domain Model One typed model of your business, confirmed by the people who own the data. ### Schema Inference Automatically infers typed entities from your schemas and relationships ### Typed Entity Model One field across multiple systems. Each defined once. ### Automatic Source Mapping Each source column maps onto the model. Accept, adjust, or auto-select every mapping above a threshold. ### Entity Resolution The same customer across two systems resolves to one node, matched on shared identifiers. ### Human-Confirm Loop Your people confirm only the ambiguous calls. Each suggestion shows the reasoning behind its score. ### Metadata & Lineage Every entity carries its mapping: the datasets, columns, source rows behind it, model version, and ingestion time. ### Versioning & History The model is versioned, so you can see what an entity meant and when it changed. ## FAQ ### What is the Unified Domain Model? One typed model of your business: entities (Customer, Policy, Claim) and relationships, inferred from your data, confirmed by your people, reasoned on by your agents. ### How is it built? zaimler reads your schemas and the relationships in them, infers a typed model, resolves every source onto it, and brings the hard calls back to your team. ### Do I have to model anything by hand? No. zaimler infers the model from your sources itself. Your people confirm the ambiguous definitions; they never hand-build or maintain anything. ### How is this different from a graph database or vector search? A graph database is storage. Vector search returns lookalikes. zaimler infers the model, resolves real entities, follows real relationships, so the answer holds. ### How long does it take to build? Days to weeks, where a hand-built, consultant-led model of the same scope runs about a year. --- # Platform URL: https://zaimler.ai/product/platform Last updated: 2026-08-06 ## The foundation your AI can trust Connect every source where it lives, resolve every answer with the path behind it, on a foundation you own. WHY THIS EXISTS Your business spans many systems. Agents connected to a single system only see part of the picture. zaimler unifies context across your business so every agent reasons with complete, consistent, and trusted knowledge HOW IT WORKS ## Connect ➝ map, interact, govern ### Connect your sources Federate every source you run, read right where it lives: S3, Snowflake, BigQuery, Databricks, across every cloud. Nothing migrates. ### Map a live graph Automatically infer a live, unified domain model of your business, and accept or reject any changes. ### Interact through any surface Access context through Web-UI, CLI, SDK, API, or MCP. Same governed model, same access rules, whichever surface you use. ### Govern every query Governance is role-based and attribute-based: assign your people to roles, then attach attribute-based policies to the model itself, column masking, export limits, and retention. THE PLATFORM ## The data foundation for your AI ### Read In-Place Nothing gets migrated or duplicated ### Zero-Copy Reads flow through a zero-copy, no storage path across every cloud. ### Ownership The Unified Domain Model is yours the moment it exists, and no vendor can benefit from it. ### Workspaces Carve the one model into as many use cases as you need, each one governed the same way. ### Lineage & Audit Every entity and answer traces back to the source rows it came from, with the path shown. ### Certified Encrypted in transit and at rest. SOC 2 certified, ISO in process. ## FAQ ### Does my data leave my environment? No. zaimler reads your sources right where they sit and answers every query inside your perimeter, with no frontier model required in the runtime path. Zero egress by design. ### Which sources and clouds do you support? Snowflake, BigQuery, Azure, Redshift, Salesforce, and more of your stack, federated across clouds into one model. ### How is governance enforced? Right on the model itself. Role-based and attribute-based: assign users to roles and attach attribute-based policies (column masking, export limits, retention), and every query clears them before it returns an answer. ### What does it mean to own the model? The Unified Domain Model runs in your own environment and belongs to you outright. No vendor holds the original or rents your business back to you. ### Do I have to migrate my data first? No. zaimler reads every source in place, zero-copy, so there are no quarters of migration before the foundation is live. ### Is it ready for regulated data? Built for it: encrypted in transit and at rest, SOC 2 certified, ISO in process, with governance built into how every answer gets made. --- # Asset Management URL: https://zaimler.ai/solutions/by-industries/asset-management Last updated: 2026-08-06 ## Put AI on the exposure decisions that move portfolio risk See true exposure across every mandate from one live understanding of the business. [ WHY IT HOLDS UP ] ## Built for this industry's non-negotiables ### Real relationship traversal Every answer traces a real client-to-holding link in your data, end to end. ### Federated data access Portfolio, mandate, holdings, and client data read into one model, in place. ### Auditable access control You control who acts on a position, and every action is logged for the risk committee. ### Cut portfolio risk The agents that know the real record catch it before it costs your portfolio. ### See the whole portfolio Every system you run feeds agents that finally see your whole portfolio. ### Keep ownership of your data Your agents work from data that never leaves the building and log for the risk committee. [ SEE IT BUILD ] ## See it build, trace every answer to source Your data becomes a live understanding of the business, down to an answer you can replay for an auditor. ### Your sources connect in place Portfolio, mandate, holdings, and client systems connect and read in place. ### The model builds itself The portfolio model builds itself from your sources, then your team confirms it. ### You follow the real relationships You walk the real links from client to mandate to holding across systems. ### Control and log every action You assign roles across positions and client data, and every action is logged. [ WHAT YOU'D ASK ] ## Plain language in, a governed answer out Illustrative examples of the kind of question the Explorer resolves, phrased your way, not ours. - What's our current exposure to this sector? - Show me all mandates with allocation above 60% equities. - Which clients hold this position? [ THE PLATFORM ] ## Built on the zaimler platform ### Platform Your sources connect and read in place. ### Ontology The model of your business builds itself. ### Explorer You follow the real relationships in your data. ### Governance Audit your AI operations ## FAQ ### Is this just portfolio and exposure, or more of asset management? This is our production use case in asset management. Bring another use case from the industry and we'll confirm fit in a proof of value. ### How do you keep data from leaking across mandates? Access is scoped by role and policy, so a manager sees only the mandates they are cleared for, and every action is logged. The model reads in place, nothing copied out. ### Does our data stay inside our environment? Yes. zaimler runs in your VPC or on-prem, over any model, zero egress. Your data and its meaning stay inside your walls, and no frontier model trains on them. ### How does an answer stay accurate? Agents resolve and traverse a graph of the real relationships in your data, so the same question returns the same answer, with the path behind it. ### What does it connect to? Your existing sources, read in place. Core systems, warehouses, and operational data federate into one model, no migration, no copy. ### How long to stand it up? Weeks. The domain model builds itself from the data you already have, then your team confirms it. ### Who's behind it? A team that has automated knowledge graphs at scale and built for regulated production. SOC 2 certified, ISO in process. --- # Banking URL: https://zaimler.ai/solutions/by-industries/banking Last updated: 2026-08-06 ## AI on fraud decisions that move loss and regulatory exposure Flag fraud and clear model-risk review from a live understanding of your business, kept inside your walls. [ WHY IT HOLDS UP ] ## Built for this industry's non-negotiables ### Real relationship traversal Every alert traces the real account-to-transaction links, so none rides on a lookalike. ### Federated data access Core banking, transactions, KYC, and risk read into one model, in place. ### Auditable access control You control who acts, and every decision is logged to clear model-risk review. ### Cut your fraud losses The agents that know the real record catch it before it costs your fraud losses. ### See the whole customer Every system you run feeds agents that finally see your whole customer. ### Keep ownership of your data Your agents work from data that never leaves the building and log for regulatory review. [ SEE IT BUILD ] ## See it build, trace every answer to source Your data becomes a live understanding of the business, down to an answer you can replay for an auditor. ### Your sources connect in place Core banking, transactions, KYC, and risk read in place, nothing copied out. ### The model builds itself The customer model builds itself from your connected data, and your team confirms it. ### You follow the real relationships One customer resolves across core banking, KYC, and risk as you walk the links. ### Control and log every action You set roles and policies to clear model-risk review, with a full audit log. [ WHAT YOU'D ASK ] ## Plain language in, a governed answer out Illustrative examples of the kind of question the Explorer resolves, phrased your way, not ours. - Show me every account linked to this flagged entity. - What's this customer's KYC history? - What's the entity network behind this alert? [ THE PLATFORM ] ## Built on the zaimler platform ### Platform Your sources connect and read in place. ### Ontology The model of your business builds itself. ### Explorer You follow the real relationships in your data. ### Governance Audit your AI operations ## FAQ ### Is this specific to compliance and fraud, or does it cover more of banking? This page shows our banking production use case. Bring another from the same industry and we'll confirm fit in a proof of value. ### Does this clear model-risk review? Yes. Model-risk teams get the path behind every answer: the real account-to-transaction links it resolved, with roles, policies, and a full audit log. Built to clear the review. ### Does our data stay inside our environment? Yes. zaimler runs in your VPC or on-prem, over any model, zero egress. Your data and its meaning stay inside your walls, and no frontier model trains on them. ### How does an answer stay accurate? Agents resolve and traverse a graph of the real relationships in your data, so the same question returns the same answer, with the path behind it. ### What does it connect to? Your existing sources, read in place. Core systems, warehouses, and operational data federate into one model, no migration, no copy. ### How long to stand it up? Weeks. The domain model builds itself from the data you already have, then your team confirms it. ### Who's behind it? A team that has automated knowledge graphs at scale and built for regulated production. SOC 2 certified, ISO in process. --- # Healthcare URL: https://zaimler.ai/solutions/by-industries/healthcare Last updated: 2026-08-06 ## Put AI to work on the decisions that move payment integrity Protect payment integrity by checking claims against a live understanding of the business. [ WHY IT HOLDS UP ] ## Built for this industry's non-negotiables ### Real relationship traversal Patient, diagnosis, and claim connect through real links in the record, traceable end to end. ### Federated data access EHR, claims, and operations read into one patient model, in place. ### Auditable access control Every decision is logged and HIPAA-defensible, with PHI staying inside your walls. ### Protect payment integrity The agents that know the real record catch it before it costs your payment integrity. ### See the whole patient Every system you run feeds agents that finally see your whole patient. ### Keep ownership of your data Your agents work from data that never leaves the building and log for regulatory review. [ SEE IT BUILD ] ## See it build, trace every answer to source Your data becomes a live understanding of the business, down to an answer you can replay for an auditor. ### Your sources connect in place Your EHR, claims, and operations read in place, and PHI never leaves your walls. ### The model builds itself The patient model builds itself from your data, and your team confirms it. ### You follow the real relationships You trace the real links from patient to diagnosis to claim across every source. ### Control and log every action You scope every role to the minimum PHI necessary, with a HIPAA-defensible audit log. [ WHAT YOU'D ASK ] ## Plain language in, a governed answer out Illustrative examples of the kind of question the Explorer resolves, phrased your way, not ours. - Does this claim match the diagnosis on record? - Show me this patient's full care and claim history. - Which claims were coded against a missing diagnosis? [ THE PLATFORM ] ## Built on the zaimler platform ### Platform Your sources connect and read in place. ### Ontology The model of your business builds itself. ### Explorer You follow the real relationships in your data. ### Governance Audit your AI operations ## FAQ ### Is this just care and claims, or does it cover more of healthcare? This shows our production use case in healthcare. Bring another from the same industry and we'll confirm fit in a proof of value. ### How does it stay HIPAA-defensible with PHI? zaimler reads PHI in place, scopes every role to the minimum necessary, logs every action to a HIPAA-defensible audit trail, and never trains the frontier model on your data. ### Does our data stay inside our environment? Yes. zaimler runs in your VPC or on-prem, over any model, zero egress. Your data and its meaning stay inside your walls, and no frontier model trains on them. ### How does an answer stay accurate? Agents resolve and traverse a graph of the real relationships in your data, so the same question returns the same answer, with the path behind it. ### What does it connect to? Your existing sources, read in place. Core systems, warehouses, and operational data federate into one model, no migration, no copy. ### How long to stand it up? Weeks. The domain model builds itself from the data you already have, then your team confirms it. ### Who's behind it? A team that has automated knowledge graphs at scale and built for regulated production. SOC 2 certified, ISO in process. --- # Insurance URL: https://zaimler.ai/solutions/by-industries/insurance Last updated: 2026-08-06 ## Move loss ratio on claims and fraud decisions Build agents from a live understanding of your business, making claims faster and payouts more defensible. [ WHY IT HOLDS UP ] ## Built for this industry's non-negotiables ### Real relationship traversal Every answer traces a real policy-to-claim link, so no payout rides on a lookalike. ### Federated data access Claims, underwriting, billing, and CRM read into one policyholder model in place. ### Auditable access control You control who acts on a claim, and log every decision for the claims audit. ### Cut your loss ratio The agents that know the real record catch it before it costs your loss ratio. ### See the whole policyholder Every system you run feeds agents that finally see your whole policyholder. ### Keep ownership of your data Your agents work from data that never leaves the building and log for the claims audit. [ SEE IT BUILD ] ## See it build, trace every answer to source Your data becomes a live understanding of the business, down to an answer you can replay for an auditor. ### Your sources connect in place Claims, underwriting, billing, and CRM connect and read in place, nothing copied out. ### The model builds itself The policyholder model builds itself from your sources, and your team confirms it. ### You follow the real relationships You trace the real links between policy, claim, and billing across sources. ### Control and log every action You assign claims and underwriting roles, and every action lands in the audit log. [ WHAT YOU'D ASK ] ## Plain language in, a governed answer out Illustrative examples of the kind of question the Explorer resolves, phrased your way, not ours. - Does this claim match the policy on file? - Show me every claim tied to this provider. - Which open claims share a billing address? [ THE PLATFORM ] ## Built on the zaimler platform ### Platform Your sources connect and read in place. ### Ontology The model of your business builds itself. ### Explorer You follow the real relationships in your data. ### Governance Audit your AI operations ## FAQ ### Is this just claims, or does it cover more of insurance? This shows our production use case in insurance. Bring another from the same industry and we'll confirm fit in a proof of value. ### Can an agent's payout call stand up in a claims audit? Yes. Every answer carries the path it traversed, the real policy-to-claim-to-billing links, logged for the claims audit. Your team can replay how the agent reached the call. ### Does our data stay inside our environment? Yes. zaimler runs in your VPC or on-prem, over any model, zero egress. Your data and its meaning stay inside your walls, and no frontier model trains on them. ### How does an answer stay accurate? Agents resolve and traverse a graph of the real relationships in your data, so the same question returns the same answer, with the path behind it. ### What does it connect to? Your existing sources, read in place. Core systems, warehouses, and operational data federate into one model, no migration, no copy. ### How long to stand it up? Weeks. The domain model builds itself from the data you already have, then your team confirms it. ### Who's behind it? A team that has automated knowledge graphs at scale and built for regulated production. SOC 2 certified, ISO in process. --- # Telecommunications URL: https://zaimler.ai/solutions/by-industries/telecommunications Last updated: 2026-08-07 ## Move revenue assurance with AI on subscriber decisions Defend every subscriber answer in a revenue-assurance review, on a live understanding of the business. [ WHY IT HOLDS UP ] ## Built for this industry's non-negotiables ### Real relationship traversal Every answer traces the real links between customer, plan, device, and network. ### Federated data access Billing, CRM, network, and support read into one subscriber model, in place. ### Auditable access control You control who can act, and every action is logged for a revenue-assurance review. ### Cut revenue leakage The agents that know the real record catch it before it costs your revenue. ### See the whole subscriber Every system you run feeds agents that finally see your whole subscriber. ### Keep ownership of your data Your agents work from data that never leaves the building and log for leadership review. [ SEE IT BUILD ] ## See it build, trace every answer to source Your data becomes a live understanding of the business, down to an answer you can replay for an auditor. ### Your sources connect in place Billing, CRM, network, and support connect and read in place, nothing copied out. ### The model builds itself The subscriber model builds itself from your sources, and your team confirms it. ### You follow the real relationships You walk the real links between subscriber, plan, device, and network across systems. ### Control and log every action You assign roles across customer and network data, and every action is logged. [ WHAT YOU'D ASK ] ## Plain language in, a governed answer out Illustrative examples of the kind of question the Explorer resolves, phrased your way, not ours. - What's this subscriber's full account history? - Which accounts on this plan are hitting network issues? - Which subscribers are on degraded cell sites? [ THE PLATFORM ] ## Built on the zaimler platform ### Platform Your sources connect and read in place. ### Ontology The model of your business builds itself. ### Explorer You follow the real relationships in your data. ### Governance Audit your AI operations ## FAQ ### Is this just subscriber and network, or does it cover more of telecom? This page shows our telecom production use case. Bring another use case from the industry and we'll confirm fit in a proof of value. ### Can it back a revenue-assurance review? Yes. Every subscriber and network answer carries its trail, scoped by role and logged, so a revenue-assurance review can follow exactly how the number was reached. ### Does our data stay inside our environment? Yes. zaimler runs in your VPC or on-prem, over any model, zero egress. Your data and its meaning stay inside your walls, and no frontier model trains on them. ### How does an answer stay accurate? Agents resolve and traverse a graph of the real relationships in your data, so the same question returns the same answer, with the path behind it. ### What does it connect to? Your existing sources, read in place. Core systems, warehouses, and operational data federate into one model, no migration, no copy. ### How long to stand it up? Weeks. The domain model builds itself from the data you already have, then your team confirms it. ### Who's behind it? A team that has automated knowledge graphs at scale and built for regulated production. SOC 2 certified, ISO in process. --- # Agents URL: https://zaimler.ai/solutions/by-use-case/agents Last updated: 2026-08-07 ## Build agents you can trust zaimler grounds your agents in a live, governed understanding of your business, and runs every call they make through your policies. [ THE PROBLEM ] ## Agents stall before production To get your agents working in the real world, they need real-time understanding of your business data with traceability and governance. [ HOW IT WORKS ] ## Get agents working in weeks Watch a grounded agent run on core data, from the first call to the audit. ### Ground the agent It works from the same model of how your business fits together. ### Traverse the business The agent walks the real relationships in your data to reach what it needs. ### Govern every call Every call runs through your policy before an entity resolves. ### Log the path Every action is logged with the traversal that produced it, ready for review. ## FAQ ### How do agents get grounded, and how accurate are they? Every agent runs over the domain model zaimler builds in Ontology, so it works from the real entities and relationships in your data. Grounding it in that model is what makes its answers hold up on core data. The full accuracy story lives on the Data page. ### Do agents share context with our analysts? Yes. Your agents and your analysts pull from the same domain model, so a question resolves the same way whoever asks it, and one access policy decides what each of them can see. ### Will an agent pass our security review? Every call the agent makes runs through your access policy before an entity resolves, and it logs the full traversal behind the answer, so your model-risk team can replay exactly how any action was reached. Your data stays in your environment the whole time. See Data sovereignty for the deployment detail. ### How fast to a production agent? You bring a real, live use case and zaimler stands up the context for it on your own data, then grounds and governs the agent on that model. That is how a working agent reaches your team in weeks. --- # Data URL: https://zaimler.ai/solutions/by-use-case/data Last updated: 2026-08-06 ## Make high-stakes decisions on accurate data Ask in natural language. zaimler provides accurate, real-time, governed answers. [ THE PROBLEM ] ## Close enough is still wrong RAG and vector search return what looks similar. On core data, similar is a wrong number carried with confidence. zaimler uses ontologies to model your business accurately. [ HOW IT WORKS ] ## Get the right answer, every time. Watch a natural language question become a grounded, traceable answer. ### Ask a natural language question You type it the way you would say it, with no query language to learn. ### Resolve it on the graph zaimler resolves it against the real relationships across every connected source. ### See the reasoning You get the resolved entities and the exact route they came from. ### Set it on repeat Ask again and it resolves the same way every time. ## Questions zaimler answers today ### Data exploration - Which policies touch this reinsurance treaty? - Show every claim linked to this policyholder. - List the accounts onboarded since the last model refresh. ### Relationship analysis - How is this customer connected to this counterparty? - Which records resolve to one policyholder across systems? - Trace the path from this claim to its underwriting file. ### Analytical queries - What is our loss ratio by product this quarter? - Average time from first notice of loss to payment? - Which segments drove written-premium growth? ### Insights and trends - Where are fraud patterns emerging across transactions? - Which products carry the most disputed claims? - What is trending in policy cancellations by region? ## FAQ ### How is this different from RAG? RAG matches on surface similarity, so it can hand back a passage that looks right and is not. zaimler traverses the modeled relationships in your data, so it returns what is actually connected to your question, with the path to prove it. ### How is this different from a data catalog? A catalog describes your data in a snapshot you read, and it goes stale between refreshes. zaimler puts the meaning in the query path itself and resolves the answer against live sources every time, so what comes back reflects the business as it is right now. ### How do I know the result is consistent? zaimler resolves each question by traversing the same modeled relationships, so a repeated question returns the same answer as long as the underlying data has not changed. Every resolution records its path in Governance, so anyone on your team can open it and see which entities and relationships produced the result. ### Can non-technical teams use it? Yes. Anyone who can ask the question in plain language can use it, with no query language to learn. zaimler returns the resolved entities, the answer, and the exact path it took, so the result is easy to read and easy to check. --- # Field notes on context for enterprise AI URL: https://zaimler.ai/blog Last updated: 2026-08-06 zaimler provides the runtime context layer between enterprise data and enterprise AI. Dive in to learn how accuracy beats similarity, and how agents survive production. - [Your best questions aren't retrieval questions](https://zaimler.ai/blog/structural-questions): Retrieval assumes the answer is sitting somewhere, waiting to be found. For the questions enterprises most want answered, it isn't. - [Most "Ontologies" Don't Reason. Build Yours in the Right Order Anyway.](https://zaimler.ai/blog/ontology-maturity-ladder): An opinionated maturity path for ontology-like structures in the agentic era - [Metric status is a trust signal, not paperwork.](https://zaimler.ai/blog/metric-status-trust-signal): What draft, published, and certified have to mean now that agents read the catalog too, and why the labels you already have are quietly running your board deck. - [Context Layer: Feature or Platform?](https://zaimler.ai/blog/context-layer-feature-or-platform): What talking to your data actually requires, and ten questions that follow from it --- # Your best questions aren't retrieval questions URL: https://zaimler.ai/blog/structural-questions Last updated: 2026-08-07 Retrieval assumes the answer is sitting somewhere, waiting to be found. For the questions enterprises most want answered, it isn't. ### In short Retrieval assumes answers are stored somewhere and just need finding. That holds for a lot of questions and fails for an important class of them: the ones whose answer exists _across_ records rather than _in_ any one of them. No embedding model reaches those. Neither does a bigger context window. ## The short version - Retrieval assumes the answer is written down somewhere. A second class of question, structural questions, has answers that are properties of the relationships between records, and no record contains them. - The beneficial ownership loop is the clean case: three correct filings, a chain that closes on itself, and a finding that lives in no single row. - Similarity search cannot rank the record that matters, because what makes it matter is not written in its text. Whether it arrives depends on the corpus, and nothing announces its absence. - Handing the model the whole subgraph does not save it: cycles, aggregated percentages, and threshold breaches are computations to perform and verify rather than things to notice in prose. - What closes the gap is an ontology: what the entities are, what the relations mean, and what rules hold over them, written down once where both the analyst's knowledge and the engine's query can come from it. ## 01 A question with no answer in the file There is a class of question that enterprises most want answered and that the current generation of agents cannot reach. This is the first post in a series about such questions. The examples that follow come from banking, where the rules are written down, the stakes are legible, and the failure modes already have names, but very little of what follows is specific to banks. The same pattern appears wherever an answer depends on how records relate rather than on what any one of them says: a manufacturer tracing a component back through four tiers of suppliers, an insurer checking whether the same adjuster sits on both sides of a claim, a hospital reconciling one patient across systems that never agreed on an identifier. Swap the vocabulary, and the argument still holds. Every bank has to name the human beings behind a corporate customer. That is the [beneficial ownership requirement](https://www.fatf-gafi.org/en/topics/beneficial-ownership.html): follow ownership up through whatever holding structures exist until the chain ends in natural persons, then screen those names against sanctions and [politically exposed person (PEP)](https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-pep-rec12-22.html) lists. It runs thousands of times a day and it is almost always mechanical. Then an analyst files a note that reads: _we can never get to a real person on this one._ Nothing in the data looks wrong. Three columns do the work, `customer_id`, `parent_entity_id` and `ownership_pct`, and the filings are present and correct. `FILING 1 ACM-4471 Acme Corp is 100% owned by KES-2210 Kestrel Holdings` `FILING 2 KES-2210 Kestrel Holdings is 100% owned by ALD-8853 Alder Group` `FILING 3 ALD-8853 Alder Group is 100% owned by ACM-4471 Acme Corp` Read them one at a time and there is nothing special to see. Companies own companies all the time. Every record is clean and every field populated. And the requirement still cannot be satisfied, because the chain has no bottom. Follow the ownership and you arrive back where you started, without ever reaching a person. No single filing carries that fact. It belongs to the three of them together, and it is written down nowhere. ![One three-row ownership table answering two questions: a point lookup reads one cell and returns Acme Corp's balance of 4,210.00; the structural question follows parent_entity_id three hops, lands back on the row it started from, and never names a person.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_1_one_table_two_questions_v2_d281f320c6.png) FIGURE 1 — Same table, same three rows. The first question reads a cell and stops. The second one reads three rows and arrives back where it began. 'Something' or 'someone' has to know that a chain of `parent_entity_id` pointers _is_ an ownership structure, that walking it is what the regulation means by tracing, and that a chain closing back on itself means the ownership never reaches a person, rather than meaning the data is broken. None of that knowledge is in the schema. None of it is in the embeddings. It lives in the analyst's head, and it gets re-derived, imperfectly, on every single query. ![Two beneficial ownership walks side by side: most customers' chains end in a natural person after two hops and the name is screened; Acme Corp's chain runs Acme to Kestrel to Alder and back to Acme, so the walk never ends and no name is screened.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_2_walk_that_never_ends_868334ea59.png) FIGURE 2 — One procedure, two customers, identical up to the last hop. Every box on the right is a valid, correctly filed record. The only thing that differs is where the arrows go. ## 02 The model underneath Retrieval is incomplete rather than wrong: it describes half the problem, and the field has been treating it as the whole one. Beneficial ownership is exactly the kind of work agents are now pointed at. Sit an agent on the bank's data, let an analyst ask in plain language, get an answer back without a ticket and a three-day wait. The standard advice for making that agent answer better tends to be the same. Better embeddings. Better chunking. Better reranking. Hybrid search. A bigger context window. Every item on it improves _fetching_. The assumption underneath, mostly unexamined, is that answering a question means going and getting the thing that contains the answer. That assumption is good. It is just partial. It holds perfectly for questions whose answers were written down somewhere, and those questions are common enough that the edge of it rarely comes up. _What's this customer's balance? What does our refund policy say?_ The answer is sitting in a place. Retrieval is the right tool there. The ownership question is the edge. Fetch all three records perfectly, with a perfect ranker, and the answer still isn't among them, because none of them contains it. The retrieval ran correctly, against a question that was never a retrieval question. That is the missing half. Alongside the questions with an answer somewhere sits a second class, whose answers are properties of the _relationships between_ things rather than properties of any thing. Let's call them **structural questions**. ## 03 Recognizing them in the wild Once the missing half is visible, structural questions turn out to be most of the ones worth asking. ### Structuring detection Nine cash deposits between $6,400 and $9,100, spread over thirty-one days across four branches, totaling $71,800. The reporting threshold is $10,000 and not one deposit reaches it. The account's largest single deposit in the preceding twelve months was $2,300. Every deposit is legal, unremarkable, and correctly recorded. **SIGNAL** `a property of the set, and of its distance from that account's own baseline` ### Cross-border flow mapping 2.1m euro leaves a Frankfurt account held by Meridian GmbH, lands in Nicosia, moves to Dubai eleven days later, and returns to a second Frankfurt account held by Meridian Logistik GmbH. Different legal entity, same beneficial owner. Each hop is a legitimate transfer between legitimate accounts and each clears review on its own. Nothing in hop three records that hop one ever happened. **SIGNAL** `the route, and the fact that it closes on the party it started from` ### Four-eyes violations Every alert is supposed to be raised by one analyst and cleared by a different one. Over eighteen months, how many times did the same person appear on both ends, whether directly or through a colleague they also supervise? No memo records a violation, because no single memo contains both ends of the pair. **SIGNAL** `a count of paths through people and documents, computed, not stored` ### Shared-attribute clustering Nine companies file as independent entities. Three list the same address in Slough, four name the same director, two give the same Berlin phone number. Plenty of companies legitimately share a registered office, so no single filing is irregular. The signal only exists once the nine are placed side by side. **SIGNAL** `the collision, invisible until the records are co-located` ![Nine independent filings wired to three shared attributes from three source systems: an address in a registry field, a director on a scanned onboarding form, a phone number in a support transcript. The collision is visible only with all nine side by side.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_3_nine_filings_one_collision_1900ca2dd4.png) FIGURE 3 — The shared address sits in a structured registry field. The director is buried in a scanned onboarding form. The phone number is mentioned once, in a support transcript. Three systems, three shapes, and the finding is visible in none of them alone. There is a practical filter in here. Lookup questions already have good answers; a database has handled them well for decades, and wrapping natural language around them is a real convenience but rarely the reason anyone funds an agent. The questions above are the ones with _no_ explicitly written answer, and they are where an agent earns its place. It makes a useful check against our roadmaps: how many of the target questions are structural, and does the current stack have a way to reach them? ## 04 Where each way of fetching breaks Walk the two standard retrieval methods against the ownership question. Each fails in a specific, nameable place, and neither failure is fixed by turning a dial harder. ### FAILURE 1 · SIMILARITY SEARCH ### The ranking is flat, and nothing in it tells you whether the chain is complete. Embed _who ultimately owns Acme Corp_ and pull the k nearest records. Acme's own filing comes back first, because it contains the string. After that the ranking goes flat. Every record in the corpus is a corporate filing, and they are all written the same way: an entity, a status, a parent. To an embedder they are near-identical. Kestrel Holdings, the record the chain runs through, scores 0.67. Brightwater Holdings, which has nothing to do with this customer, scores 0.70. Kestrel Marine Ltd, which shares half a name and no relationship at all, scores 0.71. That spread is noise. The property that makes Kestrel's filing the one you cannot do without, that it is the middle link between Acme and Alder, is not written in its text, so no score can reflect it. What the scores reflect is that all of these documents look like corporate filings. So the retrieval is a maybe. At k=10 today Kestrel lands just inside the window and the agent finds the loop. Onboard forty thousand entities next quarter and Kestrel is at rank 31, the retrieval window closes above it, and the agent reports that Acme is owned by Alder Group. **Same pipeline, same prompt, same confident tone, opposite answer, and nothing in either output distinguishes the two runs.** Reranking does not help, because a reranker scores the same text against the same query. Raising k does not help either; it widens the window and adds more filings that look exactly alike, which lowers the odds that a reader spots the one that mattered. There is no threshold or confidence band, and no error to catch, because as far as the retriever is concerned, nothing went wrong. ![Similarity ranking for the query 'who ultimately owns Acme Corp': ten near-identical scores from 0.74 to 0.67 with the decisive record ranked tenth, and two runs of the same pipeline two quarters apart, one finding the ownership loop and one confidently reporting the wrong owner.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_4_ranked_by_similarity_55fb705328.png) FIGURE 4 — The failure is that nothing separates the right record from the ones around it, so whether the chain completes depends on the corpus rather than the question, and neither run gives you a way to tell. Even with all three records in hand, similarity has no way to represent _these three close into a loop_, because the loop is a property of no single record. Similarity ranks records against a query. It cannot rank a relationship that isn't written in any of them. ### FAILURE 2 · QUERY RETRIEVAL ### The database can compute it, but only if someone already knew to ask. A [recursive CTE (common table expression)](https://www.postgresql.org/docs/current/queries-with.html) with cycle detection finds the loop in milliseconds, and it comes with the thing similarity search cannot offer: a definite answer, and a path you can read back to check it. To write it, though, you have to already suspect a cycle, already know that a cycle is what _no beneficial owner_ reduces to, and already know which of the forty ownership-shaped columns is the one to walk. A query is a question made precise. The analyst holding the question cannot express it that way, and the engine will not volunteer it. SQL doesn't surface findings; it confirms hypotheses you already have. _The data supports the query_ and _the question gets answered_ are not the same statement. So similarity retrieval cannot reliably assemble the relevant records, and cannot tell you when it failed. Query retrieval can do both, and cannot be written by the person who needs it. The tempting fix is to be generous: skip the retrieval problem entirely, hand the model the whole neighborhood, and let it work the answer out. ## 05 Handing over the subgraph doesn't save it Even given the exact right records, retrieve-then-generate is the wrong shape, because the finding now depends on the model noticing it, every time, with nothing to check. Suppose you solve retrieval by brute force. Pull Acme's entire ownership neighborhood, every entity and every edge, and drop the whole subgraph into the context window. The model now has three companies and three ownership links sitting in front of it. Ask again: who ultimately owns Acme? This is [RAG (retrieval-augmented generation)](https://arxiv.org/abs/2005.11401) in its most generous form, and it is still the wrong architecture. **Having the loop in the context is not the same as knowing there is a loop.** The model has to notice that Acme → Kestrel → Alder returns to Acme, understand that a returning chain means the ownership never grounds out in a person, and do that reliably, in prose, buried among whatever else got swept into the window. On three clean nodes, it might. That _might_ is the entire problem, and it is the same _might_ as the last section, moved one stage downstream. Because the real question isn't three nodes. It is a customer with forty holding entities across six jurisdictions, where control has to be aggregated along every branch and compared against the 25% threshold. A path of 40% × 70% × 90% comes to 25.2% and has to be reported. A path of 40% × 60% × 90% comes to 21.6% and does not. Those two branches look identical in prose, and there are two hundred of them. _Read all of it and reason it out_ degrades exactly where it matters, and it degrades invisibly. The model returns a confident paragraph either way, and nothing in the output tells you whether it multiplied the percentages down each branch or pattern-matched something plausible. The data was all there. Retrieve-then-generate fails because the finding is a computation over structure, and generation was asked to _notice_ it rather than _perform_ it. It's worth separating two things here. A cycle. An aggregated ownership percentage. A shortest path between two parties. A set that breaches a threshold. These are things you compute, deterministically, and then verify by reading back the path that produced them. They are not things you hope a model spotted in a wall of retrieved text. A better retriever puts more into the window. It does nothing about the fact that the answer has to be reasoned out of the structure, reliably and checkably. ## 06 The architecture is wrong, not the components Both stages of the standard pattern miss, and the thing that would close the gap was never written down. Put the two halves together and the standard pattern collapses. Retrieval ranks by similarity, so whether the record that matters arrives is a matter of luck, and nothing announces its absence. Generation is handed whatever did arrive and asked to find the structure by reading, which it does unreliably and unverifiably. Fetch, then generate: both stages miss, and both miss quietly. That pattern has a name, and it is the default way agents get built today. RAG is superb when the answer is sitting in a document and the job is to find the document. It is the wrong architecture the moment the answer is a property of how things connect, because neither of its two moves is the move the question needs. **Retrieval doesn't traverse, and generation narrates rather than computes.** ![The retrieve-then-generate pipeline against what the question needs: ranking records by similarity and narrating them in prose, versus traversing the relationships, computing the finding, and returning the path that produced it.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_5_retrieve_then_generate_d7e0505f5c.png) FIGURE 5 — The fix isn't a better retriever or a bigger model. Both help with the questions that were already easy. Neither touches the hard ones, because the missing capability was never fetching or phrasing. The fair objection at this point is that all of this is solved. Graph databases traverse relationships natively, recursive SQL finds the loop, any competent engineer writes the query in an afternoon. All true, and all beside the point, because a query is an answer to a question you already knew how to ask, and the ownership loop only gets caught by someone who already suspected it was there. So the problem splits in two. The analyst staring at the alert knows what to look for but cannot express it in SQL. The engineer who can write the SQL doesn't know that a loop is what _no beneficial owner_ reduces to. **The person with the question and the person who can pose it to the machine are never the same person.** Which points back at the first section. What the analyst knows, that these pointers are an ownership structure, that walking them is what tracing means, that a chain closing on itself is a finding rather than a data error, has never been written anywhere a machine can read. The schema certainly doesn't systematically hold it. A schema is enough to store the column correctly and says nothing whatsoever about what the column means. ![The same column twice: the schema records parent_entity_id as a VARCHAR foreign key, while the analyst knows the edge is ownership, that it composes along a path, that control is the product of percentages, that owners must be natural persons, and that a closed chain is a finding. The right side is written down nowhere.](https://mindful-life-e47e725b32.media.strapiapp.com/structural_questions_figure_6_same_column_twice_37dc59c033.png) FIGURE 6 — The same column, twice. The left side is three lines long and has been maintained for years. The right side is five statements, every one of which this post has already relied on, and it exists only in people. Write those five statements down in a form a machine can evaluate and the question changes shape. _No beneficial owner_ stops being a matter of phrasing and gains a definition: walk the ownership relation out from this entity, return the natural persons at the ends, and if the walk closes on itself without reaching one, that is the finding, and here is the path it took. The analyst no longer needs to know what a cycle is. The engineer no longer needs to know what a beneficial owner is. Neither has to become the other, because both halves are written down once, in the same place. That account of what the entities are, what the relations mean, and what rules hold over them is an **ontology**. The schema describes storage, and the knowledge graph is the data arranged in that shape. The ontology is the layer that makes the question answerable at all, and it is the one most stacks never needed until an agent turned up to ask. None of this helps the analyst from the first section, not yet. The alert is still open and the chain still doesn't reach a person. What would close it is somewhere for the domain knowledge to live, rather than a bigger model or a faster engine: ownership defined once, tracing defined once, and an agent that can walk those definitions and hand back the path it took. Part two of this series picks up on what it takes to build this layer. ## FAQ ### What is a structural question? A question whose answer is a property of the relationships between records rather than of any single record. The beneficial ownership loop is one: three filings are each clean, and the finding that the chain closes on itself is written down nowhere. Lookup questions have answers sitting in a place; structural questions have answers that only exist across records. ### RAG over documents is not answering our cross-system questions. What should sit underneath the agents instead? A layer that holds what the schema leaves out: what the entities are, what the relations mean, and what rules hold over them. That account is an ontology. Written down once in a form a machine can evaluate, it turns a phrase like no beneficial owner into a definition an agent can walk, with the path read back as the check. ### Is a stronger RAG pipeline enough for production reliability, or do we need to traverse relationships? For questions whose answer sits in a document, a stronger pipeline helps. For structural questions it does not: similarity ranks near-identical records on noise, and generation is then asked to notice structure in prose with nothing to check against. Cycles, aggregated ownership percentages, and threshold breaches are computations over structure, and they have to be performed rather than narrated. ### Why do agents answer the same question differently as the data grows? Because similarity retrieval makes the arrival of the deciding record corpus-dependent. At k=10 today the record that closes the ownership loop sits just inside the window and the agent reports the loop; forty thousand entities later it sits at rank 31, and the same pipeline reports that Acme is owned by Alder Group, in the same confident tone, with nothing in either output distinguishing the runs. ### What's the difference between a schema, a knowledge graph, and an ontology? The schema describes how the data is stored. The knowledge graph is the data arranged in relationship shape. The ontology is the account of what the entities are, what the relations mean, and what rules hold over them: the layer that makes a structural question answerable at all. --- # Most "Ontologies" Don't Reason. Build Yours in the Right Order Anyway. URL: https://zaimler.ai/blog/ontology-maturity-ladder Last updated: 2026-08-07 An opinionated maturity path for ontology-like structures in the agentic era ## The short version - Almost no product on the market meets the formal definition of an ontology, and Jessica Talisman is right to say so. Ours does not meet it either: we build governed graphs of entities, properties, and relations, without formal inference. - The useful question for a builder is what to build, in what order, so that agents working against your data are trustworthy at each step. - The answer is a six-rung ladder: a resolved and governed graph, then versioning, inheritance, controlled vocabularies and taxonomies, rules and constraints, and formal inference last. Rungs two and three often land in either order. - A reasoner is an amplifier. Pointed at an unresolved, unversioned graph, it derives garbage with perfect logical rigor; the lower rungs are its preconditions. - Ask any vendor which rung they are on today, not which rung their roadmap gestures at. The word "ontology" is having a moment. Databricks put it in a product name. Palantir built a company on it. Microsoft attached it to Fabric IQ. Snowflake wrapped an architecture in it at their Summit. Databricks? The week after. And shortly thereafter, Jessica Talisman published ["Not an Ontology"](https://jessicatalisman.substack.com/p/not-an-ontology), a careful analysis arguing that none of these products meets the formal definition: ["an explicit specification of a conceptualization"](https://doi.org/10.1006/knac.1993.1008), in Tom Gruber's classic formulation, which the knowledge-representation tradition completes with axioms and a reasoner that derives new facts. By that bar, she is right. Ranking definitions is not reasoning. Snapshot traversal and pre-declared joins are retrieval and query generation, which are useful and are not the same thing. I work on zaimler, the runtime context layer for AI agents, so I read her piece with more than academic interest. Her bar would find our platform short too; conceding that plainly is the only credible place to start. We produce governed graphs of entities, properties, and relations. We do not have formal inference. Almost nobody does. But here is where I part ways with how the debate usually goes from there. The interesting question for a practitioner is not "is it a real ontology?" It is: **what should you actually build, in what order, so that agents working against your data are trustworthy at each step along the way?** That question has an answer, and the answer is a ladder. You climb it. (A note on framing: in a follow-up piece I'll look at the five mechanisms vendors actually ship behind the word "ontology": retrieve, rank, generate SQL, traverse, reason. That is a lens for evaluating products. This piece is the other side of it, the path a builder climbs. The two are related but not the same axis: a product runs one mechanism; a builder accumulates structure.) ## The false fork: property graph versus RDF First, a distraction to clear away. Much of this debate collapses into a technology fork: labeled property graphs (fast, pragmatic, vendor-flavored) versus RDF and OWL (open, formal, reasoner-ready). Pick your church. The fork is a red herring, because the two things do different jobs at different layers. A property graph is a runtime substrate: it is how you materialize a graph and traverse it quickly, multi-hop, at query time. An ontology is a governance layer: it is where classes, properties, and constraints are defined, and it is where open semantic standards belong, because meaning defined in open structure ([RDF, OWL, JSON-LD](https://www.w3.org/standards/semanticweb/), [SKOS](https://www.w3.org/TR/skos-reference/)) can leave the building. The mature architecture uses both, each where it is strong: an open-standards-aligned model governing what the graph may contain, and a traversal-optimized runtime executing against it. ![Two-layer stack: an ontology governance layer governs and constrains a property-graph runtime layer. Meaning is exportable from the governance layer as open structure such as JSON-LD and RDF/OWL.](https://mindful-life-e47e725b32.media.strapiapp.com/not_a_fork_a_stack_5334ee1d7b.png) The two layers do different jobs. Sovereignty lives in the top layer. This matters for Talisman's description of sovereignty, and her framing of it is the one I now use: meaning is only sovereign if it is exportable in open, vendor-neutral structure. A graph whose semantics exist only inside one vendor's runtime fails that test no matter how good the demo is. A runtime graph that is _grounded in_ an open model passes it, because the meaning has an existence independent of the engine. Residency (where the reasoning runs, what leaves your boundary) is the other half of sovereignty, and it deserves equal weight, especially as legal compliance requirements of traceability and oversight obligations take shape. Ask both questions of any platform, including mine. ## Climb the ladder in order Talisman's own [Ontology Pipeline](https://jessicatalisman.substack.com/about) is a progressive framework: controlled vocabularies, then taxonomies, then ontologies, then knowledge graphs. I want to offer a practitioner's version of the same instinct, aimed at teams building for agents today. The principle: **each rung is only worth building on top of the rung below it.** You do not build the fifth floor before the second. The full arc is below. Rungs two and three often land in either order; everything else sequences strictly. Each rung earns its place the same way: it converts a class of silent failure into governed behavior a business can rely on. ![The ontology maturity ladder: six ascending rungs, from a resolved and governed graph at rung 0 through versioning, inheritance, vocabularies and taxonomies, and rules and constraints, to formal inference at rung 5, which nobody ships yet.](https://mindful-life-e47e725b32.media.strapiapp.com/ontology_maturity_ladder_6f04a6aaa4.png) The maturity ladder. | Rung | Why it sequences here | What it buys you | | --- | --- | --- | | 0. Resolved, governed, traversable graph | The foundation everything stacks on: entity resolution, typed relationships, human-validated definitions, runtime multi-hop query with provenance. | Agents reason about things, not columns. Every answer carries a path back to source. | | 1. Versioning | The cheapest trust you will ever buy. Auditability requires knowing what a term meant at the moment an answer was generated. | A model auditable over time, and a direct answer to emerging traceability obligations. | | 2. Inheritance (IS-A) | The gateway to subsumption, and the precondition for most real reasoning. | Knowledge propagates instead of being restated: what holds for Contract holds for Policy, for free. | | 3. Controlled vocabularies and taxonomies | Natural alongside inheritance; taxonomies are inheritance hierarchies over concepts. | Agents speak canonical code lists (ICD, NAIC, AML typologies) instead of inventing synonyms for things with official names. | | 4. Rules and constraints | The first taste of derivation. A domain expert's judgment is encoded once and enforced thereafter. | The model can reject an invalid assertion instead of storing it. The graph pushes back. | | 5. Formal inference | Only safe on top of resolved, versioned, constrained structure. | New facts derived by deduction, with logic that can show its work. | Two rungs deserve a closer look, because they are where I see teams go wrong most often: the bottom and the top. The bottom rung is unglamorous, and it is where most of the production value lives. Entity resolution is what makes federated consistency possible, where "Customer 4471" in the billing system and "C-4471" in the CRM are one thing, not two. And the human in the loop matters most here: when the system proposes a definition or a relationship, an expert validates it before agents rely on it. Automation that guesses definitions from usage signals produces confident, wrong answers unless a person signs off. The middle rungs compound quietly. Versioning answers the auditor's question: what did "active member" mean when this answer was generated? Inheritance is what Talisman rightly calls "the most basic ontological relation," and its absence is a fair test of any product using the word (she makes exactly this point about Fabric). [SKOS](https://www.w3.org/TR/skos-reference/)-style concept schemes earn their keep fastest in regulated domains built on canonical code lists. And validation shapes (in the spirit of [SHACL](https://www.w3.org/TR/shacl/)) are a bigger day-to-day win than most teams expect, because the moment the graph can push back is the moment it stops being a passive store. The top rung is the reasoner: axiomatic entailment, deduction. The rung Talisman correctly observes nobody ships. It is only a matter of time before this arrives as a scalable capability in the agentic era. But most teams are not prepared to start there, for a simple reason: **reasoning over an unresolved, ungoverned graph just produces confident nonsense faster.** A reasoner is an amplifier. Point it at a graph where entities are duplicated, definitions are unvalidated, and nothing is versioned, and it will derive garbage with perfect logical rigor. The lower rungs are not a delay on the way to reasoning. They are its preconditions. ## Even a reasoner needs an interpreter One more layer that the formal debate tends to skip, raised by a commenter on Talisman's piece: even with a working reasoner, outputs have to be interpreted by people who were not in the room when the model was built. Inference does not exempt you from interpretation. This is why I weigh provenance and human validation so heavily on rung 0. An answer that arrives with its derivation path (these entities, these relationships, these definitions, validated by this person, under this model version) can be interpreted, challenged, and corrected. An answer that arrives bare is a liability even when it is right, and in regulated settings, especially then. It's an open secret that generative models are increasingly shouldering the burden of reasoning in agentic architectures. If production systems are to rely on this reference architecture, then _the derivation path is the only part of the answer a human can actually audit._ ## What I would hold any vendor to, including us The industry is converging on the right ambitions: sovereign meaning, persistent knowledge infrastructure, semantics a machine can compute with. Talisman is right that the current products stop short of the logic, and right to say so with receipts. The neurosymbolic research consensus ([Hitzler et al.](https://doi.org/10.1093/nsr/nwac035) is a canonical reference) says the destination is real: symbolic structure supplies the stability, consistency, and explainability that statistical models lack on their own. So hold every vendor, including the one I work for, to the ladder. Ask which rung they are on today, not which rung their roadmap gestures at. Ask whether meaning can leave their runtime in open structure, and whether it stays inside your boundary at inference time. Ask who validates an inferred definition before an agent uses it. And be suspicious of anyone who claims the top rung; as of this writing, the honest answer from the entire industry is "not yet." The word "ontology" will keep stretching in whatever direction the next product launch needs. Climb the ladder in order anyway. _Sources and further reading: _[_Jessica Talisman, "Not an Ontology"_](https://jessicatalisman.substack.com/p/not-an-ontology)_ (Intentional Arrangement, June 2026); _[_Thomas R. Gruber, "A Translation Approach to Portable Ontology Specifications"_](https://doi.org/10.1006/knac.1993.1008)_ (1993); W3C _[_Semantic Web standards_](https://www.w3.org/standards/semanticweb/)_ and _[_SHACL_](https://www.w3.org/TR/shacl/)_; _[_Hitzler et al., "Neuro-symbolic approaches in artificial intelligence"_](https://doi.org/10.1093/nsr/nwac035)_ (National Science Review, 2022); _[_Kent Stoker, "The Squishy World of Context Graphs"_](https://www.hpcwire.com/bigdatawire/2026/06/18/the-squishy-world-of-context-graphs/)_ (BigDATAwire, June 2026); the _[_Open Semantic Interchange_](https://open-semantic-interchange.org/)_ initiative, recently renamed _[_Apache Ossie (Incubating)_](https://www.snowflake.com/en/blog/apache-ossie-open-semantic-interchange-incubator/)_, an open interchange effort worth watching; _[_EU AI Act implementation timeline_](https://artificialintelligenceact.eu/implementation-timeline/)_._ ## FAQ ### Is a knowledge graph the same thing as an ontology? No. An ontology is a governance layer: it is where classes, properties, and constraints are defined, and where meaning lives. A knowledge graph is the runtime artifact those definitions govern: materialized entities and relationships, optimized for traversal at query time. The mature architecture uses both, each where it is strong. ### Why does inheritance matter so much? Inheritance is what Talisman rightly calls the most basic ontological relation. Once "a Policy is a Contract" is declared, everything the model knows about contracts applies to policies for free, and its absence is a fair test of any product using the word "ontology." ### Can you skip straight to formal inference? No. A reasoner is an amplifier. Run one over a graph with duplicated entities, unvalidated definitions, and no versioning, and it produces confident nonsense faster. The lower rungs are not a delay on the way to reasoning; they are its preconditions. ### Property graph or RDF and OWL for an enterprise ontology that agents query at runtime? The fork is a false one, because the two do different jobs at different layers. Meaning belongs in open, vendor-neutral structure such as RDF, OWL, and JSON-LD, so it can leave the building; execution belongs in a traversal-optimized runtime. The real question for an enterprise ontology that agents query at runtime is whether the runtime graph is grounded in an open model, because then portability is a property of the architecture. --- # Metric status is a trust signal, not paperwork. URL: https://zaimler.ai/blog/metric-status-trust-signal Last updated: 2026-08-07 What draft, published, and certified have to mean now that agents read the catalog too, and why the labels you already have are quietly running your board deck. ## The short version - Metric lifecycle labels like draft, published, and certified were documentation in the human era. Once agents read the catalog, a status that does not gate invocation programmatically might as well not exist. - Every state has to answer three questions in a policy file an agent loads at startup: who can invoke a metric in this state and in what mode, how the agent describes it to the user, and how much the definition can change silently. - Enforcement takes four gates, not one: retrieval filters the candidate set, the planner checks named metrics, the compiler resolves the full dependency chain, and the executor re-verifies state and hash before running. - Certified stands for four guarantees at once: an accountable signed review, a hash bound to the definition, monitored upstream freshness, and automatic downgrade on drift. Without that machinery the badge and the metric's health quietly come apart. - Deprecation works as two states: deprecated redirects to its replacement instead of executing, and retired stays readable for lineage but no longer compiles. An analyst asks a chat assistant: _what was our net revenue retention last quarter?_ The agent finds a metric called `net_revenue_retention`, runs it, returns 118%. The analyst nods. The number goes into a board deck. Nobody in that loop checked whether the metric that ran was the one finance actually uses. There are three definitions of NRR in the catalog. One came from a 2022 spreadsheet a departing PM committed as YAML. One is what the controller uses in the monthly close. One is a draft someone started when the CFO asked for a new cut, then abandoned. All three compile. All three return numbers. Two of them are wrong. The assistant did exactly what it was asked. The failure is in retrieval: the agent reaches the catalog through a tool server, semantic search ranks the candidate definitions by embedding similarity, and all three come back as plausible matches for the same question. The agent picks one. The candidate set should never have contained two of the three. ![Three catalog definitions of net_revenue_retention: an unverified 2022 draft the agent picks (118%), the controller's certified monthly-close metric (104%), and an abandoned draft (127%). All three compile; the draft's number ships into the board deck.](https://mindful-life-e47e725b32.media.strapiapp.com/fig1_three_nrr_definitions_8442cbb4e8.png) Fig. 1 · The retrieval problem the semantic layer was never designed to solve, and what it costs downstream. ## Agents lost the periphery that made sloppy status survivable. Every semantic layer has a lifecycle. Draft, published, certified, deprecated, retired. The names vary across dbt Semantic Layer, Cube, LookML, and the homegrown YAML trees most teams actually run, but the shape is the same. In the human era these labels were mostly documentation. A steward set them, a dashboard grouped by them, someone occasionally remembered to check. They could be sloppy because the human running the query brought their own trust calibration in parallel. They knew who owned the metric. They noticed when a number felt off. They asked in Slack. Status was one signal among many, and usually the weakest one. Agents have no such periphery. They see the catalog, the definition, the compiled query, the result. Nothing else. If status does not gate the invocation programmatically, it might as well not exist. The stakes differ from ordinary retrieval failure, too. When a document pipeline surfaces the wrong source, the user gets text that reads slightly off, and an attentive reader catches it. When metric retrieval surfaces the wrong definition, the user gets a number. Numbers do not read as off. They get pasted into decks. ## What a status has to actually specify. So what does it take to make a state name executable rather than decorative? For every state in your catalog, whether that is draft, published, certified, deprecated, retired, or whatever custom one your team invented, you have to be able to answer three questions in a config file that an agent loads at startup. 1. **Who is allowed to use a metric in this state, and in what mode?** Can a background agent pull it on a schedule? Only if a user names it directly? Only inside a chat where a human reads the answer before acting on it? Nobody at all? 1. **How does the agent describe it to the user?** "This is the certified NRR metric" is a very different sentence from "this is a draft owned by Jamie, not reviewed." The state decides which one the agent is permitted to say. 1. **How much can the definition change silently?** A draft should churn freely; its author is still iterating. A certified metric changing without a signal is a bug, because whoever reads the result believes they are getting the same number they got yesterday. The first question has three answers rather than one, and that split carries more weight than it looks. There are three ways a metric gets invoked and they run very different risks. A scheduled agent picks the metric itself and no human reads the result before it lands somewhere. A user in a chat names a metric explicitly, so they chose it and they will read what comes back. Or a user asks a topical question and the agent chooses on their behalf, with a human still reading the answer. The more discretion the agent has, and the less oversight there is downstream, the higher the bar a metric has to clear. Written out, that is a policy file rather than a planner prompt or a condition scattered through retrieval SQL: ```yaml states: draft: eligibility: { autonomous: false, hitl_named: true, hitl_topic: false } confidence_framing: "draft; not reviewed" change_discipline: { hash_stable: false, notify_on_change: false } certified: eligibility: { autonomous: true, hitl_named: true, hitl_topic: true } confidence_framing: "certified" change_discipline: { hash_stable: true, notify_on_change: true } ``` Fill those rows in for every state you have defined. If you can, the state model is real, and an agent can act on it. If you cannot, if `certified` sits in your catalog but you cannot say what it authorizes an agent to do that `published` does not, then `certified` is a badge. Delete it, merge it into its neighbor, or work out the rule. > If you cannot answer eligibility programmatically for a state, it is not a lifecycle stage. It is a label. And agents do not read labels. ## Four gates, not one. The obvious place to enforce that policy is retrieval. Filter the candidate set before the agent ever sees it: ```sql WHERE state IN (:allowed_states) AND (visibility = 'global' OR owning_team IN :caller_teams) ``` Do this first. It solves the three-NRR problem in its most common form. But there is a decision inside the retrieval step that most catalogs get wrong, and it quietly undermines everything built on top of it. Being findable by name and being selectable by topic are two different privileges. A team-local metric should have the first and not the second: its owners can call it up whenever they want it, but it never surfaces as the answer to someone else's general question. That takes two retrieval paths with two different filters. ```sql -- topical retrieval: only globally eligible states WHERE state IN ('published', 'certified') AND visibility = 'global' -- name resolution: broader, scoped to the caller WHERE name = :requested AND (visibility = 'global' OR owning_team IN :caller_teams) ``` Collapse those into one path and unpublished metrics either leak into everyone's search results or become invisible even to the people who wrote them. Either way, the organization starts treating unpublished as a backlog to clear. Certification turns into an OKR, the OKR turns into a rubber stamp, and the catalog fills up with certified definitions nobody uses. Two paths let unpublished stay what it usually should be: a perfectly good place for a metric to end up, whether it was exploratory, team-local, or written to answer one question in one meeting. Even with both paths correct, retrieval by itself still leaks in three ways. Each one needs its own gate. ![Four enforcement gates in the agent pipeline: retrieve filters ineligible states, plan checks named metrics against caller tier, compile resolves every referenced entity, execute re-verifies state and hash before running. One policy file, loaded at startup.](https://mindful-life-e47e725b32.media.strapiapp.com/fig2_four_enforcement_gates_ed70800e35.png) Fig. 2 · Four gates, four distinct invariants. Each one catches a class the others miss. **A user can name the metric outright.** Ask for the draft NRR that Jamie was building and retrieval never ran at all; the planner resolved that name directly. So the planner needs a check of its own. Is this caller, working in this mode, allowed to invoke a metric in this state? **A clean metric can rest on a broken one.** A certified definition references dimensions, joins and sources that carry states of their own, and any one of them might be deprecated or retired. Filtering the metric tells you nothing about what sits underneath it. Compiler has to resolve the full dependency chain and fail closed if any link in it is ineligible. **Status can change after the plan is made.** In a long-running autonomous workflow, minutes pass between choosing a metric and running it. A definition that was published at 09:03 can be deprecated by 09:11 because someone found a bug. So the executor takes one last cheap look at state and definition hash, and aborts and re-plans if either moved. Four gates, not one. The useful question is never _where to put the status check_. It is _what each layer is responsible for guaranteeing_. ## Certified means the contract, not the label. That last gate is only worth running if the contract it checks is worth something. So what should certification actually guarantee? Done properly, `certified:true` is exactly the signal you want an agent to trust, because it stands for four guarantees at once. An accountable owner reviewed and signed the definition. That signature is bound to a hash of the definition. Upstream freshness is monitored against an agreed SLA. And any drift, in the definition, the pipeline, or the source data, downgrades the state automatically. When all four hold, the green badge really does mean the number is trustworthy. That is what the contract is for. The trap is shipping certification without any of that machinery, as a decorative label on a YAML file. Two things that ought to be the same thing then come apart: the badge, stamped once when somebody reviewed it, and the metric's actual health, determined fresh on every run. Nothing keeps them in sync, and nobody notices, because every interface shows the badge and none of them show the health. Keeping the two together means returning them together. The answer envelope should carry the evidence, not just the verdict: ```json { "value": 104.1, "metric": "net_revenue_retention", "state": "certified", "cert_actor": { "role": "finance_controller", "at": "2026-07-01" }, "definition_hash": "sha256:9c1b…", "upstream_freshness_at": "2026-07-10T03:14:00Z" } ``` `cert_actor` is in there because who signed matters as much as the fact that somebody did, and most state models throw that away. A metric certified by an automated lint pass is a different claim from one certified by the finance controller. Both are legitimate. They justify different things. Keeping the distinction means recording transitions as append-only events instead of overwriting a column: ``` (metric_id, from_state, to_state, actor_role, basis_ref, at) ``` `basis_ref` points at whatever authorized the change: the controller's memo, the reviewed PDF, the ticket. Policy then reads the actor rather than the bare label. A controller-signed metric can run in an autonomous workflow; a lint-signed one stays restricted to sessions where a human reads the answer. The hash does the rest of the work. Certification signs the definition, the same way a build signature covers an artifact in a software supply chain, so if the definition changes the signature stops matching and the state downgrades on its own. Nobody has to re-run a review to catch silent tampering. Freshness comes from the pipeline and travels alongside, which means a stale certified metric is visibly stale rather than quietly wrong. Build it that way and `certified:true` earns the trust it asks for. Build it as a label and it lies to you. ## Deprecation has to have teeth. Retirement is where the real damage accumulates. A metric gets superseded, the replacement gets certified, and the old definition keeps sitting in the catalog because nothing actively removes it. It still compiles. It still returns a number. An agent scanning for `net_revenue_retention` finds both. Absent an enforced deprecation state, there is no reason to expect it picks the current one. Which is why deprecation is cleaner as two states rather than one. ![Table of five metric lifecycle states (draft, published, certified, deprecated, retired) and what each answers for autonomous use, topical use with a human, and change discipline, with the lifecycle as a timeline beneath.](https://mindful-life-e47e725b32.media.strapiapp.com/fig3_metric_lifecycle_states_a7307c942d.png) Fig. 3 · Every state answers the same three questions. Two states sharing all three answers means one state wearing two names. A `deprecated` metric fails topical retrieval outright. If a user names it explicitly, the resolver hands back a `replaced_by` pointer instead of an execution plan, and the agent surfaces that redirect rather than quietly running the successor. A `retired` metric stays readable for lineage and back-testing but is no longer executable, so compile fails closed. The two-step matters. It keeps historical metrics auditable without leaving them armed in the live path. Skipping the deprecated step is why most metric graveyards are indistinguishable from most metric catalogs. ## What happens to the three NRRs. Run the opening scene again with the contract in place. The 2022 spreadsheet definition is a draft, so retrieval excludes it from the topical candidate set and the analyst's question never surfaces it. The planner will only invoke it if someone on the owning team names it outright. The abandoned CFO cut is the same story. The controller's monthly-close definition is certified, hash-signed against the controller's own sign-off with freshness live from the pipeline, so it comes back as the single eligible candidate. The agent returns 104% and frames it as certified. The number that ships is the number that is right. Now the harder version of the question, and the one worth sitting with: what if two of the three were both certified? Suppose an EMEA finance team certifies its own regional NRR under the same public name. The state contract alone does not resolve that, and pretending otherwise would be dishonest. Two things narrow it. Actor and scope. A controller-signed, globally-scoped metric outranks a team-signed, locally-scoped one at topical retrieval, because a topical question from an unscoped user is asking for the globally eligible answer. That is precisely why `cert_actor` belongs in the envelope rather than being flattened into a boolean. And if two candidates genuinely tie on both axes, the honest answer is that runtime is the wrong place to fix it. Name uniqueness within the certified tier is a governance rule the catalog owner enforces at authoring time. A runtime contract can refuse to guess; it cannot invent an authority that was never established. ## The label and the contract. Status was paperwork when humans were in the loop. It is runtime infrastructure now that agents are. Every state your semantic layer defines has to answer, in code rather than in a wiki page: what can an agent do with a metric in this state, at each gate in the pipeline, and what does it owe the user when it does? If you cannot answer that programmatically for a state you have defined, that state is not a lifecycle stage. It is a label. And agents do not read labels. _Sharvari is an engineer on the Intelligence pod at zaimler, the runtime context layer for AI agents._ ## FAQ ### How are teams marking which data an agent is allowed to trust? By making the state contract executable rather than decorative. Every lifecycle state in the metric catalog has to answer three questions in a policy file the agent loads at startup: who can invoke a metric in this state and in what mode, how the agent frames it to the user, and how much the definition can change silently. ### How are teams handling business definitions before the agent ever touches the warehouse? Gate retrieval on state and scope, so ineligible definitions never enter the candidate set. Topical retrieval should surface only published and certified, globally visible metrics; resolving a metric by name is broader but scoped to the caller's team. That way the wrong definitions are excluded before the agent picks, instead of corrected after. ### What should a certified metric actually guarantee? Four things at once: an accountable owner reviewed and signed the definition, the signature is bound to a hash of that definition, upstream freshness is monitored against an agreed SLA, and any drift downgrades the state automatically. Built that way, the green badge earns the trust it asks for. ### Why does an agent pick the wrong metric definition? Because retrieval chooses the candidates and ranks definitions by embedding similarity, so an abandoned draft and the controller's certified metric both come back as plausible matches for the same question. The fix sits upstream of the model: the candidate set should never have contained the ineligible definitions. --- # Context Layer: Feature or Platform? URL: https://zaimler.ai/blog/context-layer-feature-or-platform Last updated: 2026-08-07 What talking to your data actually requires, and ten questions that follow from it _This is the condensed argument. The full version, which works through each question in detail, is _[_here_](/blog/context-layer-feature-or-platform-extended)_._ ## The short version - Nobody argues about whether a context layer is needed anymore. The disagreement is about where context lives: inside a platform you already run, or as its own layer that many tools and agents resolve against. - A feature is the right choice when the context powers a single solution, for one team, with nothing else expected to resolve against it, or when the work is a proof of concept. Its reach ends at its host platform's boundary, where it answers from the portion it can see with no warning that the picture is partial. - A platform pays its machinery cost up front and must earn adoption rather than inherit it; built once, the tenth context is largely configuration. The crossover point is organization-specific. - The consumer of context is shifting from a person, who compensates for a partial answer, to an agent, which cannot and is asked to act on the result. - Take the ten questions you most want an agent to answer and test each for single-platform reach, repeatability next quarter, and a traceable explanation. The number that passes tells you what to build. A question I increasingly get asked is: we know we need a context layer, but should we expect this to be a feature built in an existing solution, or should we consider this as a platform in its own right? Nobody argues about whether a context layer is needed anymore. That discussion is over. Agents that hallucinate, that take too long and then fail to provide an answer, that keep giving different answers to the same question, or that can only work on small sets of data are demos. Everyone has now seen enough demos. The disagreement is about where context lives. One camp says inside the tools you already run: a semantic model in the warehouse, a metrics layer in the BI tool. The other says it is its own layer, with its own lifecycle, that many tools and agents resolve against. Let me say up front that I have a strong opinion on this topic based on more than two decades building technology in this space. I have been part of projects that were spectacular failures, great successes and everything in between. From these battle scars, I believe I have a good sense of what works and what the right questions to ask are when it comes to context layers. So I set out both answers to each question below and leave you to weigh them. Several have a genuinely strong feature-based answer, and I say so where they do. ## Start with what you are actually trying to build Almost every organization asking this question wants the same two things: people who can ask questions of their data in plain language, and agents that can act on the answers. Being precise about what that requires matters, because for several of the questions below the answer differs for an agent and for an analyst. Talking to data reliably requires five things: - **Breadth.** Reaching every system that holds an authoritative fact about the entity - **Consistency.** The same question resolving the same way twice - **A stable contract.** An interface that does not change shape between releases - **Predictable latency under concurrency.** Thousands of questions at once rather than twelve - **Explainability.** A traceable account of which definition and sources produced an answer A person compensates for the absence of most of these. They notice that a number looks wrong, or remember that a field changed meaning after a migration, and go and ask someone. Human judgment has been the error-correction layer in every analytics stack we have built, which is why weak context has been survivable for twenty years. An agent has no such faculty. It answers confidently from whatever it can reach, without telling you the picture was partial, and is then asked to act on the result. That shift in consumer is why this question is now urgent rather than academic. ## What are we actually choosing between? Context as a feature is context that is built and maintained as a capability within a platform such as [Snowflake](https://www.snowflake.com), [Databricks](https://www.databricks.com) or [Microsoft Fabric](https://www.microsoft.com/en-us/microsoft-fabric). Many platforms are indeed working on building such a feature. These contexts are governed by the permissions of those platforms, built and consumed by its users, and data is accessible only within its specific purview. A context platform is an independently addressable layer with its own lifecycle. It sits on top of existing platforms and provides one data model over all your data, and ensures consistency across teams. It is a data plane that anything can query, with a clear opinion of versioning, owners, governance, and a data access policy. Here is what both have in common, and it matters: neither invents data. Both stand on storage you already own. There is always a lake underneath; the argument is about how much of it the context can see. A feature lives inside a specific lake and is bounded by what is accessible within that lake. A platform sits above them, bounded only by what you connect. ![Diagram comparing context as a feature and context as a platform. In both, business users, applications, and AI agents consume context over storage lakes. On the feature side the context feature sits inside Platform A and reaches only Lake A, so reach ends at the platform boundary. On the platform side a context platform with a unified model, versioned and governed, connects to Lakes A, B, and C, so reach extends to every connected source and every consumer resolves against one definition.](https://mindful-life-e47e725b32.media.strapiapp.com/context_layer_figure_1_where_context_sits_fbfae3370f.png) FIGURE 1 — The same consumers in both cases; what differs is how much of the estate they can reach. ## The question that comes before the others First establish whether you are building something durable. If the context you need powers a single solution, for one team, with nothing else expected to resolve against it, a feature is appropriate and the rest of this analysis does not apply. The same holds for a proof of concept, which is one of the least expensive ways to learn what your context actually needs to be. The failure I see most often is choosing correctly and then not honoring the choice. A proof of concept that quietly becomes production is how organizations end up with partial implementations that were never designed to work together, and agents that answer differently depending on which one they reach. Two disciplines prevent it: record that the work is disposable where your sponsor will see it, and set a date for its removal. ## Ten questions, and both answers to each | Question | A feature-based answer | A platform-based answer | | --- | --- | --- | | 1. Is this a one-off or a proof of concept? | Built inside the platform already in use; the shortest path to an answer | Disproportionate for a single use case | | 2. Who and what will resolve against it? | The platform's users and agents working inside it | Any consumer holding a contract, including agents elsewhere | | 3. How many stores must it reach across? | Those the host platform can access | Those you choose to connect | | 4. Is the tenth context cheaper than the first? | Each is scoped and built for its own use case | Each reuses the same generation and resolution machinery | | 5. How quickly does it deliver first value? | Weeks, using capability that already exists | No more than a quarter before the layer is queryable | | 6. How does marginal cost behave? | Largely repeated for each use case | Front-loaded, then declining | | 7. Who owns and maintains it in year three? | The vendor owns the runtime; the team owns the model | A named internal owner holds both | | 8. Will the same question return the same answer twice? | Within one context yes; across several, not necessarily | Yes, because one definition is resolved centrally | | 9. How are overlapping definitions handled? | Within each platform, by the team that built it | In a shared model, with the overlap recorded | | 10. How is an agent's answer explained afterwards? | By reconstructing it in each platform involved | From the layer's lineage and version history | The three sections below group these questions; the full version works through all ten. ## Demand: who consumes it, and how far must it reach **The feature case, and its cost.** Consumers are already in the tool, so there is no new interface to adopt and permissions are already provisioned and audited. Adoption is the most common reason context work fails, and a feature starts with it solved; colocation with compute adds query pushdown, no data movement and a single security model. Where an agent's work stays inside one platform's data, that is sufficient. What it gives up is reach. A feature's reach ends where its host platform's reach ends, and it does not fail cleanly at that boundary: asked about an entity spanning three systems, it answers from the portion it can see with no indication that the picture was partial. **The platform case, and its cost.** A platform is built as an interface: versioned, testable against consumer contracts, queryable by anything with credentials, and extended rather than duplicated when a source is added. Against that, it adds a hop and a second security model to reconcile with the ones you already run, [federated query performance](https://en.wikipedia.org/wiki/Federated_database_system) across heterogeneous stores is genuinely difficult, and latency under concurrency, precisely what agents stress, is harder to predict than inside a single engine. Adoption must also be earned rather than inherited. ## Economics: what it costs to build, to repeat, and to own **The feature case, and its cost.** First value arrives in weeks rather than quarters, and momentum is how data initiatives survive funding cycles. A feature spends only on what was required and inherits upgrades, disaster recovery, an on-call rotation, and certifications your auditors have already accepted. What it gives up is that marginal cost declines slowly, since what carries between use cases is the team's learning rather than reusable machinery. Change absorption grows with each context, and reconciliation, establishing why two contexts disagree and which is correct, appears in no business case and eventually dominates. It also arrives sooner than it used to, because agents surface the disagreement immediately and in front of the business. **The platform case, and its cost.** The expensive part is machinery: generating a model from sources you already have, mapping it, resolving entities across systems, testing that it holds when a schema shifts, and versioning what changes. Built once, the tenth context is largely configuration. Against that, the cost is front-loaded and incurred before any return, the crossover point is uncertain when you must decide, and if the machinery proves not to be general you pay the up-front cost without the amortization. You also own a runtime, and therefore a funded team. ![Line chart of cumulative cost of ownership against use cases delivered, an illustrative shape rather than benchmarked figures. The feature line rises steadily because cost repeats for each use case. The platform line starts higher, with the initial build paid once, then flattens. The lines cross between the third and fourth use case, after which the platform is cheaper per use case. The crossover point is organization-specific.](https://mindful-life-e47e725b32.media.strapiapp.com/context_layer_cco_chart_7c4f6e1942.png) FIGURE 2 — Illustrative shape: cost repeats per use case for a feature; a platform's upfront build flattens after the crossover, which is organization-specific. This is also where I would hold a platform to account. One that cannot deliver a business-visible use case within eight to twelve weeks is being mismanaged rather than misconceived. The shape that works is one entity, resolved across two real sources, answering a question a named person cares about. ## Control: consistency, change, and explanation Consistency and explainability were negotiable when a person read the answer. They are not when software acts on it. **The feature case, and its cost.** Domain autonomy is a genuine virtue, and the history favors it: a generation of [master data management](https://en.wikipedia.org/wiki/Master_data_management) programs set out to define the customer and consumed years producing models so negotiated they described nobody's actual business. Change has a small blast radius, and nothing new has to be certified. What it gives up is that overlaps get discovered rather than managed, and are then settled in meetings with no record of the outcome. An agent asking how many customers there are gets a different answer depending on which context it reaches, and cannot say which definition it used. Context also goes stale silently, and explaining an answer means reconstructing it in every platform involved. **The platform case, and its cost.** Governance is the stronger of two gains. A single point of control means one place to set policy, and one lineage graph and version history to consult when someone asks why an agent answered as it did. The other gain is consistency: one definition, resolved centrally, so the same question returns the same answer. Neither requires a canonical enterprise model. The machinery is shared, the modeling stays with the domains, and where two domains genuinely disagree the platform records both definitions and the relationship between them. The costs sit elsewhere: that point of control must be built and certified rather than inherited, change discipline becomes mandatory because a bad change now reaches every agent at once, and making definitional conflict visible means somebody has to arbitrate it. ## Where the analysis leads me A feature is the right decision in a narrower set of circumstances than it is currently chosen for, and outside them what makes it inexpensive for the first use case is what makes it expensive by the seventh. But the consideration that settles it for me is the one I opened with. The consumer of context is shifting from a person who could compensate for a partial answer to software that cannot, and that will be asked to act on what it is told. Breadth, consistency, a stable contract and a traceable explanation are what make an agent trustworthy, and all four are properties of an interface rather than of a model embedded in one tool. Where an agent's work stays inside a single platform's data, a feature provides all four. Where it does not, no feature can, and the shortfall surfaces as a confident answer drawn from part of the picture, with no error raised. So take the ten questions you most want an agent to answer, and for each ask three things: can it be answered from data inside a single platform, will it return the same answer next quarter, and can you show which definition and which sources produced it? The number that passes all three tells you what you need to build. I would be interested to hear where others have landed, particularly from anyone who took the feature path deliberately and would choose it again. _The full version, which works through each question in detail, is _[_here_](/blog/context-layer-feature-or-platform-extended)_._ ## FAQ ### Where does a context layer sit in my data stack? Above the storage you already own and below the consumers that ask questions of it: business users, applications, and AI agents. Neither version invents data. A context feature sits inside one platform and sees what that platform can access; a context platform sits above all of them, bounded only by what you connect. ### Is a context feature inside Snowflake, Databricks or Microsoft Fabric enough for AI agents in production? Where an agent's work stays inside that one platform's data, yes. Adoption starts solved, permissions are already provisioned and audited, and colocation with compute adds query pushdown with no data movement. The limit is reach: asked about an entity spanning several systems, a feature answers from the portion it can see without indicating the picture was partial. ### When is a context layer as a feature the right choice? When the context powers a single solution, for one team, with nothing else expected to resolve against it, or when the work is a proof of concept. The discipline that matters is honoring that choice: record that the work is disposable where your sponsor will see it, and set a date for its removal. ### What does a context platform cost compared with building context per use case? The platform's cost is front-loaded machinery, incurred before any return: generating the model, mapping it, resolving entities, testing it against schema change, and versioning it. If the machinery proves general, the tenth context is largely configuration, while a feature's cost largely repeats per use case and reconciliation between contexts eventually dominates; if it does not, you pay the up-front cost without the amortization. The crossover point is organization-specific, and a platform that cannot show a business-visible use case within eight to twelve weeks is being mismanaged. ### How is an AI agent's answer explained after the fact? On a context platform, from the layer's lineage and version history: one place records which definition and which sources produced the answer. With context built per platform, explaining an answer means reconstructing it in every platform involved, and the agent cannot say which definition it used. --- # Privacy Policy URL: https://zaimler.ai/privacy-policy Last updated: 2026-06-25 THIS PRIVACY POLICY (“POLICY”) EXPLAINS HOW ZAIMLER, INC. (“ZAIMLER,” “WE,” “US,” OR “OUR”) COLLECTS, USES, AND DISCLOSES PERSONAL INFORMATION IN CONNECTION WITH THE WEBSITE LOCATED AT ZAIMLER.AI AND ANY RELATED ZAIMLER WEBPAGES, CONTENT, AND FEATURES (COLLECTIVELY, THE “SITE”), AND WITH OUR SALES, MARKETING, AND RECRUITING ACTIVITIES. BY USING THE SITE, YOU ACKNOWLEDGE THE PRACTICES DESCRIBED IN THIS POLICY. THIS POLICY COVERS PERSONAL INFORMATION THAT ZAIMLER HANDLES AS A CONTROLLER THROUGH THE SITE AND ITS BUSINESS OPERATIONS. IT DOES NOT COVER PERSONAL DATA THAT ZAIMLER PROCESSES ON BEHALF OF ITS CUSTOMERS WITHIN ZAIMLER’S PRODUCTS, PLATFORM, OR HOSTED SERVICES, WHICH IS GOVERNED BY THE SEPARATE AGREEMENT AND DATA PROCESSING ADDENDUM BETWEEN ZAIMLER AND THE RELEVANT CUSTOMER. IF YOUR PERSONAL DATA WAS PROVIDED TO ZAIMLER BY A CUSTOMER THAT USES OUR SERVICES, PLEASE DIRECT PRIVACY REQUESTS TO THAT CUSTOMER. ### **1. Information We Collect** We collect personal information in the following ways: i. Information you provide. When you complete a form, request a demo, contact us, subscribe to communications, or apply for a job, we collect the information you submit, which may include your name, business email address, telephone number, employer, job title, the contents of your message, and, for job applicants, your resume and related materials. ii. Information we collect automatically. When you use the Site, we and our analytics providers automatically collect device and usage information, such as your IP address, browser type, operating system, pages viewed, referring and exit pages, and the dates and times of access, using cookies and similar technologies. iii. Information from third parties. We may receive business contact information and related details from lead-generation, data-enrichment, marketing, referral, and social media sources, and from our affiliates and partners. ### **2. How We Use Personal Information** We use personal information to respond to your inquiries and requests; to provide, operate, maintain, and improve the Site; to send marketing and promotional communications, subject to your choices; to understand how the Site is used and to conduct analytics; to protect the security and integrity of the Site and our business; to recruit and evaluate candidates; and to comply with legal obligations and enforce our agreements. ### **3. Legal Bases for Processing** Where the GDPR or a similar law applies, we process personal information based on your consent; our legitimate interests in operating, securing, and promoting our business, balanced against your rights and interests; the performance of a contract or steps taken at your request; and compliance with our legal obligations. Where we rely on consent, you may withdraw it at any time. ### **4. Cookies and Similar Technologies** We use cookies and similar technologies as described in the Cookies section of our Website Terms of Use. You can accept, decline, or change your choices at any time using the cookie controls available on the Site, and through your browser settings. ### **5. How We Disclose Personal Information** We do not sell your personal information. We disclose personal information to service providers and processors that perform services on our behalf, such as hosting, analytics, customer-relationship management, email delivery, and security, under contracts that limit their use of the information; to our affiliates and professional advisors; and to government authorities or other parties where we believe disclosure is necessary to comply with law, enforce our agreements, or protect the rights, property, or safety of zaimler, our users, or others. We may also disclose personal information in connection with a merger, acquisition, financing, or sale of assets. To the extent we use advertising or analytics technologies that are considered a “sale” or “sharing” of personal information under applicable law, we provide the opt-out controls described in the “Your Privacy Rights” section. ### **6. Data Retention** We retain personal information for as long as necessary to fulfill the purposes described in this Policy, including to satisfy any legal, accounting, or reporting requirements, after which we delete or de-identify it. ### **7. Data Security** We maintain administrative, technical, and physical safeguards designed to protect personal information. No method of transmission or storage is completely secure, however, and we cannot guarantee absolute security. ### **8. International Transfers** We are based in the United States and may process personal information in the United States and other countries whose data-protection laws may differ from those in your jurisdiction. Where required, we rely on appropriate safeguards, such as standard contractual clauses, for cross-border transfers. ### **9. Your Privacy Rights** Depending on where you live, you may have the right to access the personal information we hold about you; to correct or update it; to request its deletion; to object to or restrict certain processing; to receive a copy in a portable format; to withdraw consent; and to opt out of the “sale” or “sharing” of personal information or of targeted advertising. We will not discriminate against you for exercising these rights. To make a request, email [info@zaimler.ai](mailto:info@zaimler.ai), and we will verify and respond as required by applicable law. If you are in the EEA or the UK, you may also lodge a complaint with your local supervisory authority. ### **10. Children’s Privacy** The Site is intended for businesses and for individuals who are at least 18 years old. We do not knowingly collect personal information from children. If you believe a child has provided us with personal information, please contact us and we will delete it. ### **11. Third-Party Links** The Site may link to third-party websites and services that we do not control and that have their own privacy practices. We are not responsible for those practices, and we encourage you to review the policies of any third-party site you visit. ### **12. Changes to This Policy** We may update this Policy from time to time. The “Last Updated” date above shows when it was last revised. Material changes take effect when we post the updated Policy or otherwise provide notice. ### **13. Contact Us** Questions or requests regarding this Policy or your personal information may be sent to [info@zaimler.ai](mailto:info@zaimler.ai). --- # Terms of Service URL: https://zaimler.ai/terms-of-service Last updated: 2026-06-25 THESE WEBSITE TERMS OF USE ("TERMS") ARE A LEGAL AGREEMENT BETWEEN YOU AND ZAIMLER, INC. ("ZAIMLER," "WE," "US," OR "OUR") THAT GOVERN YOUR ACCESS TO AND USE OF THE WEBSITE LOCATED AT ZAIMLER.AI, TOGETHER WITH ANY RELATED ZAIMLER WEBPAGES, CONTENT, AND FEATURES (COLLECTIVELY, THE "SITE"). BY ACCESSING OR USING THE SITE, YOU AGREE TO THESE TERMS. IF YOU DO NOT AGREE, DO NOT ACCESS OR USE THE SITE. THESE TERMS GOVERN YOUR USE OF THE SITE ONLY. THEY DO NOT GOVERN ACCESS TO OR USE OF ZAIMLER'S PRODUCTS, PLATFORM, OR HOSTED SERVICES, WHICH ARE MADE AVAILABLE SOLELY UNDER A SEPARATE WRITTEN AGREEMENT (FOR EXAMPLE, AN ORDER FORM OR MASTER SUBSCRIPTION AGREEMENT). THAT SEPARATE AGREEMENT GOVERNS THOSE PRODUCTS AND SERVICES AND CONTROLS OVER THESE TERMS WITH RESPECT TO THEM. ### **1. Eligibility and Authority** You must be at least 18 years old to use the Site. If you use the Site on behalf of a company or other legal entity, you represent that you have authority to bind that entity to these Terms, and "you" refers to that entity. ### **2. Changes to These Terms** We may update these Terms from time to time. The "Last Updated" date above shows when these Terms were last revised. Material changes take effect when we post the revised Terms or otherwise provide notice, and your continued use of the Site after the effective date means you accept the revised Terms. Changes do not apply retroactively. ### **3. License to Use the Site** Subject to these Terms, zaimler grants you a limited, non-exclusive, non-transferable, revocable license to access and use the Site for your own informational and internal business purposes. zaimler reserves all rights not expressly granted in these Terms. ### **4. Acceptable Use** You agree not to, and not to permit any third party to: i. use the Site in violation of any applicable law or regulation; ii. copy, scrape, harvest, frame, mirror, or systematically retrieve any part of the Site except as we expressly permit in writing; iii. reverse engineer, decompile, or attempt to derive the source code of any portion of the Site; iv. introduce any malware or code intended to disrupt, damage, or gain unauthorized access to the Site or related systems; v. probe, scan, or test the vulnerability of the Site, or breach or circumvent any security or authentication measure; vi. interfere with or disrupt the integrity or performance of the Site, including through automated means or excessive request volumes; vii. use the Site to send unsolicited communications, or to upload or transmit unlawful, infringing, harassing, or obscene material; viii. misrepresent your identity or affiliation, or use the Site to gain a competitive advantage against zaimler; or ix. remove, obscure, or alter any proprietary notice on the Site. We may suspend or terminate your access to the Site at any time for conduct we reasonably believe violates these Terms or harms zaimler, the Site, or others. ### **5. Intellectual Property** The Site and all content on it — including text, graphics, logos, images, software, and the selection and arrangement thereof — are owned by zaimler or its licensors and are protected by intellectual property and other laws. "zaimler," the zaimler logo, and related names and marks are trademarks of zaimler. These Terms do not grant you any right to use zaimler's trademarks without our prior written consent. ### **6. Submissions and Feedback** If you submit any information or materials to us through the Site (for example, through a contact or demo-request form), you represent that you have the right to do so. If you provide suggestions, ideas, or feedback about the Site or our products ("Feedback"), you grant zaimler a perpetual, irrevocable, worldwide, royalty-free license to use and incorporate that Feedback for any purpose, without obligation to you. Do not submit confidential information through the Site unless you are doing so under a separate written agreement with zaimler. ### **7. Privacy** Our collection and use of personal information through the Site is described in our Privacy Policy. By using the Site, you acknowledge those practices. ### **8. Cookies** The Site uses cookies and similar technologies, such as pixels and local storage, to operate the Site, remember your preferences, and understand how the Site is used. Cookies are small data files placed on your device. We use strictly necessary cookies that are required for the Site to function; functional cookies that remember your choices and settings; and analytics cookies that help us measure and improve the Site's performance. To the extent we use advertising or targeting cookies, we will identify them through the cookie controls described below and obtain your consent where required. Where consent is required by law, we request it before setting non-essential cookies. You can accept, decline, or change your cookie choices at any time using the cookie controls available on the Site, and you can also block or delete cookies through your browser settings; disabling some cookies may affect how the Site functions. Additional detail about how we handle personal information is set out in our Privacy Policy. ### **9. Third-Party Links and Content** The Site may contain links to third-party websites, services, or resources that we do not control. We provide these for convenience only and are not responsible for the content, products, or practices of any third party. Your use of any third-party site is at your own risk and subject to that third party's terms. ### **10. Disclaimers** The Site is provided "as is" and "as available," without warranties of any kind, whether express, implied, or statutory, including any implied warranties of merchantability, fitness for a particular purpose, title, and non-infringement. We do not warrant that the Site will be uninterrupted, error-free, or secure, or that any content on the Site is accurate, complete, or current. Content on the Site is provided for general informational purposes only and is not a binding offer or professional advice. ### **11. Limitation of Liability** To the maximum extent permitted by law, zaimler and its affiliates, officers, employees, and agents will not be liable for any indirect, incidental, special, consequential, or punitive damages, or for any loss of profits, revenue, data, or goodwill, arising out of or relating to your use of (or inability to use) the Site. To the maximum extent permitted by law, zaimler's total liability for all claims relating to the Site will not exceed one hundred U.S. dollars (US$100). These limitations do not apply to any liability that cannot be limited under applicable law. ### **12. Indemnification** You agree to defend, indemnify, and hold harmless zaimler and its affiliates from any claims, damages, liabilities, and expenses (including reasonable attorneys' fees) arising out of your use of the Site, your violation of these Terms, or your violation of any law or third-party right. ### **13. Governing Law and Disputes** These Terms are governed by the laws of the State of California, without regard to its conflict-of-laws rules. Any dispute arising out of or relating to these Terms or the Site will be subject to the exclusive jurisdiction of the state and federal courts located in San Mateo County, California, and you consent to personal jurisdiction there. ### **14. Suspension; Termination; Survival** We may modify, suspend, or discontinue all or part of the Site at any time without notice or liability, and we may suspend or terminate your access to the Site at any time. Sections that by their nature should survive — including Intellectual Property, Submissions and Feedback, Disclaimers, Limitation of Liability, Indemnification, and Governing Law and Disputes — will survive any termination. ### **15. General** These Terms, together with the Privacy Policy, are the entire agreement between you and zaimler regarding the Site and supersede any prior understandings on that subject. If any provision is held unenforceable, the remaining provisions remain in effect. Our failure to enforce any provision is not a waiver of it. You may not assign these Terms without our prior written consent; we may assign them freely. ### **16. Contact** Questions about these Terms may be sent to [info@zaimler.ai](mailto:info@zaimler.ai).