Avcel combines a self-hosted, Kubernetes-based development environment with an AI development harness, deployed together inside your perimeter as one governed system.
Generic AI tools reverse-engineer one application at a time, with no feedback loop and no infrastructure validation. Avcel extracts the full phenotype of your portfolio, produces a carbon copy, and validates delta features against it before anything reaches prod. That's not a prompt. That's a compiler.
Phenocel is the part of Avcel that reads a brownfield estate the way a geneticist reads an organism. Source code is the genotype: what's written. The phenotype is what your systems actually express: their running behavior, their dependencies, the tribal knowledge that never made it into a doc. Generic tools read the genotype and guess. Phenocel captures both, so agents build against reality instead of documentation. It's the reason we can prove a change works before anything touches production.
Phenocel is a capability inside Avcel, not a separate product. When someone asks how Avcel understands a codebase it has never seen, this is the answer with a name. Extraction is automated, and optional: teams that already hold their own context can supply it directly instead. Select a step to see how it works.
Once Phenocel has mapped your environment, the control plane coordinates specialist agents, human-in-the-loop gates, and evaluation, converging on assets you can trace end to end.
Work starts in your language, not a backlog format. Avcel turns business intent into a structured brief that every later stage traces back to.
The brief becomes architect-grade requirements: business case, acceptance criteria, and support docs, with your control framework attached before a line of code exists. Fully traceable, human-reviewed at every step.
AI agents plan the build, then execute it inside sealed sandboxes: isolated, deployable fully air-gapped, and bounded by the guardrails you set. Before anything moves, it's tested against a functional carbon copy of your environment: proof it works, not a promise.
Every change is verified against the requirements and recorded against policy, producing the evidence file as a natural output of the work.
Product screenshots of the Requirements Builder, Delivery Blueprint, and Evaluation views are being finalized and will appear here.
Most AI development tools are a prompt with a hope attached. You describe what you want, a frontier model returns something plausible, and you find out whether it was right in production. Avcel replaces that with a compiler: a deterministic pipeline that refuses to emit a promotable artifact unless validation passes.
A prompt fails in production. A compiler fails at build.
The compiler is a self-contained CLI wrapping a point model of your choosing. It produces the Delivery Blueprint with no frontier-model dependency, which means the part of the system that matters most can run entirely inside your walls.
Configure a local model and the deployment has zero external egress. Nothing is posted out. Nothing needs to be.
Because the output is a structured, versioned contract rather than a vendor-specific artifact, it isn't bound to one model, one provider, or one toolchain. When the model landscape shifts again next quarter, the blueprint survives it.
That portability is also your exit: the specification is yours, in a form another tool can act on.
Compiler behavior is deterministic and gated. The generation step is probabilistic, as it is everywhere. The difference is that a probabilistic generator sits behind a validation pass that can refuse to promote.
This isn't a claim that nothing else exists. It's a map of exactly what each category leaves for you to build yourself.
Every blueprint is checked against your actual infrastructure-as-code, not just your source code. Terraform and platform policy are validated before generation, so a violation blocks the build instead of surfacing in review three weeks later.
Ask any other AI development vendor what happens when an agent modifies a Terraform module. Most of them validate application code and nothing else. That gap is where the next round of audit findings is going to come from, and almost nobody is looking at it yet.
A capable engineer with a frontier model can restructure a single application. What breaks at portfolio scale is consistency: no shared feedback loop, no infrastructure validation, no memory carried from one app to the next. Phenocel extracts the phenotype of your whole portfolio and Avcel governs the path before and after code, holding that discipline across every app, not just the one in front of you. The question a generic tool can't answer: do you have anything like Phenocel?
Frameworks like SpecKit, OpenSpec, and Kiro are a real starting point: they force a spec before code. But a spec is static the moment it's written. Avcel captures metadata dynamically and tunes to your enterprise at a finer grain: how many apps depend on Ping Identity, where SAML shows up, which systems don't play well together. A generic toolkit says "capture your single sign-on" and stops. Avcel is recursive and self-learning: a live cell in your organization, not a form you fill out once.
A productized, repeatable delivery model, with AVM accountable through go-live, not a bespoke SOW that resets to zero on the next engagement. Changes outside the original scope go through an approval gate, so scope creep gets flagged instead of quietly billed.
Tools like Portkey or Bedrock solve governance at the model-call layer; platforms like Braintrust, Arize, Galileo, and Maxim solve evaluation. Both are real, both are useful, and both are one part of what a governed SDLC requires. Avcel orchestrates the full lifecycle around them and integrates with the ones you already run, rather than recreating mature plumbing.
The newest entrants design, build, host, and maintain the software they deliver. That is a real model, and it works until your regulator, your board, or your concentration-risk policy asks where the production system actually lives. Our compiler is a self-contained CLI wrapping a point model, so the blueprint is generated inside your walls with no frontier-model dependency. Two questions worth asking any vendor in this category: where does the system run when you're done, and what does my exit look like in year four?
The AI development harness orchestrates specialist agents against your blueprint. Every action stays behind the policy gate: no model call the platform doesn't account for.
Coordinates specialists across the run, sequencing work against the blueprint and the policy gate.
Mapped roles: architect, architecture, design. Owns structural and architectural decisions.
Mapped roles: product, manager, PM. Keeps delivery traceable back to the requirements.
Mapped roles: QA, quality, test. Verifies output against the evaluation gate before it ships.
Underneath the four-stage lifecycle, every request compiles through the same seven-layer pipeline. Three layers are fixed rules that always return the same result. Three involve a model. One is mixed. The single generation call is verified and cached, so the blueprint it produces is byte-identical on every run for the same inputs.
We label each layer by what it actually does rather than badging the whole pipeline "deterministic," because a reviewer will check. Select a layer to see what it does.
Fixed rules or templates. The same input always produces the same output, every time, with no model involved.
Schema checks and content hashing. Policy rule evaluation, where deny wins. Template mapping in the adapter.
Patterns and thresholds written by people. Plain code doing pattern matching, still no model call.
Section extraction from a library of known heading patterns. A confidence threshold deciding when a learned pattern applies automatically.
A model generates. Every call is bounded by policy, budgeted, and validated before its output moves.
Transcription and extraction from free text. The one blueprint generation call. The coding agent, inside a sandbox with permission checks.
Language models are not reproducible, even at temperature zero. Rather than pretend otherwise, Avcel calls the model exactly once, verifies the result against your repository, and caches it under a key derived from the signed-off representation, the prompt, the model version, and the schema. As long as those inputs are unchanged, every subsequent run returns the same blueprint, byte for byte.
Hashed together with the prompt, model version, and schema. One key.
On the first miss only. The result is verified against named paths in your repository.
Stored and served from then on. No second call for the same inputs.
Every run, same inputs, same output. Change an input and the key changes with it.
This is where the determinism claim honestly stands. The generator is probabilistic. The pipeline is not.
It is also the answer to the question every reviewer eventually asks about AI-generated code: can you reproduce it? For the same inputs, yes, exactly, and the audit record shows which key produced which artifact.
Any layer that needs a model routes through a single choke point. That is what makes model policy enforceable rather than aspirational: one place to configure, one place to audit, one place to change your mind.
Fastest path to a running pilot. Usage is metered and visible, with no provider relationship required on your side.
Your existing account with your chosen provider. Your commercial terms, your rate limits, your logs.
A model running inside your own network. This is the configuration behind the fully air-gapped deployment: no call reaches the public internet.
Blueprint generation runs on a small model that operates inside your perimeter. Frontier models are selectable and can also be reached without leaving your boundary, through a private endpoint such as a VPC-hosted provider service.
Concentration risk and exit provisions are the questions a board asks in year one and regrets not asking in year four. Here is the plain answer.
The running system, inside your network. The Delivery Blueprint, which is a structured, versioned, tool-neutral contract. The evidence record behind every change.
You are not holding a hostage artifact. The blueprint is a real specification in a tool-neutral format, and it stays useful in anyone's hands. That is deliberate: a governance system you cannot leave is not a governance system, it is a dependency.
Avcel itself, including the model that generates blueprints, licensed to run in your environment rather than rented from ours.
Any specification is accurate only as of the moment it was written, and your systems keep changing after that. Drift is a fact of every estate, not a property of our licensing. The license is what regenerates the blueprint against the current state of yours, so it stays true rather than becoming another document nobody trusts.
If you stop, you keep everything already delivered. What you give up is the ability to recompile.
Cost control at Avcel isn't a metering feature bolted onto the platform; it's how delivery is run. Scope is fixed before work starts, each of the four stages ends at an evaluation gate, and nothing moves to the next stage (or the next invoice) without sign-off. That's how AI project spend stays predictable instead of becoming an open-ended token bill.
Self-hosted on Kubernetes in your environment: your cloud accounts or your data center. Deployable fully air-gapped, and in production that way today at a Tier-1 regulated U.S. financial institution.
Bring the AI models your policy allows, hosted where your policy says. No calls to outside model providers required.
AVM installs, integrates, and hands over a running system, then stays accountable through delivery of your first governed workloads.
Avcel's documentation is written for the people who have to say yes: engineers, architects, security reviewers, and examiners. Full documentation ships with your instance; the set below is available on request.
From installed instance to first governed change: the shortest path through the four stages.
With your instanceComponents, trust boundaries, and how the sealed sandboxes are constructed and torn down.
On requestHow policy is expressed, enforced at each gate, and compiled into the audit record.
On requestKubernetes requirements, image provisioning, and operating without external package resolution.
On requestIsolation model, data handling, model hosting, and the review posture for regulated environments.
On requestThe questions risk teams ask first: answered in their language.
On requestA carbon copy is a stateless binary replica of your environment. Changes are executed and validated against it before anything is promoted to production, so a failure surfaces at build rather than in front of customers. It is inspectable by your own architects, unlike a staging environment that has drifted from production at an unknown rate.
Phenocel is Avcel's context extraction capability. Source code is the genotype: what was intended. The phenotype is what actually runs: runtime behavior, real dependencies, infrastructure, and the operational knowledge that never reached a document. Phenocel captures the phenotype across a portfolio. Extraction is automated and optional; teams holding their own context can supply it directly.
Yes. Terraform and platform policy are validated alongside application code, before generation, so a violation blocks the build instead of surfacing in review weeks later. Most AI development tools validate application code only and leave the infrastructure layer unchecked.
A prompt sends a description to a model and hopes the result is correct, which you discover in production. A compiler refuses to emit a promotable artifact unless validation passes. Avcel's generation step is probabilistic, as everywhere, but its validation and promotion pipeline is deterministic and gated. A prompt fails in production. A compiler fails at build.
Yes, for the same inputs. Language models are not reproducible even at temperature zero, so Avcel calls the model once, verifies the output against your repository, and caches it under a key derived from the signed-off representation, the prompt, the model version, and the schema. Every later run returns the same blueprint byte for byte. Change an input and the key changes with it. The generator is probabilistic; the pipeline is not.
Three layers are fully deterministic: the internal representation with its schema checks and content hashing, the policy engine where rule evaluation decides and deny wins, and the adapter layer which is template mapping only. Ingest is mixed, using fixed parsers plus a model to extract structure from free text. Blueprint generation is one cached model call. Feedback and the coding agent also involve models, both bounded by policy and permission checks.
Yes. The Delivery Blueprint is a structured, versioned, tool-neutral contract, and it stays useful in anyone's hands. That is deliberate: a governance system you cannot leave is a dependency, not a governance system. You also keep the running system and the evidence record. What the license provides is regeneration, recompiling the blueprint against the current state of your estate as your systems change.
Blueprint generation runs on a small model operating inside your perimeter, not a frontier model. Every model call in the platform routes through a single gateway you configure three ways: our metered account, your own provider key, or your own endpoint. Choose your own endpoint and no call reaches the public internet. Frontier models remain selectable and can also be reached without leaving your boundary through a private endpoint.