Manifesto

How we build Wizard.

A technical read, written for CTOs, VPs of engineering, and infra folks. This is the architecture under the Trust Promise — where the principles live in code, not in a policy PDF.

0. Why this document exists

Every AI-for-revenue vendor writes a privacy policy. Very few of them describe the architecture that backs it. This manifesto is the opposite: the architecture is the commitment, and every clause is traceable to code.

If a statement below is marketing, it's wrong. If you're evaluating Wizard and a promise here doesn't match what we've shipped, call us on it and we'll either fix the shipped reality or retract the promise.

1. Minimize — data we don't have can't leak

Every Wizard connector has a manifest. The manifest names the fields Wizard is allowed to read from your Salesforce or HubSpot org. Anything not on the manifest is unreadable — not "unasked," unreadable. The OAuth scope enforces it, and the in-process data adapter refuses anything outside scope.

This matters because the category default is "pull broadly, filter later." Wizard pulls narrowly, always. If you need a new field, you add it to the manifest; the manifest change is a tracked, auditable event.

2. Encrypt — per-tenant envelope, BYOK at Growth+

Each tenant gets its own encryption envelope. Embeddings, vector indices, intermediate agent state, and signed action logs are scoped to the tenant envelope. There is no shared embedding pool and no cross-tenant retrieval surface.

At Growth and Enterprise, BYOK is available: the tenant supplies the KMS key that unwraps the envelope. Warden Systems cannot read the envelope without the tenant's cooperation. Key rotation is the tenant's call, not ours.

3. Explain — signed rationale per autonomous action

Every action Wizard takes ships with a signed rationale record: the prompt context, the retrieved evidence, the model that produced the action, the autonomy tier in effect, the policy gates crossed, and a cryptographic signature over the whole packet. Default retention is 12 months, exportable on demand.

This is the audit trail that makes HITL meaningful. Not a log that says "an email was sent," but a record that says why the email was sent, what else was considered, and who (human or agent) approved it.

4. Empower — pause, rollback, revoke, inside 24 hours

Any autonomous action can be reversed inside a 24-hour window. External sends can be recalled where the downstream system supports recall. CRM writes carry a compensating-transaction record that rolls them back cleanly. Contract sends go through a hold-and-release stage before signature.

Higher autonomy tiers (Execute-with-HITL, Autonomous) ship with a mandatory action log and a tenant-owned kill-switch. The kill-switch is a one-call operation that quiesces the agent surface, freezes the outbound queue, and preserves the log for forensics.

5. Expire — deletion is an artifact, not a checkbox

On exit, Wizard produces a cryptographic deletion certificate: the hashes of the artifacts deleted, the key shred that renders the envelope unreadable, and the timestamps of each step. Default prompt-and-output retention is 30 days; configurable to zero. The deletion certificate is exported to the tenant before the keys are shredded, so the tenant keeps the receipt.

6. Agent autonomy — four tiers, HITL where it matters

Wizard runs at one of four autonomy tiers, per-capability:

  • Advisory. Wizard shows what it would do. A human executes. No writes, no sends.
  • Suggest. Wizard drafts the artifact (email, CRM update, contract). A human reviews and clicks send.
  • Execute-with-HITL. Wizard acts, but gated by an approval step. Default for anything touching external systems at scale.
  • Autonomous. Wizard acts without a per-action approval. Reserved for the narrow set of actions the tenant has explicitly whitelisted; always wrapped by the kill-switch and a mandatory log.

Four action classes always require HITL regardless of tier: external send, financial commit, legal text, record deletion. These are non-overridable by tenant config.

7. Sovereignty stack

The sovereignty posture is four things, layered:

  • Per-tenant isolation. Logical isolation at all persistent layers — databases, vector stores, signed-log archives, envelope keys.
  • Self-hosted Documenso. Contracts are drafted and signed inside a Documenso instance you control. Signed PDFs never leave your infrastructure. This removes DocuSign as a sub-processor entirely at the Starter tier, and makes it optional at Enterprise.
  • Typed-field contract templates. No Jinja, no Handlebars, no HTML merge. Template tokenization is a key-lookup substitution into structured typed fields, which eliminates the HTML-injection surface that plagues most AI-generated contract flows.
  • Single-tenant and on-prem tiers.Enterprise tenants can run the full stack on their own infrastructure. The installer is a first-class product, not a services engagement.

8. Local-first LLM routing

Wizard does not assume the largest frontier model is the right answer to every prompt. Every task class has a routing policy. Low-sensitivity, latency-bound tasks (drafts, summarization, extraction) route to local LLMs running on the tenant's infrastructure whenever the tenant opts in. High-judgment tasks (recommendation, strategy) route to the frontier with signed evidence packets.

The routing is observable. Every inference names the model, the provider, and the policy that selected it. No silent fallbacks. No "surprise, that went to a third-party model."

9. Seed-and-feed — sharpening without leakage

Wizard learns. Every deployment sharpens to its environment over time — voice, naming conventions, ICP, attribution conventions, product catalog. This is the seed-and-feed pattern: ship with a seed (the skill pack's defaults) and accumulate a feed (the tenant-specific, tenant-owned corrections).

The feed stays inside the tenant envelope. It is not used to train, fine-tune, evaluate, or improve any model available to any other customer. Period. This is an architectural boundary, not a policy choice — the feed lives behind the tenant's envelope key.

Skills with a decision surface (classification, routing, judgment) run periodic shadow novel-trials to detect drift. Deterministic skills — fixed procedures — do not. The cadence and the shadow-only constraint are declared in the skill's frontmatter and audited.

10. Tenant-owned vaults + kill-switches

The tenant owns the vault. The tenant owns the keys. The tenant owns the kill-switch. Warden Systems operates the service; the tenant owns the substrate. If the relationship ends, the tenant keeps the vault, takes the deletion certificate, and moves on. We don't hold data hostage. We don't charge migration ransoms. We don't tier-gate the export.

11. What we are not

Five things Wizard is deliberately not:

  • Not a model. We route to the right model for the task, including frontier and local.
  • Not a new CRM. We sit on top of Salesforce and HubSpot; we do not displace them.
  • Not an unsupervised autonomy product by default. HITL is on by default for anything that matters.
  • Not an ad-supported offering. We charge for value. There is no surveillance tier, now or later.
  • Not a lock-in. The export is first-class. The deletion certificate is the receipt.

12. The invitation

If you're a CTO or VP of engineering evaluating Wizard for your team, we want a technical review, not a sales call. Ask the hard questions: how does the envelope actually work, what does a failed HITL gate do, what exactly can Autonomous tier write, what does the seed-and-feed audit trail look like in production. We'll answer with code, not slides.

Write to hello@wardensystems.ai, or submit the beta access form and flag that you want the engineering read.