[{"data":1,"prerenderedAt":73},["ShallowReactive",2],{"blog-tag-application-factory":3},[4,24,39,50,61],{"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\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",[13,14,15,16],"identity","architecture","application-factory","api-first","fazezero-editorial","2026-07-29T00:00:00.000Z",2026,7,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":20,"quarter":21,"status":22,"featured":23,"series":37,"seriesOrder":38},"2026\u002F07\u002Fai-in-production\u002Fdeployment-ready-is-not-production","deployment-ready-is-not-production","\n“Production-ready” is one of the most abused phrases in enterprise software. It usually means “the demo worked.” We avoid it on purpose.\n\nWe describe every application in one of three stages. Each stage describes what has actually happened, not what we hope will happen.\n\n## 1. Deployment-Ready Application Foundation\n\nThis is where every application in our inventory starts. A foundation has:\n\n- been generated and scaffolded on the factory architecture\n- a runnable core with domain services and adapters\n- an API structure defined by contracts\n- a web application\n- identity and authorization patterns\n- automated tests\n- a deployment baseline\n- a known, consistent architectural structure\n\nA foundation is real software, not a mock-up. But it hasn't met your data, your identity provider, your integrations or your policies. Calling it “production” would be misleading.\n\n## 2. Customer-Configured Application\n\nThe foundation has been adapted to one organization:\n\n- the customer's requirements and business workflows\n- their data and data platforms\n- integrations with their systems of record\n- AI and model choices, including providers, hosting and evaluation criteria\n- their identity environment\n- their cloud platform and regional constraints\n- their policies and approval rules\n- their operating environment\n\nThis is what an [AI Production Sprint](\u002Fservices\u002Fai-production-sprint) delivers. It is a working application on a production path, but it isn't in production yet.\n\n## 3. Production Deployment\n\nThe application has completed the customer-specific work that production actually requires:\n\n- integration testing against live systems\n- security hardening and review\n- cloud deployment in the customer's environment\n- operational testing\n- customer acceptance\n- observability and alerting\n- a support design\n- production controls\n\nOnly then do we call it production.\n\n## Why the distinction matters\n\n**For buyers**, it sets honest expectations. A foundation shortens the path to production. It doesn't remove the path. Integration, hardening and acceptance still take real effort, and a vendor who claims otherwise is either underestimating your environment or overestimating their template.\n\n**For risk and security teams**, it gives a shared vocabulary. A deployment-ready foundation can be reviewed architecturally. A customer-configured application can be reviewed against your policies. A production deployment has passed your gates.\n\n**For partners**, it prevents over-selling. A systems integrator who promises a “production-ready AI app in two weeks” is setting up the relationship to fail.\n\n## How the stages map to engagements\n\n| Stage | How you get there |\n|---|---|\n| Deployment-ready foundation | Already in the inventory, or generated by the factory |\n| Customer-configured | [Solution Definition Sprint](\u002Fservices\u002Fsolution-definition-sprint), then [AI Production Sprint](\u002Fservices\u002Fai-production-sprint) |\n| Production deployment | Completion of the production roadmap, often inside an [Application Family Program](\u002Fservices\u002Fapplication-family-program) |\n\n## What we won't do\n\nWe won't label a listing “production” because it runs. We won't describe a customer-configured application as a production deployment before acceptance. And we won't publish customer names, metrics or badges we can't evidence.\n\nIt's a small discipline. It also happens to be the one enterprise buyers trust most.\n\nRead more about [the factory](\u002Ffactory), or [bring us a use case](\u002Fcontact).\n","\u003Cp>“Production-ready” is one of the most abused phrases in enterprise software. It usually means “the demo worked.” We avoid it on purpose.\u003C\u002Fp>\n\u003Cp>We describe every application in one of three stages. Each stage describes what has actually happened, not what we hope will happen.\u003C\u002Fp>\n\u003Ch2>1. Deployment-Ready Application Foundation\u003C\u002Fh2>\n\u003Cp>This is where every application in our inventory starts. A foundation has:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>been generated and scaffolded on the factory architecture\u003C\u002Fli>\n\u003Cli>a runnable core with domain services and adapters\u003C\u002Fli>\n\u003Cli>an API structure defined by contracts\u003C\u002Fli>\n\u003Cli>a web application\u003C\u002Fli>\n\u003Cli>identity and authorization patterns\u003C\u002Fli>\n\u003Cli>automated tests\u003C\u002Fli>\n\u003Cli>a deployment baseline\u003C\u002Fli>\n\u003Cli>a known, consistent architectural structure\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A foundation is real software, not a mock-up. But it hasn't met your data, your identity provider, your integrations or your policies. Calling it “production” would be misleading.\u003C\u002Fp>\n\u003Ch2>2. Customer-Configured Application\u003C\u002Fh2>\n\u003Cp>The foundation has been adapted to one organization:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>the customer's requirements and business workflows\u003C\u002Fli>\n\u003Cli>their data and data platforms\u003C\u002Fli>\n\u003Cli>integrations with their systems of record\u003C\u002Fli>\n\u003Cli>AI and model choices, including providers, hosting and evaluation criteria\u003C\u002Fli>\n\u003Cli>their identity environment\u003C\u002Fli>\n\u003Cli>their cloud platform and regional constraints\u003C\u002Fli>\n\u003Cli>their policies and approval rules\u003C\u002Fli>\n\u003Cli>their operating environment\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This is what an \u003Ca href=\"\u002Fservices\u002Fai-production-sprint\">AI Production Sprint\u003C\u002Fa> delivers. It is a working application on a production path, but it isn't in production yet.\u003C\u002Fp>\n\u003Ch2>3. Production Deployment\u003C\u002Fh2>\n\u003Cp>The application has completed the customer-specific work that production actually requires:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>integration testing against live systems\u003C\u002Fli>\n\u003Cli>security hardening and review\u003C\u002Fli>\n\u003Cli>cloud deployment in the customer's environment\u003C\u002Fli>\n\u003Cli>operational testing\u003C\u002Fli>\n\u003Cli>customer acceptance\u003C\u002Fli>\n\u003Cli>observability and alerting\u003C\u002Fli>\n\u003Cli>a support design\u003C\u002Fli>\n\u003Cli>production controls\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Only then do we call it production.\u003C\u002Fp>\n\u003Ch2>Why the distinction matters\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>For buyers\u003C\u002Fstrong>, it sets honest expectations. A foundation shortens the path to production. It doesn't remove the path. Integration, hardening and acceptance still take real effort, and a vendor who claims otherwise is either underestimating your environment or overestimating their template.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>For risk and security teams\u003C\u002Fstrong>, it gives a shared vocabulary. A deployment-ready foundation can be reviewed architecturally. A customer-configured application can be reviewed against your policies. A production deployment has passed your gates.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>For partners\u003C\u002Fstrong>, it prevents over-selling. A systems integrator who promises a “production-ready AI app in two weeks” is setting up the relationship to fail.\u003C\u002Fp>\n\u003Ch2>How the stages map to engagements\u003C\u002Fh2>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Stage\u003C\u002Fth>\n\u003Cth>How you get there\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Deployment-ready foundation\u003C\u002Ftd>\n\u003Ctd>Already in the inventory, or generated by the factory\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Customer-configured\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"\u002Fservices\u002Fsolution-definition-sprint\">Solution Definition Sprint\u003C\u002Fa>, then \u003Ca href=\"\u002Fservices\u002Fai-production-sprint\">AI Production Sprint\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Production deployment\u003C\u002Ftd>\n\u003Ctd>Completion of the production roadmap, often inside an \u003Ca href=\"\u002Fservices\u002Fapplication-family-program\">Application Family Program\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2>What we won't do\u003C\u002Fh2>\n\u003Cp>We won't label a listing “production” because it runs. We won't describe a customer-configured application as a production deployment before acceptance. And we won't publish customer names, metrics or badges we can't evidence.\u003C\u002Fp>\n\u003Cp>It's a small discipline. It also happens to be the one enterprise buyers trust most.\u003C\u002Fp>\n\u003Cp>Read more about \u003Ca href=\"\u002Ffactory\">the factory\u003C\u002Fa>, or \u003Ca href=\"\u002Fcontact\">bring us a use case\u003C\u002Fa>.\u003C\u002Fp>\n","Deployment-ready is not production: an honest maturity model","Why we describe applications in three stages (deployment-ready foundation, customer-configured, production deployment) and never call a template 'production'.","ai-in-production",[33,15,34,35],"production","implementation","governance","2026-07-07T00:00:00.000Z","the-application-factory",5,{"id":40,"slug":41,"body":42,"html":43,"title":44,"description":45,"category":11,"tags":46,"author":17,"date":47,"year":19,"month":48,"quarter":49,"status":22,"featured":23,"series":37,"seriesOrder":21},"2026\u002F06\u002Ffactory-and-architecture\u002Fcoding-assistants-are-not-an-architecture","coding-assistants-are-not-an-architecture","\nIt is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\n\n> “Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\n\nThe honest answer is **not** that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\n\n## Implementation engines\n\nAI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\n\nWhat they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce *an* answer every time. It will not reliably produce the *same* answer every time.\n\n## Where the risk accumulates\n\nThe risks of architecture-free AI development are predictable:\n\n- **Inconsistent domain boundaries.** The same business concept lives in three services, modelled three ways.\n- **Weak API design.** Endpoints shaped by screens rather than contracts, and no versioning discipline.\n- **Late identity and authorization.** Role checks scattered through handlers, added after the demo.\n- **Inconsistent multi-tenancy.** Tenant isolation handled by convention, differently in each module.\n- **Thin testing.** Tests written to pass rather than to specify.\n- **Drift.** Regenerating a module quietly changes behaviour elsewhere.\n- **Production rework.** The prototype gets rewritten the moment it meets security review, integration or scale.\n\nNone of this is the tool's fault. It's what happens when the architecture is left to emerge.\n\n## An architectural system\n\nfazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\n\n- **Domain-Driven Design** with bounded contexts as the unit of structure\n- **OpenAPI-first contracts** validated before implementation\n- **Identity, authorization and multi-tenancy** generated into the core\n- **Adapters** that keep integrations out of the domain\n- **Testing and AI evaluation** as a delivery gate\n- **Observability, audit and evidence** patterns shared by every application\n- **Controlled regeneration**, so generated code can be refreshed without losing customer logic\n\nThe assistants then do what they are good at, inside those rails. We call it simply: **AI accelerates the implementation. fazeZERO governs the architecture.**\n\n## What this means for a systems integrator\n\nFor an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\n\n- proposals start from an existing foundation and a defined delta\n- less pre-sales engineering on every opportunity\n- the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\n\nWe describe the partner model in [how systems integrators can industrialize AI delivery](\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery).\n\n## A simple test\n\nAsk your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\n\nSee the rails in detail on the [Architecture](\u002Ffactory\u002Farchitecture) page, or [bring us a use case](\u002Fcontact) and we'll show you the delta against the closest foundation.\n","\u003Cp>It is the most common objection we hear from enterprises and systems integrators, and it's a fair one:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>“Our developers already use Cursor, Claude Code and Copilot. Why do we need you?”\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>The honest answer is \u003Cstrong>not\u003C\u002Fstrong> that we have better AI. We use the same class of tools. The difference is what those tools are pointed at.\u003C\u002Fp>\n\u003Ch2>Implementation engines\u003C\u002Fh2>\n\u003Cp>AI coding assistants are extraordinary at implementation. Given a clear intent and a clear structure, they write correct code quickly, refactor fluently and generate tests on request. They make good engineers much faster.\u003C\u002Fp>\n\u003Cp>What they don't provide is the structure itself. A general-purpose assistant has no opinion about your bounded contexts, your API versioning policy, your tenancy model or how your adapters should isolate a core banking system. It will happily produce \u003Cem>an\u003C\u002Fem> answer every time. It will not reliably produce the \u003Cem>same\u003C\u002Fem> answer every time.\u003C\u002Fp>\n\u003Ch2>Where the risk accumulates\u003C\u002Fh2>\n\u003Cp>The risks of architecture-free AI development are predictable:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Inconsistent domain boundaries.\u003C\u002Fstrong> The same business concept lives in three services, modelled three ways.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Weak API design.\u003C\u002Fstrong> Endpoints shaped by screens rather than contracts, and no versioning discipline.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Late identity and authorization.\u003C\u002Fstrong> Role checks scattered through handlers, added after the demo.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Inconsistent multi-tenancy.\u003C\u002Fstrong> Tenant isolation handled by convention, differently in each module.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Thin testing.\u003C\u002Fstrong> Tests written to pass rather than to specify.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Drift.\u003C\u002Fstrong> Regenerating a module quietly changes behaviour elsewhere.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Production rework.\u003C\u002Fstrong> The prototype gets rewritten the moment it meets security review, integration or scale.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of this is the tool's fault. It's what happens when the architecture is left to emerge.\u003C\u002Fp>\n\u003Ch2>An architectural system\u003C\u002Fh2>\n\u003Cp>fazeZERO provides the part the assistants lack: a reusable application architecture refined over roughly two years and exercised across hundreds of application foundations. Concretely:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Domain-Driven Design\u003C\u002Fstrong> with bounded contexts as the unit of structure\u003C\u002Fli>\n\u003Cli>\u003Cstrong>OpenAPI-first contracts\u003C\u002Fstrong> validated before implementation\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Identity, authorization and multi-tenancy\u003C\u002Fstrong> generated into the core\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Adapters\u003C\u002Fstrong> that keep integrations out of the domain\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing and AI evaluation\u003C\u002Fstrong> as a delivery gate\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Observability, audit and evidence\u003C\u002Fstrong> patterns shared by every application\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Controlled regeneration\u003C\u002Fstrong>, so generated code can be refreshed without losing customer logic\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The assistants then do what they are good at, inside those rails. We call it simply: \u003Cstrong>AI accelerates the implementation. fazeZERO governs the architecture.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>What this means for a systems integrator\u003C\u002Fh2>\n\u003Cp>For an SI, the question is not “fazeZERO or our developers.” It's whether every engagement should start with a blank repository and a fresh architecture debate. A reusable application layer means:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>proposals start from an existing foundation and a defined delta\u003C\u002Fli>\n\u003Cli>less pre-sales engineering on every opportunity\u003C\u002Fli>\n\u003Cli>the SI's developers use their AI tools on customer-specific work, not on reinventing the plumbing\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>We describe the partner model in \u003Ca href=\"\u002Fblog\u002Fhow-systems-integrators-industrialize-ai-delivery\">how systems integrators can industrialize AI delivery\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>A simple test\u003C\u002Fh2>\n\u003Cp>Ask your team to build the same small application twice, a week apart, with the same assistant and the same requirements. Then compare the two architectures. If they differ in ways that would matter in production, you have found the gap an architectural system fills.\u003C\u002Fp>\n\u003Cp>See the rails in detail on the \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa> page, or \u003Ca href=\"\u002Fcontact\">bring us a use case\u003C\u002Fa> and we'll show you the delta against the closest foundation.\u003C\u002Fp>\n","Cursor, Claude Code and Copilot are implementation engines, not architectures","Our developers already have AI coding tools, so why use fazeZERO? The answer is not better AI. It is the architectural system the AI works inside.",[14,15,16,33],"2026-06-23T00:00:00.000Z",6,2,{"id":51,"slug":52,"body":53,"html":54,"title":55,"description":56,"category":11,"tags":57,"author":17,"date":59,"year":19,"month":48,"quarter":49,"status":22,"featured":60,"series":37,"seriesOrder":49},"2026\u002F06\u002Ffactory-and-architecture\u002Fai-accelerates-architecture-governs","ai-accelerates-architecture-governs","\nEvery enterprise now has access to AI that writes code. The interesting question is no longer *whether* AI writes the application. It is **what the AI is allowed to write into**.\n\nOur answer is a fixed, proven architecture. AI accelerates the implementation inside it. It does not get to reinvent the structure for each customer.\n\n## The problem with improvised architecture\n\nGive a capable coding assistant a requirements document and a blank repository and you will get a working prototype quickly. You will also get an architecture that *emerged*: shaped by the order in which prompts arrived, the examples the model happened to favour, and whatever the developer accepted at 11pm.\n\nRun that process ten times for ten applications and you get ten architectures:\n\n- domain boundaries drawn differently every time\n- APIs designed after the screens, not before them\n- identity and authorization added once someone asks about security\n- multi-tenancy handled three different ways\n- tests written after the fact, if at all\n- code that drifts every time it is regenerated\n\nNone of this shows in the demo. All of it shows in production, as rework.\n\n## What we do instead\n\nOur pipeline runs in a fixed order:\n\n1. **Requirements**: the business problem, users, workflows and user stories.\n2. **Domain model**: bounded contexts and the vocabulary of the business.\n3. **Governed architecture**: the same layering, service boundaries and adapters every time.\n4. **API contracts**: OpenAPI definitions for every boundary, before implementation.\n5. **Generated core**: services, adapters, identity, authorization and tenancy from the factory.\n6. **Customer-specific logic and AI**: the part that is genuinely unique to this customer.\n7. **Testing and controls**: automated tests, AI evaluations, audit and evidence.\n8. **Web application and deployment**: a working UI and a baseline for the customer's cloud.\n\nAI is involved at almost every step. It drafts user stories, proposes domain models, writes implementation and generates tests. But it works *inside* rails that were set before it arrived.\n\n## Why this is faster, not slower\n\nIt sounds like governance should slow things down. In practice, it does the opposite. It removes the decisions that don't need to be made again.\n\nWhen the architecture is fixed, a new application doesn't debate how to structure identity, how to version APIs, where business rules live or how to test adapters. Those answers already exist, and they have been exercised across a large inventory of applications in very different domains. The engineering effort goes where it should: into the customer's workflow, data and integrations.\n\nThis is also why we can start customer work from an **existing application foundation** rather than a blank repository. Hundreds of foundations share one architectural grammar, so the closest one is usually a meaningful head start.\n\n## What changes and what doesn't\n\nBetween customers, **these change**: domain vocabulary, workflows, integrations, data, AI capabilities, cloud and policies.\n\n**These don't**: bounded contexts as the unit of design, contract-first APIs, identity and tenancy in the core, tests as a gate, observability, and controlled regeneration.\n\nCustomer-specific functionality changes. The architectural discipline does not.\n\n## Where this leaves AI coding tools\n\nWe use them, and so should your developers. They are excellent implementation engines. The mistake is treating them as an *architecture*. We have written more about that in [coding assistants are not an architecture](\u002Fblog\u002Fcoding-assistants-are-not-an-architecture).\n\n## Where to go next\n\n- How the pipeline works end to end: [the Application Factory](\u002Ffactory)\n- The patterns every application starts with: [Architecture](\u002Ffactory\u002Farchitecture)\n- Your own use case mapped onto it: [Solution Definition Sprint](\u002Fservices\u002Fsolution-definition-sprint)\n","\u003Cp>Every enterprise now has access to AI that writes code. The interesting question is no longer \u003Cem>whether\u003C\u002Fem> AI writes the application. It is \u003Cstrong>what the AI is allowed to write into\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp>Our answer is a fixed, proven architecture. AI accelerates the implementation inside it. It does not get to reinvent the structure for each customer.\u003C\u002Fp>\n\u003Ch2>The problem with improvised architecture\u003C\u002Fh2>\n\u003Cp>Give a capable coding assistant a requirements document and a blank repository and you will get a working prototype quickly. You will also get an architecture that \u003Cem>emerged\u003C\u002Fem>: shaped by the order in which prompts arrived, the examples the model happened to favour, and whatever the developer accepted at 11pm.\u003C\u002Fp>\n\u003Cp>Run that process ten times for ten applications and you get ten architectures:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>domain boundaries drawn differently every time\u003C\u002Fli>\n\u003Cli>APIs designed after the screens, not before them\u003C\u002Fli>\n\u003Cli>identity and authorization added once someone asks about security\u003C\u002Fli>\n\u003Cli>multi-tenancy handled three different ways\u003C\u002Fli>\n\u003Cli>tests written after the fact, if at all\u003C\u002Fli>\n\u003Cli>code that drifts every time it is regenerated\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of this shows in the demo. All of it shows in production, as rework.\u003C\u002Fp>\n\u003Ch2>What we do instead\u003C\u002Fh2>\n\u003Cp>Our pipeline runs in a fixed order:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Requirements\u003C\u002Fstrong>: the business problem, users, workflows and user stories.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Domain model\u003C\u002Fstrong>: bounded contexts and the vocabulary of the business.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Governed architecture\u003C\u002Fstrong>: the same layering, service boundaries and adapters every time.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>API contracts\u003C\u002Fstrong>: OpenAPI definitions for every boundary, before implementation.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Generated core\u003C\u002Fstrong>: services, adapters, identity, authorization and tenancy from the factory.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Customer-specific logic and AI\u003C\u002Fstrong>: the part that is genuinely unique to this customer.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testing and controls\u003C\u002Fstrong>: automated tests, AI evaluations, audit and evidence.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Web application and deployment\u003C\u002Fstrong>: a working UI and a baseline for the customer's cloud.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>AI is involved at almost every step. It drafts user stories, proposes domain models, writes implementation and generates tests. But it works \u003Cem>inside\u003C\u002Fem> rails that were set before it arrived.\u003C\u002Fp>\n\u003Ch2>Why this is faster, not slower\u003C\u002Fh2>\n\u003Cp>It sounds like governance should slow things down. In practice, it does the opposite. It removes the decisions that don't need to be made again.\u003C\u002Fp>\n\u003Cp>When the architecture is fixed, a new application doesn't debate how to structure identity, how to version APIs, where business rules live or how to test adapters. Those answers already exist, and they have been exercised across a large inventory of applications in very different domains. The engineering effort goes where it should: into the customer's workflow, data and integrations.\u003C\u002Fp>\n\u003Cp>This is also why we can start customer work from an \u003Cstrong>existing application foundation\u003C\u002Fstrong> rather than a blank repository. Hundreds of foundations share one architectural grammar, so the closest one is usually a meaningful head start.\u003C\u002Fp>\n\u003Ch2>What changes and what doesn't\u003C\u002Fh2>\n\u003Cp>Between customers, \u003Cstrong>these change\u003C\u002Fstrong>: domain vocabulary, workflows, integrations, data, AI capabilities, cloud and policies.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>These don't\u003C\u002Fstrong>: bounded contexts as the unit of design, contract-first APIs, identity and tenancy in the core, tests as a gate, observability, and controlled regeneration.\u003C\u002Fp>\n\u003Cp>Customer-specific functionality changes. The architectural discipline does not.\u003C\u002Fp>\n\u003Ch2>Where this leaves AI coding tools\u003C\u002Fh2>\n\u003Cp>We use them, and so should your developers. They are excellent implementation engines. The mistake is treating them as an \u003Cem>architecture\u003C\u002Fem>. We have written more about that in \u003Ca href=\"\u002Fblog\u002Fcoding-assistants-are-not-an-architecture\">coding assistants are not an architecture\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Where to go next\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>How the pipeline works end to end: \u003Ca href=\"\u002Ffactory\">the Application Factory\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>The patterns every application starts with: \u003Ca href=\"\u002Ffactory\u002Farchitecture\">Architecture\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>Your own use case mapped onto it: \u003Ca href=\"\u002Fservices\u002Fsolution-definition-sprint\">Solution Definition Sprint\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n","AI accelerates the implementation. Architecture governs it.","Why fazeZERO uses AI inside a proven production architecture instead of letting it improvise a new architecture for every enterprise application.",[15,14,33,58],"enterprise","2026-06-18T00:00:00.000Z",true,{"id":62,"slug":63,"body":64,"html":65,"title":66,"description":67,"category":68,"tags":69,"author":17,"date":71,"year":19,"month":48,"quarter":49,"status":22,"featured":23,"series":37,"seriesOrder":72},"2026\u002F06\u002Fpartners-and-channel\u002Fhow-systems-integrators-industrialize-ai-delivery","how-systems-integrators-industrialize-ai-delivery","\nSystems integrators are being asked the same question by every client: *how do we get our AI use cases into production?* Most SIs have strong customer access, cloud and data practices, and growing AI teams. What few have is an **industrialized application layer**: a repeatable way to turn a use case into a governed application without starting from a blank repository each time.\n\nThat is the gap a joint AI application factory fills.\n\n## The operating thesis\n\n> **The SI discovers, sells, integrates and operates. fazeZERO productizes and builds.**\n\nThe split follows what each side does best.\n\n**The systems integrator owns:**\n\n- the customer relationship and business context\n- enterprise discovery\n- cloud, infrastructure and data\n- enterprise integrations and cybersecurity\n- managed services, change and operations\n\n**fazeZERO owns:**\n\n- product definition, architecture and domain modeling\n- the application factory and code generation\n- application-level AI\n- testing and reusable engineering\n- application-specific architecture\n\nNobody competes for the same work, and the customer gets both an application and someone to run it.\n\n## Why it raises conversion\n\nThe hardest moment in an AI opportunity is the gap between an enthusiastic workshop and a funded project. The customer asks what exactly they would get, how long it would take and how risky it is. Without a reusable application layer, answering means weeks of unpaid pre-sales engineering.\n\nWith one, the answer starts from an existing application foundation and a defined delta:\n\n1. **Opportunity qualification.** Account context, application matching and discovery questions. Included.\n2. **Joint discovery workshop.** Use-case selection and an architecture hypothesis, within an agreed pre-sales allowance.\n3. **AI Opportunity Brief.** A joint deliverable, so the SI leaves the room with something concrete to sell.\n4. **Solution Definition Sprint.** Formal requirements, domain model, integrations and scope. Billable.\n\nThe rule we follow: **we don't charge partners to bring us into the room. We charge once the conversation turns into solution engineering.**\n\n## Rules that protect the account\n\nPartnerships fail on ambiguity, so the rules of engagement are explicit:\n\n- **The originator keeps the relationship.** On partner-originated accounts, the partner is normally the commercial prime.\n- **Registration and protection.** Opportunities are registered (account, use case, sponsor, owner, stage) and protected while active.\n- **No circumvention.** Neither party pursues a registered opportunity around the other.\n- **No blanket exclusivity.** Preferred status is earned through bookings, delivery and commitment.\n- **Clear IP.** The factory, generator and reusable assets stay with fazeZERO. Customer-specific IP follows the customer contract.\n- **Co-branding over white label.** “Your AI Application Factory, powered by fazeZERO” builds credibility for both sides.\n\n## The tools\n\nPartners work in a private workbench on top of the [Application Atlas](\u002Fatlas): account mapping, problem-to-application matching, discovery questions, opportunity briefs and opportunity registration. The workbench is one configurable codebase with partner branding. We don't build a separate fork for each partner.\n\n## How to start\n\nStart small and measurable: ten named accounts, a handful of repeatable AI opportunities, three to five joint discovery sessions and one paid sprint. The goal of the first quarter isn't only revenue. It's learning whether the partner can generate qualified opportunities without us originating every one.\n\nRead more on [systems integrator partnerships](\u002Fpartners\u002Fsystems-integrators), or [start the conversation](\u002Fcontact).\n","\u003Cp>Systems integrators are being asked the same question by every client: \u003Cem>how do we get our AI use cases into production?\u003C\u002Fem> Most SIs have strong customer access, cloud and data practices, and growing AI teams. What few have is an \u003Cstrong>industrialized application layer\u003C\u002Fstrong>: a repeatable way to turn a use case into a governed application without starting from a blank repository each time.\u003C\u002Fp>\n\u003Cp>That is the gap a joint AI application factory fills.\u003C\u002Fp>\n\u003Ch2>The operating thesis\u003C\u002Fh2>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>The SI discovers, sells, integrates and operates. fazeZERO productizes and builds.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>The split follows what each side does best.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>The systems integrator owns:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>the customer relationship and business context\u003C\u002Fli>\n\u003Cli>enterprise discovery\u003C\u002Fli>\n\u003Cli>cloud, infrastructure and data\u003C\u002Fli>\n\u003Cli>enterprise integrations and cybersecurity\u003C\u002Fli>\n\u003Cli>managed services, change and operations\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>fazeZERO owns:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>product definition, architecture and domain modeling\u003C\u002Fli>\n\u003Cli>the application factory and code generation\u003C\u002Fli>\n\u003Cli>application-level AI\u003C\u002Fli>\n\u003Cli>testing and reusable engineering\u003C\u002Fli>\n\u003Cli>application-specific architecture\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Nobody competes for the same work, and the customer gets both an application and someone to run it.\u003C\u002Fp>\n\u003Ch2>Why it raises conversion\u003C\u002Fh2>\n\u003Cp>The hardest moment in an AI opportunity is the gap between an enthusiastic workshop and a funded project. The customer asks what exactly they would get, how long it would take and how risky it is. Without a reusable application layer, answering means weeks of unpaid pre-sales engineering.\u003C\u002Fp>\n\u003Cp>With one, the answer starts from an existing application foundation and a defined delta:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Opportunity qualification.\u003C\u002Fstrong> Account context, application matching and discovery questions. Included.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Joint discovery workshop.\u003C\u002Fstrong> Use-case selection and an architecture hypothesis, within an agreed pre-sales allowance.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>AI Opportunity Brief.\u003C\u002Fstrong> A joint deliverable, so the SI leaves the room with something concrete to sell.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Solution Definition Sprint.\u003C\u002Fstrong> Formal requirements, domain model, integrations and scope. Billable.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>The rule we follow: \u003Cstrong>we don't charge partners to bring us into the room. We charge once the conversation turns into solution engineering.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch2>Rules that protect the account\u003C\u002Fh2>\n\u003Cp>Partnerships fail on ambiguity, so the rules of engagement are explicit:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>The originator keeps the relationship.\u003C\u002Fstrong> On partner-originated accounts, the partner is normally the commercial prime.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Registration and protection.\u003C\u002Fstrong> Opportunities are registered (account, use case, sponsor, owner, stage) and protected while active.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>No circumvention.\u003C\u002Fstrong> Neither party pursues a registered opportunity around the other.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>No blanket exclusivity.\u003C\u002Fstrong> Preferred status is earned through bookings, delivery and commitment.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Clear IP.\u003C\u002Fstrong> The factory, generator and reusable assets stay with fazeZERO. Customer-specific IP follows the customer contract.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Co-branding over white label.\u003C\u002Fstrong> “Your AI Application Factory, powered by fazeZERO” builds credibility for both sides.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>The tools\u003C\u002Fh2>\n\u003Cp>Partners work in a private workbench on top of the \u003Ca href=\"\u002Fatlas\">Application Atlas\u003C\u002Fa>: account mapping, problem-to-application matching, discovery questions, opportunity briefs and opportunity registration. The workbench is one configurable codebase with partner branding. We don't build a separate fork for each partner.\u003C\u002Fp>\n\u003Ch2>How to start\u003C\u002Fh2>\n\u003Cp>Start small and measurable: ten named accounts, a handful of repeatable AI opportunities, three to five joint discovery sessions and one paid sprint. The goal of the first quarter isn't only revenue. It's learning whether the partner can generate qualified opportunities without us originating every one.\u003C\u002Fp>\n\u003Cp>Read more on \u003Ca href=\"\u002Fpartners\u002Fsystems-integrators\">systems integrator partnerships\u003C\u002Fa>, or \u003Ca href=\"\u002Fcontact\">start the conversation\u003C\u002Fa>.\u003C\u002Fp>\n","How systems integrators can industrialize AI delivery","A joint AI application factory: the SI owns the customer, integration and operations while fazeZERO productizes and builds the application layer.","partners-and-channel",[70,15,34,58],"partners","2026-06-16T00:00:00.000Z",1,1790080513426]