Questions,
answered.

An independent layer that proves AI-produced work. Whatever a model makes, Praxis checks it against what was actually asked and shows that it holds. It sits outside the model, so the proof doesn't rest on trusting the thing that did the work. Why this matters.

Vibe coding means jumping straight from a rough ask to output and hoping it's right. Anti-vibe coding keeps the speed and puts the plan back. The ask becomes a spec you can audit, and every step is checked against it. You still move fast. You just stop shipping on faith. How it works.

CRAFT is the pipeline that turns a rough ask into software you can prove. Five stages, Capture, Rehearse, Author, Field, and Track, with one spec running through every one. Anti-vibe coding is the discipline. CRAFT is how you do it. See the pipeline.

Yes. There is a live check on the site. Bring a piece of AI output and the ground truth it should answer to: a code change and the test it must pass, a claim and its source, a number and the data behind it. Watch it get held to the standard right in your browser. Nothing is uploaded. It runs one check. The real pipeline runs hundreds. Try the live check.

No. Turning an RFP, SOW, or brief into an auditable spec is what runs today, but the standard isn't tied to that. The same three checks land on a document, a code change, or an analysis. The substrate doesn't care about the domain. It cares that what shipped can be shown to be right.

An RFP, an SOW, a brief, or an unformed idea. Praxis turns it into a spec you can audit, and stands behind what comes out of it. Whatever you bring, you can follow every claim back to the ask.

A dossier you can hand to a client: an executive summary, the technical design and the reasoning behind it, infrastructure, a low-level design, a delivery plan, and the diagrams that make it legible. Every claim ties back to a requirement, and every requirement ties back to your ask. See what ships.

Every requirement is numbered, measurable, and traced back to the sentence in the ask it came from. What the ask left out is flagged as an open question, not filled with a guess. You can hand it to an evaluator who trusts none of it, and they can check it line by line. See the specification.

The spec is your requirements, lifted out and made auditable, with the gaps named instead of guessed. The dossier is the full deliverable Praxis builds from that spec: the design, the plan, and the diagrams. The spec is the foundation. The dossier is what goes on the table. See the specification.

Yes. The dossier keeps a consistent backbone, an executive summary, technical design, infrastructure, low-level design, delivery plan, and a traceable appendix, and it can be shaped to your house format and branding. The sections scale with the work, from a short brief to a full build.

Every step carries a record: the claim, the check that ran against it, the result, and a trace back to the requirement. Three independent parties sign it, a maker, a pilot, and a watcher outside the system. What ships is a record you can check, not a promise you have to trust. See proven delivery.

The maker checks its own work, a pilot re-checks every step against the contract, and an independent watcher checks the pilot. Nothing ships unproven. See the three checks.

That's what the checks are for. The pilot re-checks every step against the contract and an independent watcher checks the pilot, so a mistake is caught before it ships. Where the source is genuinely silent, the gap is flagged as an open question, not filled with a guess.

Every requirement points back to the sentence it came from, and every diagram and claim ties back to a requirement. You can follow the thread end to end and audit the coverage yourself, instead of taking the output on faith.

No. Praxis runs on any model, cloud or your own hardware. The model is swappable. The verification stays constant. Sovereign and on-prem are just one end of the same dial. See everywhere it runs.

Frontier models including Claude, GPT, Gemini and Grok, and open weight models including Llama, Qwen, DeepSeek, Kimi, Mistral, GLM, MiniMax, Nemotron and gpt-oss. Every open weight model on that list can also run inside your own network, on GPUs, on TPUs, on Gaudi, or on the accelerators already built into your machines. The list grows without a release, because a new model from a maker already there is a line of configuration. See the full roster.

Pick the model that fits your cost, latency, or sensitivity needs: a frontier model, an open one, or a local model on your own hardware. Praxis treats the model as swappable, so the choice stays yours to change at any time, and the verification around it doesn't move. Why switching costs you nothing.

Teams that have to stand behind what they ship. Bid and proposal teams turning an RFP into a proposal they can defend. Founders pressure-testing an idea before they build it. Engineering teams shipping AI-written code they can trust. And regulated or sovereign organisations that need an audit trail on their own ground. See how it fits together.

Yes. The record is written while the work happens, not reconstructed for the meeting. Every decision traces to a requirement, the model and the ground it ran on are yours to choose, and a watcher outside the system signs the result. For regulated and sovereign.

Yes. Praxis runs in the cloud or on your own hardware, including on-prem and sovereign setups. The work never has to leave your environment for the verification to hold.

Yes. Praxis can run entirely on your own hardware, in your own region, with a local model, so both your work and where it lives stay under your control. Nothing has to cross a border or a vendor boundary for the verification to hold.

Your work stays under your control. On an on-prem or local setup it never leaves your systems, so it isn't sitting on someone else's servers. You decide what's shared and where it's processed.

No. Your work is used to do your work, not to train anything. You decide what to share, and on an on-prem setup it never has to leave your own environment.

The contact form composes an email in your own mail app and keeps a copy on screen for you. Nothing reaches us until you send it, so you decide exactly what to share and when.

The source ask is enough: the RFP, SOW, or brief you're responding to, or the idea you want pressure-tested. If parts are missing, Praxis flags them as open questions rather than guessing, so you can start with whatever you have.

You send a note. A person reads it and replies about your actual work. Then we run one real piece of it, something you bring, and show you the pass with you watching. There's nothing to pay for the first run. If it holds, we scope the work from there. No drip sequence, no sales bot. Request access.

That is what CRAFT is: the pipeline builds from the spec with a check on every step. Turning a fuzzy ask into an auditable spec is substantially there today, and the build stages carry the same spec forward, so the code answers to the exact thing you agreed. See the pipeline.

Use them. Praxis runs on them. Those tools write the work and they are good at it. What none of them can do is prove their own work, because the tool being checked and the tool doing the checking are the same tool. Praxis sits outside that. The maker writes and checks itself. A pilot then re-derives every step against the contract with a reasoning engine, so the verdict is worked out rather than guessed. A watcher outside the whole system checks the pilot. You keep your editor and your model. You add the proof they cannot give you about themselves. See the three checks.

The words are the same and the mechanism is not. A built-in rubric asks a model whether the work looks good. Ask again tomorrow and the score can move, and nobody outside can work out how it got there. The check that gates a step in Praxis runs on a reasoning engine. It reads the work, applies the rules that were agreed, and reaches the same verdict every time. The watcher outside the system runs that same check from its own read of the files and has to reach the same verdict too. One answer you take on trust. The other you can repeat. How the checks hold.

Because a vendor cannot sell you independence from itself. Every check a model maker builds runs inside its own product, grades its own output, and stops working the day you switch. Praxis is not tied to any of them. Change the model and your standard, your record and your proof all stay put. That is the point of keeping the check outside the thing being checked. Which models it runs on.

No. Asking a second model to grade the first one gives you another opinion from the same kind of thing, with the same blind spots. The check in Praxis is a reasoning engine. It works the verdict out from the contract that was agreed and refuses anything it cannot tie back to it. The model writes the work. It does not get a vote on whether the work passed. Watch a check run.

Those tools help you write a spec, and a good spec beats guessing. Praxis starts there and keeps going. The spec turns into pass or fail checks before any code is written. The build answers to it one gated step at a time. The deploy reads its rules from it. Production watches the targets it set. Every requirement stays traceable to the sentence it came from, the whole way through. A spec is a document. What Praxis adds is the proof that what shipped actually followed it. See the five stages.

Yes, and you do it in settings, not in code. Choose the model per run from the front end. Put a frontier model on the hard reasoning, a cheaper or faster one on the routine passes, and a local model on anything sensitive. Mix them in the same engagement if that is what the work needs. The checks around each step do not change when the model does, so swapping is a cost and speed decision rather than a standard decision. See the roster.

Yes. Praxis can pull weights from an internal container registry, from a model hub, from an object store, or from a path already mounted on your machines. Licensed and gated models are handled through the same path, with the licence checked before anything is fetched. That matters if the model you are cleared to use is not the one on a public download page. How models are supplied.

Because the exact one is recorded and checked. Two runs of the same model name are not the same substrate if the quantisation, the context window, the runtime version or the precision differ. Praxis pins the specific release, checks the digest of every file it pulled, and records what served the work in the seal. The point is that nobody can swap the substrate under a sealed engagement and have it pass quietly. What the record holds.

It still holds. The record says what ran, and the checks are written against the contract rather than against a model, so an old result stays readable and a new run gets held to the same standard. Moving from a frontier model to one on your own hardware changes your cost and your speed. It does not change what counts as passing. Change the model, keep the proof.

Yes. Open weight models can run inside your own network, on your GPUs or on the accelerators already in your machines. Weights can come from a registry or a mount you control rather than a public download, and the checking runs where the work runs. Nothing has to leave your environment for the proof to hold. Regulated and sovereign setups.

No, and that is part of the point. The check does not get weaker when the model gets cheaper, because the check is not the model. Teams often find a smaller model is fine once the spec is precise and every step is held to it, since most failures come from a vague ask rather than a weak model. Start where your budget is and move up only where the work shows you need to. Why the model is an input.

They are good and they are getting better, and Praxis is not trying to replace them. Point one at a CRAFT contract and it does the making inside a set of rules it did not write. The difference is what happens when the agent is wrong. On its own it plans, builds and then judges its own work, which is the same tool marking its own paper. Inside Praxis a pilot re-derives every step against the contract, and a watcher outside the whole system checks the pilot. Use the strongest agent you can get. Just do not let it be the last word on whether it succeeded. See the three checks.

Useful, and only half the loop. Reading production tells you something broke and suggests a change. It cannot tell you which requirement that thing was supposed to satisfy, because nothing wrote one down. Praxis sets the targets at the start, carries them through the build and the deploy, and watches them in production as the same targets. So a failure points back to the promise it broke, and a fix has to restore that promise before it passes. Detection without a contract is a smoke alarm. Useful, and not a plan. See how Track closes the loop.

Ask what is being counted. Most of that number is typing, which means code written or pull requests opened. Those are real and they are also the easiest thing to measure. Work that gets reviewed twice was not fast. Work rewritten next sprint was not fast. Work that fails in production and costs three people a week was the most expensive fast there is. Praxis moves the whole job instead of one stage, including the discovery, the design, the estimate, the plan, the review and the evidence. We will not quote you a multiple we have not measured. We will tell you exactly what is checked and let you count your own. What the multiplier is measured on.

That is what most of the industry decided in 2026, and it tells you something. Model access alone was not landing deployments, so the biggest names started embedding engineers with customers to make the work stick. It works, and it costs salaries, and the standard travels with the person. Praxis puts that discipline in the pipeline instead. It runs on every step, on every engagement, at the same standard, whether anyone senior is looking that day or not. Keep your best people on the hard problems rather than on checking whether the work was done properly. Why we built it this way.

No, and that is the main difference. Writing was never the slow part. The time goes on working out what was actually asked for, deciding how to build it, estimating it honestly, planning it, reviewing it, and proving at the end that what shipped is what was agreed. Praxis carries one spec through all of that. The document you hand a client and the code you ship come from the same source, so they do not drift apart the week the deal is signed. See the five stages.

The first run is on one real piece of your work, with a person, and there's nothing to pay for it. After that we scope it to your work rather than quote a number at a form. Tell us what you'd verify and we'll talk it through. Request access.