The words we use, defined

Delivery infrastructure installed on a client codebase so that people who are not Frontend engineers can get production Frontend changes merged. Concretely: guards that run on every pull request, specifications a coding agent can execute, design-system enforcement, an AI context layer committed to the repository, and agent tooling. It is operated by our forward deployed engineers through phased stages (install, operate, teach, hand over) and then owned by the client team. It is infrastructure with a defined outcome, not staff augmentation and not a strategy engagement.

Not to be confused with. The published definitions of "software factory" and "AI software factory" disagree with each other. Some describe a work queue of agents with a human approving at the merge point, some describe an operating model where agents write and ship while humans keep the specifications, and some describe artifact signing and build provenance. Ours is narrower than all three and differs in what it industrializes: the merge-time guard set and the context an agent reads before it writes, inside an existing codebase, on an existing pipeline. We do not sell an agent fleet, an architecture migration or a platform you log into.

An automated check that decides whether a change may merge, running before a human is asked to look at it and failing with a specific, actionable reason addressed to the author. The decisive properties are the position (before review, not after) and the verdict (blocking, not advisory). A check that reports a finding and lets the merge proceed is instrumentation. A check that holds the change is a gate.

Not to be confused with. Guardrail, policy and scan. The useful separation is four levels: a policy is the stated intent, a scan is the measurement, a gate is the pipeline checkpoint that passes or fails, and a guardrail is the enforced boundary that may contain several gates. Most vendor writing uses all four words for all four things, and "agentic guardrails" usually means something else again: runtime controls inside an agent execution loop, which is a different layer from a merge gate and does not substitute for one.

The full collection of merge gates installed on a codebase, treated as one artifact with one owner rather than as a pile of individual CI jobs. The named guards are design-system conformance, tests and test quality, performance, accessibility, security, and the contract and localization checks a given codebase needs. The set is the deliverable of a factory install, and it is the thing that remains after handover.

The merge-time check on the declarations that carry a page’s value in search and in answer engines: the route itself, the internal links pointing at it, one canonical per route, the robots directive, the sitemap entry, the title and the description. It works from an inventory built at build time and diffed against the base branch, so a renamed or deleted public route fails without a redirect and an internal link that resolves to nothing fails outright. It rides inside the performance budget guard, because that is the guard already driving a page audit in the pipeline.

Not to be confused with. A technical SEO audit, which is a report produced after a drop, on URLs somebody chose to crawl, read by a person who cannot block a merge. This runs on the diff that would cause the drop. It is also not the rendering question (whether your content is in the HTML at all) and not the agent-readiness question (whether an agent can operate the page), which are both about what a product publishes outward. And it asserts declarations rather than positions: a green guard says the inputs are intact, never that a page deserves to rank.

A senior engineer who works inside a client organization rather than beside it: same repository, same sprint, same standup, same definition of done. The model comes out of enterprise deployment work and became the default way serious AI capability is installed, because the hard part is the last mile into a real codebase rather than the model. At Enpitech it is a delivery model rather than a service: every embedded engineer arrives carrying the factory and installs it while shipping production features.

The written standards a coding agent reads before it writes: conventions, module boundaries, commands, the component and token registry, domain language. The factory treats it as code with an assertion behind it. Everything derivable is generated from the repository, everything else is written so a machine can check it, and a job in the same CI run that holds the guards fails the build when the file names a script, a path or a convention the repository no longer has.

Not to be confused with. Documentation. A stale README is skimmed by a human with doubts. A stale context file is obeyed, silently, and nothing errors, because from the agent side nothing failed.

A context file generated by a tool’s own init command, never reviewed, and treated from then on as the configuration. It is the most common failure mode found in audits of real AGENTS.md and CLAUDE.md files, and it travels with three siblings: lint leakage (restating rules a linter already enforces), skill leakage (keeping a rarely used procedure in the file that loads every session), and conflicting instructions (two directives that contradict, so the agent picks one differently each time).

The stage at which the client team owns the guard set, the context layer and the workflows outright, with a named internal owner, and the engagement either ends or continues as an operation retainer by choice rather than by dependency. Ownership is the deliverable: nothing we install may require us to keep running it. Stated as a design constraint, not as a promise about switching costs.

The merge-time check that an experiment can produce a number worth acting on. It asserts the things only the repository knows: that the assignment comes from a key that cannot change inside a session, that the exposure event is awaited before any navigation the same change introduces, that the resolution reason travels beside the variant so a provider falling back to its default reads as an outage rather than a result, and that the experiment carries an expiry. The failure it exists for is not a broken page, it is a correct-looking chart behind a wrong decision.

Not to be confused with. An experimentation platform and a feature-flag service, which are the two tools a team already pays for and neither of which can do this. Both of them see only what your client actually sent, so a lost exposure, a re-bucketed visitor or a defaulted evaluation arrives at them already indistinguishable from a real result. The platform tells you the split looks wrong after the test has run; the guard is what stops the cause from merging.

The checks that run when content is published rather than when code is merged, and the rule that decides which fields are allowed on that path at all. The boundary is drawn by what a field can break, not by who edits it: content that can only be wrong (body text in a slot with asserted bounds, an image with a required alt) belongs to editors, while declarations that can break something no reviewer will see (anything that becomes markup, a URL, a cache key, a title or a canonical, a new locale or a new field type) stay in the repository behind the merge gate. What it exists for is that a publish has no merge, so every guard a delivery pipeline runs is structurally blind to it.

Not to be confused with. A CMS approval workflow, which is the thing most teams already have and which answers a different question. An approval records that a human looked at the copy; it cannot assert that the markup was sanitized, that the slot still fits the string, that the slug change shipped with its redirect, or that the invalidation reached every instance. The other confusion is with a merge gate, which is not lenient here so much as absent: it never sees the publish path.

The merge-time checks that an age check actually works on the devices you claimed it works on, and fails safe when it cannot. It asserts the things only the repository knows: that both presentation paths exist rather than only the one the authoring machine can run, that the capability check is guarded so it cannot throw on the very engines it exists to detect, that the request sits inside a real user gesture rather than an effect or a retry loop, that trust-list validation fails closed when the list is unreachable, that no demo endpoint is reachable from a production build, and that an alternative route exists for the people who cannot use the main one. The failure it exists for is not an ugly page, it is a compliance flow that works on the team’s own phones and silently does not work, or quietly overcharges the user, everywhere else.

Not to be confused with. A vendor age-verification widget, which is what most teams buy and which cannot do this. The widget implements the protocol; it does not know which of your routes gate content, whether your frame is sandboxed so the call is rejected outright, whether your analytics stack is attaching a stable identifier to the one flow that must not carry one, or what your application does when the trust list times out. The other confusion is with a browser-support target, which is the general policy about which engines you promise to run on. This is the narrower question of what a mandatory flow costs the user when the engine in front of it lacks the API.

The merge-time checks that your application actually behaves the way your privacy notice says it behaves when a browser sends an opt-out preference signal. It asserts the things only the repository knows: that the header is compared against its one permitted value rather than tested for existence, so a value meaning "not opted out" is not read as an opt-out, that the signal is part of the cache key for every route whose response changes with it, that the case where an intermediary inserts the header is exercised and not only the case a browser produces, that the document-scoped property is read once per document rather than polled, that the disclosure renders in both states, that the published support file parses and matches what the code does, and that the signal is never attached to an outbound measurement payload. The failure it exists for is not a visible bug. It is an application that handles the signal correctly on the engineer’s machine, serves a cached page that ignores it to everybody else, and reports nothing, on a path whose traffic is about to arrive on a date that is already public.

Not to be confused with. A consent management platform, which is what most teams buy and which cannot do this. The platform reads the signal and sets its own state; it does not know which of your routes vary their response on it, whether your edge put that variance in the cache key, whether your single-page application is re-reading a property the specification froze at navigation, or whether your own measurement is quietly recording who sent the signal. The other confusion is with a consent banner, which is an interface for collecting a choice. This is the narrower question of what your application does with a choice the person already made somewhere else, before your page ran.

The merge-time checks that the paths your certificates are renewed through still work, on every hostname your Frontend owns rather than only on the one in the address bar. It asserts the things only the repository knows: that the challenge directories return the challenge value and not an application shell, because a catch-all route answers them with a 2xx and the wrong body rather than with the 404 anyone would notice, that any redirect on those paths is a protocol-layer 301, 302, 307 or 308 and not a meta refresh or a client-side navigation, that the paths answer the same way from more than one network location rather than only from the machine running the check, that the CAA record and the signing state of each zone are committed and reviewed like the rest of your declarations, and that the remaining validity of every certificate in the inventory is a number your alerting reads. The failure it exists for is not a visible bug. It is a renewal that stops happening on the day somebody tidies up a redirect rule, and a hostname that becomes unreachable a hundred days later with no degraded mode to fall back to.

Not to be confused with. A certificate lifecycle management product, which is what most orgs buy and which is not what this is. That product obtains and installs certificates; it does not know that your framework now answers the validation URL with an HTML document, that your canonical-host redirect is implemented in JavaScript, that one of your zones has a broken signing chain, or that the subdomain about to expire is reached by a Strict-Transport-Security policy with includeSubDomains, which converts a warning a person could click through into a connection the browser refuses. The other confusion is with certificate pinning, which is a different decision about trusting a specific key, wearing the same word as the version pinning in your lockfile.

The merge-time checks that you know which capabilities your product depends on are being taken away by the people who implement them, and that you will find out before your users do. It exists because the usual instruments cannot see this class of dependency at all. A dependency audit reads manifests, and the thing being removed is not in a manifest: it can be an instruction inside a document you serve, a default in an engine, a header somebody else sends you, or a transform that has been free for so long that nobody who relies on it is still at the company. So the gate asserts what a code search cannot: an inventory of what your origin actually serves rather than what your repository contains, built by walking reachable surfaces; a label on each entry saying whether it is read by your own team or by somebody who pays you, because that label and not the technology decides whether a removal is an inconvenience or an incident; the declarations that trigger the capability reviewed as a diff like any other declaration; the surfaces a customer opens moved to a processor you control; a deliberate, written decision to do nothing about the ones that do not matter; and the implementer’s own warning channel collected, so the next removal arrives as a failing check rather than as a support ticket. The failure it exists for is not a visible bug and not a test going red. It is a document that rendered correctly for years rendering as raw markup on a date somebody else chose, announced in a console nobody was watching.

Not to be confused with. The browser-support target, which is the opposite question and is often conflated with this one. That target is which engines you commit to serving, agreed once and enforced at merge, and it deals with capabilities that are arriving: the question is whether enough of your users have one yet. This deals with capabilities that are leaving, which every engine already has, and the readiness datasets actively mislead here, because a feature implemented everywhere and scheduled for removal computes the same not-ready value as a feature nobody has shipped. A rule that reads that value as a reason to wait gets this case exactly backwards. The second confusion is with a deprecated package in your lockfile, which you upgrade on your own schedule and which fails loudly in a build you own. Nothing here is on your schedule, and nothing here fails in your build.

The share of opened pull requests that merge within a fixed window, measured on the far side of review and split by whether an agent authored the change. It is the honest throughput number in an agent-assisted pipeline, because it is taken on the artifact that actually ships and it falls when the pipeline is failing.

Not to be confused with. Suggestion acceptance rate, the share of a tool’s inline completions a developer tabs into a file. The two names are nearly identical and the numbers measure opposite things: the first is taken after review on shipped work, the second before review on keystrokes, and the second climbs when nothing has improved. Do not let a vendor dashboard hand you the second one and call it the first.

The complement of merge acceptance: the share of authored changes that were generated, looked at, argued about and thrown away. Reading the gap as scrap rather than as slowness is the point, because the cost is paid twice, once in tokens and once in reviewer attention, and it ships nothing. The published benchmarks show the ceiling moving a long way with the model held constant, which is what makes it a property of the system around the agent rather than of the agent.

The share of defects stopped by a gate before a human was asked, reported per guard. It is the number that says whether the guard set is doing the work, and it is always read beside review rejection rate on agent output, because a catch rate that rises while rejection also rises means the guards are catching more and the pipeline is still producing more to catch.

The share of agent output that reaches a human already proven rather than merely finished. It is the number that decides whether running more agents in parallel does anything, because the ceiling on parallel agents is not how much code can be produced, it is how much of it a person is willing to put their name on. It is a property of the codebase rather than of the engineers: a repository with an enforced design system, trustworthy tests and typed boundaries is far more delegable than one whose rules live in three people’s heads. There is no published figure for it and we do not invent one; the audit measures yours before anything is installed.

The distance between the share of work developers do with AI assistance and the much smaller share of tasks they say they can fully delegate. The published measurement names verification as the bottleneck that produces the gap. Buying more agent seats moves the first number and does nothing to the second, which is the whole argument for spending on guards instead.

The share of deliberately introduced faults in changed code that the test suite notices. A mutation tool alters the code in small ways and reruns the tests; a fault the suite catches is killed, one it misses survived. It answers the question a gate exists to ask, whether anything would fail if this line were wrong, and it is the measurement the factory gates on for changed files once people outside the Frontend team are merging.

Not to be confused with. Code coverage, which answers a different question: while the suite ran, did this line execute. Nothing in a coverage report inspects what a test checks, so a test that renders a component, asserts it did not throw and snapshots the output is indistinguishable from one that asserts behaviour. That distinction is why a coverage number in the eighties stops being a gate when agents write the tests too.

A deliberately introduced fault that the tests executed and did not notice: something ran the changed code, the behaviour was altered, and the suite stayed green. It is distinct from no coverage, where nothing ran the code at all, and the interchange format the mutation tools write keeps the two as separate fields on every mutant. Survived is the state a coverage report is structurally unable to report, and it is the state that matters once agents write the tests.

The mutation score below which the build fails, as distinct from the score below which it only warns. It is worth naming because the default in the common tooling never fails a build at all, so a team can run mutation testing for months, watch the number and have no gate. A threshold that only reports is instrumentation.

The team that owns a surface, decided at merge time and written in the repository, rather than inferred afterwards from who merged the change. It is the answer to the accountability question the factory provokes, and the reason it is written down is that "whoever merged it" quietly stops the factory working within a quarter.

A contributor responsible for a small share of a component’s commits, below a low threshold. The industrial research on code ownership found the count of minor contributors correlating with pre-release failures more strongly than size, churn or complexity, and found that a typical low-ownership change is not a tourist: about half the time that same person is a major contributor to a component this one depends on. That is the backend engineer in your Frontend, exactly, and it is going to happen. It is why the factory routes quality-control effort by ownership distribution instead of trying to prevent the crossing.

Anyone merging production Frontend changes who is not on the Frontend team: backend engineers, product managers, designers, marketing, sales, customer success. The factory’s outcome is stated in terms of this group, and the measurement that goes with it is merged volume from outside the Frontend team, taken as a baseline in the audit before anything is installed.

What a non-Frontend contributor is actually missing, which is not syntax. It is knowing which component already exists, which token, the loading, empty, error and offline states, keyboard and screen-reader behaviour, and what a change costs in bundle size. A senior Frontend engineer carries it in their head, which is exactly why it cannot scale past that person and has to become a gate instead.

Not to be confused with. Ability to write React. "Backend engineers cannot write React" is both wrong and insulting to the buyer. They can generate it. What they cannot do is clear the tacit layer, and the fix is to make it machine-checkable rather than to lower it.

Making it possible for people outside the Frontend team to ship production Frontend, by installing the guards and the context first and onboarding the roles second. The sequence is the whole method and we refuse the other order: open the roles before the guards run and the result is review load, drift and a rollback, which is the failure the guard set exists to prevent.

A split that lets one part of a Frontend be released without releasing the others, usually proposed as independently deployable micro-frontends composed at runtime. It is almost always asked for to get a property it does not provide: that a change from one team cannot break another team’s surface. That is a merge-time property a pipeline can enforce. A deployment boundary moves the integration out of CI, where a guard can hold a change, into the browser of whoever loads the page next, where no guard runs.

Not to be confused with. A guard. They are opposites in the thing that matters here: a guard holds a change before it reaches anyone, a deployment boundary removes the moment at which it could have been held.

Assembling a page in the browser from parts built separately, negotiating shared dependencies at load time in a shared scope rather than resolving them at build time. The defaults are the part worth reading before approving the proposal, because the common failure is not a build error: several pipelines go green and the composition fails on a user’s first paint.

The setting that asks for exactly one copy of a shared library on the page. It matters because of what it does not do. It is off by default, so two copies of a library is the documented normal case; turned on with inconsistent versions it does not fail either, it loads the higher version and warns the party with the lower one. Related settings decide the same question differently: a declared version range on one side wins over a singleton request on the other, and the negotiation key is the property name unless told otherwise, so a mismatch between two sides is not an error, it is each side bundling its own copy.

A move between two parts of a site that unloads the current page’s resources and loads the new ones, rather than transitioning within a loaded application. It is the documented cost of the seam between independently built zones, which is why the honest version of a Frontend split puts the seam where a full page load is already acceptable and keeps pages frequently visited together on the same side of it.

A separately built and deployed application served under its own path prefix on one domain, with its own asset prefix. It is the narrow shape where splitting a Frontend is honest: a genuinely separate product with its own cadence, its own team and often its own framework, where almost nobody crosses between the two inside a session. Its cost is the hard navigation at the seam, taken deliberately.

Where source code is kept, as distinct from where it is deployed. It is a separate decision from a deployment boundary and it has become a live question again for a different reason: a coding agent sees one repository at a time, so a change spanning two of them is a change the agent cannot reason about. The answer is about what an agent and a guard can see together, and it is never a migration undertaken for its own sake.

A product an AI agent can actually use on a user’s behalf, not merely one an agent can read. The readable half is rendering and structure: a clean accessibility tree, server-rendered content, stable layout, machine-readable declarations. The usable half is whether an agent can complete a task, which means declared capabilities, authorization that assumes the caller is your signed-in user, confirmation surfaces for anything irreversible, and instrumentation per tool. We build for both audiences without degrading either.

Not to be confused with. An agent readiness score. The published specifications and scanners in this space openly note that no shared definition of agent-ready exists, and the scores measure declarations. A product can declare everything correctly and still lose every task an agent attempts, which is the worst available position.

A public number a third party computes about your domain from what it can see without asking: robots and sitemap files, Markdown content negotiation, content signals, server cards, an API catalogue, agent identity and commerce declarations. Treat it as hygiene and a floor. Pass it quickly, hold it true with a CI check rather than with somebody’s memory because these files rot the moment nobody owns them, then spend the real budget on the half it cannot see, which is whether an agent can finish anything in your product.

One typed implementation of what your product can do, called by both your own interface and any agent-facing tool. The tool an agent calls runs the same function your button calls, so validation, permissions, telemetry and audit are inherited rather than written a second time, and the difference between the human path and the agent path becomes transport rather than behaviour. Then it is asserted: a contract test runs the same case through both callers and fails when they disagree.

Not to be confused with. A second implementation. An in-product assistant built beside the interface instead of through it gets its own queries, its own permission checks and its own idea of what a cancelled order is, and the two drift from the day they ship. That is the usual reason an assistant and the product give different answers.

An action your own page registers for an agent to call, rather than leaving the agent to infer it by scraping the DOM or a screenshot. Two properties hold whatever you expose: a tool call executes in the browser, so an agent-submitted request is exactly as untrusted as a human-submitted one and a schema is not a security boundary, which means validation and authorization happen again on the server; and anything irreversible needs a human confirmation that renders the real parameters. Build it as a thin adapter over the capability layer, never as the implementation, so a renamed API costs you the adapter and not the work.

Not to be confused with. A platform-supplied tool pack. Tools your commerce platform or CDN exposes on your behalf know your catalog and your cart. They do not know your entitlement rules, promotion logic, consent state or trial gating, because they were written against a platform rather than your business, and they are the same tools every competitor on that platform exposes.

Your product exposed inside an AI assistant as a callable server plus the interactive views the assistant renders, so a user can do real work with you without leaving the conversation. It is a distribution surface rather than a feature: the build question is which flows to open, and the discovery question (how anyone finds it inside an assistant) is a separate one with its own answer.

Interface assembled at runtime in response to a model’s output, from your own typed, streamable, accessible components rather than from markup a model wrote. The components are a fixed, reviewed vocabulary; what varies is which ones appear and with what data. That constraint is the reason the result stays on-system, accessible and safe to render.

The interface decisions that determine whether anyone trusts an agent inside your product: streaming visibility of what it is doing, intervention at the step level, approval in front of irreversible actions, honest uncertainty signals, and provenance marking which sources were untrusted. The durable failure to design against is a spinner over an autonomous process, where the user cannot see progress, cannot stop it halfway and cannot tell a confident wrong answer from a right one, so they go back to the manual flow. It is a rendering problem, which is what makes it Frontend work.

Being found and cited when the thing asking is a model rather than a person. In practice it is one job with two halves: making the content legible and quotable to a retriever (structure, direct answers, machine-readable entities, recency a page can prove), and making the product legible to an agent that arrives afterwards. We treat it as a Frontend build with measurement attached rather than as a content tactic.

Not to be confused with. Each other, and that is not your fault. No authoritative definition of either acronym exists, the expansions in circulation disagree, and vendors use them interchangeably and as distinct disciplines in the same paragraph. Our practical split: AEO is being cited in an answer, GEO is the generative surface that answer appears on, and the work overlaps almost entirely.

A Markdown file at a site root that states, in plain prose a model can read in one pass, what the organization is and what its key pages hold. The audits that check it check the format rather than its presence, so a file that exists and lists bare URLs instead of Markdown links fails. Like every other declarative file in this category it rots silently once nobody owns it, which is why it belongs behind a CI check.