Purpose

1. People stay in charge

AI is a tool for the people doing the work. It extends their judgment; it does not replace it.

• A named owner. Every system we help put in production has a named owner on your side. Autonomy is a permission granted task by task, not a default.
• Pause and override. Someone on shift can pause an automation without waiting on us, and people can override or decline an automated result.
• No quiet restrictions. We do not build systems that quietly take choices away from the people using them “for their own good.” When a system refuses, blocks, or escalates, it says so and says why.
• The go-live question. Before a system goes live, we ask one question of it: does it measurably improve the work, the time, or the agency of the people who use it? If not, we redesign it or retire it.
• Roles, in the plan. If a workflow change affects someone’s role, we say so in the plan, not at launch, and we design the change around moving people toward the work only they can do.

2. You own your AI

Your data, your accounts, and your choice of model stay yours.

• Least data. We use the least data that makes the workflow work. Regulated or secret material does not go into a model path we cannot justify.
• Choice, explained. Model and tool choices come with clearly written language — that regular folks can understand. We include what it would cost to switch. Where it fits, open models can run on your own hardware so sensitive files and customer data never go to an outside AI provider. See the Toolbox.
• No silent changes. We pin model versions and tell you before changing one, so behavior does not shift under you without notice. Hosted models can still be changed or retired by their provider; we flag that dependency up front and plan a fallback.
• Portable by default. Credentials stay in your control. Configurations, prompts, evaluation cases, and documentation are handed over in readable form, so ending an engagement does not mean rebuilding. And we can provide this, optionally, integrated into any system for secrets or credentials you already use.
• Right-sized. Small, inexpensive models handle routine work. Larger models are used where the task needs them, under a spend cap you set. And we believe in leveraging all the newest, vetted tools designed to minimize the cost to you.

3. Systems say what actually happened

A system that reports success it did not achieve is worse than one that fails loudly.

• Fail closed. Failures, partial completions, and expired connections are reported as such in the activity log, not smoothed over with a confident “done.”
• Controls live outside the model. Permissions, allowed-tool lists, spend limits, and confirmation steps for irreversible actions are enforced in software, not only written into a prompt. Instructions inside a model’s working memory can be truncated, forgotten, or overridden.
• A second check before irreversible actions. Deleting records, messaging customers, or moving money requires a person, or a second check that does not share the first one’s blind spots, before it runs. Disagreement stops the action and is logged.
• Vendor safety is one layer. We do not treat a model vendor’s built-in safety training as a sufficient control by itself. It is one layer among several that we design and test.
• We test for flattery. Evaluation includes cases where the right answer is “no,” “I don’t know,” or a disagreement with the person asking. If it cannot be tested against representative cases, including failure cases, it is not ready.

4. Know where the information comes from

• Your records first. Where a system retrieves information, we prefer your own verified records and documents to generic web content, and we list the sources it draws on.
• Untrusted input stays untrusted. Inbound email, web pages, uploaded files, and third-party plugins or skills are treated as potentially hostile. They cannot give the system orders, the tools a system may use are allowlisted, and anything third-party is reviewed before it is installed and runs with least privilege.
• Generic advice is a starting point. General-purpose models tend to answer with whatever is fashionable, whatever your context. For strategy and trade-offs we use AI to generate options and evidence, ask for the counter-argument and for real successes and failures, and leave the decision with people.
• Provenance on what we build. When we assemble a retrieval index or a fine-tuning set, its sources are recorded and a named person on your side approves what goes in.

5. Nothing runs out of sight

• No hidden behavior. Software we build does not install, track, or collect anything it has not told you about. Anything a system installs, collects, or connects to is documented before go-live. We do not use dark patterns.
• Providers, named. We tell you which outside model providers touch your data, and what each one retains and whether it trains on inputs, according to its published terms. Where we have not verified a provider’s terms, we say so.
• AI identifies itself. Customer-facing AI identifies itself as AI. We do not build systems that pose as a person.
• Provenance marks, disclosed. Where AI-assisted work product carries a disclosure or provenance mark, whether required by law or added by a vendor, we tell you. We do not add undisclosed identifiers to deliverables.

6. Built to serve people, not to hold their attention

• No engineered dependence. We do not build AI designed to maximize dependence, or to imitate affection in order to drive usage or sales.
• Behavior changes are approved. Changes to how a customer-facing assistant behaves are versioned and approved by its owner. They are not pushed quietly.
• Your team keeps the skills. Your team should end an engagement more capable, not more dependent. We design training and documentation so your people keep the skills the AI touches, and so what your business knows is written down in your hands, not only embedded in a tool, or in us.

7. Honest scope, honest results

• The right answer, even when it is smaller. We will say when a rules engine, a vendor product, or no project at all is the better answer. We will not fit a foundation model onto a problem to keep an engagement alive.
• Results against the goals. Results are reported against the goals set in week one, including when a project did not pay for itself. We do not present activity volume, or headcount reduction on its own, as success.

8. Law, limits, and who this does not cover

Tell us when something is wrong