[{"data":1,"prerenderedAt":38},["ShallowReactive",2],{"blog-tag-identity":3},[4,24],{"id":5,"slug":6,"body":7,"html":8,"title":9,"description":10,"category":11,"tags":12,"author":17,"date":18,"year":19,"month":20,"quarter":21,"status":22,"featured":23},"2026\u002F08\u002Findustry-applications\u002Fgrounded-enterprise-knowledge-assistants","grounded-enterprise-knowledge-assistants","\nThe enterprise knowledge assistant is the most requested AI application and one of the most often abandoned. The pilot answers questions impressively. Then someone notices it confidently quoted a superseded policy, or showed a document the user shouldn't have seen, and trust evaporates.\n\nThose failures aren't model problems. They are **application** problems, and they have application solutions.\n\n## What a grounded assistant needs\n\nThe **knowledge and assistants** family in the Atlas is built around five requirements.\n\n**1. Approved sources only.** The assistant answers from a curated set of repositories (policies, procedures, product documentation, knowledge articles), each with an owner. Content has a lifecycle: draft, approved, superseded. Superseded content is excluded.\n\n**2. Retrieval with citations.** Every answer links to the passages it relies on. If the sources don't support an answer, the assistant says so rather than improvising.\n\n**3. Permission-aware retrieval.** Users only retrieve content they are allowed to see. Permissions come from the source systems and the identity provider, not from a separate copy that drifts.\n\n**4. Evaluation before and after launch.** A test set of real questions with expected answers and sources, run on every change to prompts, models or content. We describe the approach in [evaluation and guardrails](\u002Fblog\u002Fevaluation-and-guardrails-before-production).\n\n**5. Feedback and content ownership.** Users flag wrong or missing answers. Flags become tasks for content owners, so the knowledge base improves instead of the prompt getting longer.\n\n## Beyond Q&A\n\nOnce retrieval is trustworthy, the same foundation supports more useful workflows:\n\n- **Drafting:** first drafts of customer replies, reports or procedures, grounded in approved content\n- **Policy lookup inside other applications:** the case worker or operator sees relevant policy passages in context\n- **Onboarding:** role-specific guided learning over the procedures a new joiner needs\n- **Change impact:** when a policy changes, find the procedures and articles that reference it\n\n## Controls designed in\n\n- Answers restricted to what the user may access\n- Logging of questions, retrieved sources and answers for audit, with retention rules\n- No training on customer data by default, and a documented choice of model provider and hosting\n- Sensitive-content filters configured per deployment\n\n## Integrations\n\nDocument management and intranets, knowledge bases, ticketing systems (resolved tickets are valuable knowledge), the identity provider and directory groups, and the chat or collaboration tools where people already work.\n\n## Who uses it\n\nEveryone, which is why it needs owners: the business owner of each knowledge domain, the AI platform team, and IT for integration and access.\n\n## First scope\n\nOne domain with an owner and a clear audience, such as HR policies, IT support or a product line's procedures. Measure answer accuracy on the test set and the rate of cited answers. Scope it in a [Solution Definition Sprint](\u002Fservices\u002Fsolution-definition-sprint).\n\nExplore the [Atlas](\u002Fatlas), or [bring us your knowledge domain](\u002Fcontact).\n","\u003Cp>The enterprise knowledge assistant is the most requested AI application and one of the most often abandoned. The pilot answers questions impressively. Then someone notices it confidently quoted a superseded policy, or showed a document the user shouldn't have seen, and trust evaporates.\u003C\u002Fp>\n\u003Cp>Those failures aren't model problems. They are \u003Cstrong>application\u003C\u002Fstrong> problems, and they have application solutions.\u003C\u002Fp>\n\u003Ch2>What a grounded assistant needs\u003C\u002Fh2>\n\u003Cp>The \u003Cstrong>knowledge and assistants\u003C\u002Fstrong> family in the Atlas is built around five requirements.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>1. Approved sources only.\u003C\u002Fstrong> The assistant answers from a curated set of repositories (policies, procedures, product documentation, knowledge articles), each with an owner. Content has a lifecycle: draft, approved, superseded. Superseded content is excluded.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2. Retrieval with citations.\u003C\u002Fstrong> Every answer links to the passages it relies on. If the sources don't support an answer, the assistant says so rather than improvising.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3. Permission-aware retrieval.\u003C\u002Fstrong> Users only retrieve content they are allowed to see. Permissions come from the source systems and the identity provider, not from a separate copy that drifts.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4. Evaluation before and after launch.\u003C\u002Fstrong> A test set of real questions with expected answers and sources, run on every change to prompts, models or content. We describe the approach in \u003Ca href=\"\u002Fblog\u002Fevaluation-and-guardrails-before-production\">evaluation and guardrails\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5. Feedback and content ownership.\u003C\u002Fstrong> Users flag wrong or missing answers. Flags become tasks for content owners, so the knowledge base improves instead of the prompt getting longer.\u003C\u002Fp>\n\u003Ch2>Beyond Q&A\u003C\u002Fh2>\n\u003Cp>Once retrieval is trustworthy, the same foundation supports more useful workflows:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Drafting:\u003C\u002Fstrong> first drafts of customer replies, reports or procedures, grounded in approved content\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Policy lookup inside other applications:\u003C\u002Fstrong> the case worker or operator sees relevant policy passages in context\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Onboarding:\u003C\u002Fstrong> role-specific guided learning over the procedures a new joiner needs\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Change impact:\u003C\u002Fstrong> when a policy changes, find the procedures and articles that reference it\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Controls designed in\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>Answers restricted to what the user may access\u003C\u002Fli>\n\u003Cli>Logging of questions, retrieved sources and answers for audit, with retention rules\u003C\u002Fli>\n\u003Cli>No training on customer data by default, and a documented choice of model provider and hosting\u003C\u002Fli>\n\u003Cli>Sensitive-content filters configured per deployment\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Integrations\u003C\u002Fh2>\n\u003Cp>Document management and intranets, knowledge bases, ticketing systems (resolved tickets are valuable knowledge), the identity provider and directory groups, and the chat or collaboration tools where people already work.\u003C\u002Fp>\n\u003Ch2>Who uses it\u003C\u002Fh2>\n\u003Cp>Everyone, which is why it needs owners: the business owner of each knowledge domain, the AI platform team, and IT for integration and access.\u003C\u002Fp>\n\u003Ch2>First scope\u003C\u002Fh2>\n\u003Cp>One domain with an owner and a clear audience, such as HR policies, IT support or a product line's procedures. Measure answer accuracy on the test set and the rate of cited answers. Scope it in a \u003Ca href=\"\u002Fservices\u002Fsolution-definition-sprint\">Solution Definition Sprint\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Explore the \u003Ca href=\"\u002Fatlas\">Atlas\u003C\u002Fa>, or \u003Ca href=\"\u002Fcontact\">bring us your knowledge domain\u003C\u002Fa>.\u003C\u002Fp>\n","Grounded enterprise knowledge assistants: retrieval, citations and permissions","How to build an internal knowledge assistant people trust: retrieval over approved sources, citations, permission-aware answers and evaluation.","industry-applications",[13,14,15,16],"knowledge-retrieval","enterprise-operations","evaluation","identity","fazezero-editorial","2026-08-06T00:00:00.000Z",2026,8,3,"published",false,{"id":25,"slug":26,"body":27,"html":28,"title":29,"description":30,"category":31,"tags":32,"author":17,"date":36,"year":19,"month":37,"quarter":21,"status":22,"featured":23},"2026\u002F07\u002Ffactory-and-architecture\u002Fidentity-tenancy-and-authorization-from-the-first-commit","identity-tenancy-and-authorization-from-the-first-commit","\nAsk what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a `where` clause.\n\nIn our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\n\n## Identity\n\nEvery foundation authenticates against an **enterprise identity provider** from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\n\nService-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\n\n## Authorization\n\nAuthorization is **explicit and central**:\n\n- Roles map to permissions in one place.\n- Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\n- Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\n- Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\n\nThis is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\n\n## Multi-tenancy\n\nMany applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the **tenant as a first-class part of the data model**:\n\n- Tenant-owned records are stored and queried within the tenant's partition.\n- The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\n- Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\n- Cross-tenant views, where legitimately needed, are separate and permissioned paths.\n\nIsolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\n\n## Why generate it instead of documenting it\n\nA guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\n\n## What still happens per customer\n\nThe integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\n\nMore on the rails: [Architecture](\u002Ffactory\u002Farchitecture) · [AI accelerates, architecture governs](\u002Fblog\u002Fai-accelerates-architecture-governs)\n","\u003Cp>Ask what usually delays an AI application's go-live and the answer is rarely the AI. It's the security review. Specifically, the discovery that identity was bolted on, authorization checks are scattered through the code, and tenant isolation depends on every developer remembering a \u003Ccode>where\u003C\u002Fcode> clause.\u003C\u002Fp>\n\u003Cp>In our factory, these three concerns are part of the architecture from the first commit. They're generated into the core of every application foundation.\u003C\u002Fp>\n\u003Ch2>Identity\u003C\u002Fh2>\n\u003Cp>Every foundation authenticates against an \u003Cstrong>enterprise identity provider\u003C\u002Fstrong> from day one: OpenID Connect or SAML to Entra ID, Okta, Ping, government SSO or a national identity platform. Local development uses the same flows with a local provider. There's no “temporary” username and password table waiting to be removed.\u003C\u002Fp>\n\u003Cp>Service-to-service calls use their own identities, and AI agents act either as a service identity or on behalf of the invoking user, never with ambient superuser rights.\u003C\u002Fp>\n\u003Ch2>Authorization\u003C\u002Fh2>\n\u003Cp>Authorization is \u003Cstrong>explicit and central\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Roles map to permissions in one place.\u003C\u002Fli>\n\u003Cli>Permissions are checked in the application services layer, not in route handlers or UI code. Every entry point gets the same checks: the API, background jobs, agents and imports.\u003C\u002Fli>\n\u003Cli>Consequential actions can require a second approver (maker\u002Fchecker) as a declared policy, not ad-hoc code.\u003C\u002Fli>\n\u003Cli>Principals are re-evaluated per request, so a disabled user or a changed role takes effect immediately.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is what makes a security review short. Reviewers read one policy map instead of hunting through handlers.\u003C\u002Fp>\n\u003Ch2>Multi-tenancy\u003C\u002Fh2>\n\u003Cp>Many applications serve several tenants: business units, subsidiaries, government entities, partners, or customers of an SI. The foundations treat the \u003Cstrong>tenant as a first-class part of the data model\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Tenant-owned records are stored and queried within the tenant's partition.\u003C\u002Fli>\n\u003Cli>The tenant is taken from the authenticated principal, never from request data. A forged tenant ID in a payload is ignored.\u003C\u002Fli>\n\u003Cli>Cross-tenant requests return “not found” rather than “forbidden”, so they don't leak existence.\u003C\u002Fli>\n\u003Cli>Cross-tenant views, where legitimately needed, are separate and permissioned paths.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Isolation is tested automatically: cross-tenant reads and writes are part of every foundation's test suite.\u003C\u002Fp>\n\u003Ch2>Why generate it instead of documenting it\u003C\u002Fh2>\n\u003Cp>A guideline that says “always check the tenant” is followed until the deadline. A generated core that makes the unsafe path hard is followed every time. Because the same patterns run across the whole inventory, a weakness found in one place gets fixed in the factory and flows into every foundation that follows.\u003C\u002Fp>\n\u003Ch2>What still happens per customer\u003C\u002Fh2>\n\u003Cp>The integration with the customer's identity provider and directory, their role model and approval policies, their tenancy boundaries, and their security review. The rails are fixed, and the configuration is the customer's.\u003C\u002Fp>\n\u003Cp>More on the rails: \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> · \u003Ca href=\"\u002Fblog\u002Fai-accelerates-architecture-governs\">AI accelerates, architecture governs\u003C\u002Fa>\u003C\u002Fp>\n","Identity, tenancy and authorization from the first commit","Why identity, multi-tenancy and authorization are generated into the core of every fazeZERO application foundation instead of added before go-live.","factory-and-architecture",[16,33,34,35],"architecture","application-factory","api-first","2026-07-29T00:00:00.000Z",7,1790080513559]