What a factory must prove.

These five are not features. They are the things any agent-built artifact has to carry before you trust it. Skip one and you are guessing.

A feature is something a product picks up because it sounds good. This is not that. Each item below is a question someone accountable already asks, in their own words, before they let machine-written code into the thing they answer for. The factory does not get to dodge the question. It has to hand over the evidence. Here are the five, plain, with the answer each one demands.

01 · Provenance

“How do I know I can trust this?”

Every artifact carries its own evidence. Where it came from, the checks it passed, and who or what produced it travel with the code, not in a separate report nobody opens. Trust here is not a vibe you extend to the factory after it behaves for a while. It is a property of each piece of output, set by provenance and checkable on inspection. Nothing is trusted because someone said so. It is trusted because it can be shown.

02 · Consistency

“How do I know it will not drift?”

The same intent yields the same class of result, every time, no matter who or what ran it. Gates decide pass or fail on stable criteria. Runs reproduce, so a result can be regenerated and checked instead of taken on faith. What this defends against is silent drift: the slow slide where output quietly stops matching intent and nobody notices until it has shipped. Consistency is what makes a factory a factory and not a run of lucky one-offs.

03 · Enterprise-safe

“How do I keep the company out of trouble?”

Policy, security, licensing, audit, and accountability are built into the floor of the factory, not bolted on later. The rule is simple: the factory cannot ship what the enterprise has not permitted. Permission is enforced, not asked for. Every artifact carries the audit trail showing which policies it cleared and on whose authority, so when a machine wrote the code and someone asks who is accountable, the answer holds up.

04 · User-safe

“How do I protect the people who use it?”

Safety, correctness, privacy, and recourse are constraints enforced up front, not promises made after the fact. A promise made after shipping is only as good as the next incident. A constraint enforced before shipping is a gate the output had to pass. The end user, the person who never sees the factory and only meets its output, is protected by the gate, not by an apology. Privacy is held, correctness is checked, and there is a real path to recourse when something still breaks. Built in, not assured.

05 · Debuggable

“How do I fix it later?”

The output is something a human can read, trace, and own years after it was generated. No black boxes reach production, because a black box cannot be debugged at 3am by someone who did not write it and may not have been around when it shipped. Longevity is not a bonus tacked on at the end. It is part of trust: code you cannot understand later cannot be trusted now, because trust includes trusting that you can still fix it.

One bar, three rungs

Together these five are the bar. They are the same across the family, on purpose. jusCode and jusInfer generate in their own domains, and the machines still to come will generate in theirs, but every one of them has to clear this one definition. That is why we write it down once: so trust does not get redefined product by product, and so a company can hold the whole family to a single standard it can audit. The three rungs, certify the engineer, then the agent, then the code, are built to enforce exactly this. The machines generate. jusFactory is what they all must prove.