Company · The Qawex Charter

What we won't build around.

Five commitments that hold regardless of client, industry, or deadline. The Qawex Standard's 63 rules exist to enforce these five — the Charter is why the rules are shaped the way they are.

charter.doc
Q
The Qawex Charter5 articles · binds every engagement
I.Human-in-the-loop by defaultNo agent acts without approval unless the exception is published
II.Data sovereigntyYour data stays yours — ownership, location, and export are never ambiguous
III.Kill-switch, alwaysEvery automated system can be stopped, fully, by a human, at any time
Quick answer

The Qawex Charter is the set of five non-negotiable commitments behind everything Qawex builds — human-in-the-loop by default, data sovereignty, a working kill-switch, transparency of exceptions, and accountability through citation. Where the Qawex Standard gives you 63 specific, numbered rules, the Charter is the reasoning underneath them: the promises the rules exist to keep. A rule can be added, refined, or versioned. A Charter article can't be quietly dropped to win a deal.

5Articles
63Rules implementing them
0Silent exceptions

Why most AI commitments don't survive contact with a real deadline

Principles that live only in a pitch deck get quietly negotiated away the first time they're inconvenient.

FAILURE 01
Commitments with no owner
"We believe in responsible AI" doesn't say who checks that, or against what. Nothing in that sentence can be violated in a way anyone would notice.
FAILURE 02
No real off switch
A lot of "human oversight" language describes a dashboard someone could theoretically check, not a system that actually stops when told to.
FAILURE 03
Data ownership left vague on purpose
Ambiguity about where data lives and who can export it isn't an oversight — it's often the business model. The Charter closes that gap by design.

The five articles

Each article is implemented by specific rules in the Standard — this is the principle each of those rules is protecting.

I
Human-in-the-loop by defaultIntelligence
No agent or automated system acts without human approval unless a narrower, published exception exists — bounded, time-limited, and logged. See INT-01 and its one documented exception, INT-01-EMERGENCY.
II
Data sovereigntyEngineering / Cyber
You know where your data lives, who can access it, and how to get all of it back out. Ownership is never a support ticket away from being unclear.
III
Kill-switch, alwaysEngineering
Every automated system we build can be fully stopped by a human, immediately, without needing us on a call to do it. Reversibility is a build requirement, not a support promise.
IV
Transparency of exceptionsCyber
When a rule genuinely can't be followed as written, the exception gets its own ID, a stated scope, and a log — never a quiet workaround nobody can point to later.
V
Accountability through citationGrowth / All pillars
A claim we make about how something was built has to be checkable against the actual page or system it describes. Rule IDs are published where they apply, so "we follow best practices" is never the whole answer.

How the Charter gets enforced, not just stated

A charter that isn't operational is a marketing page. Here's what makes this one operational.

1
Every article maps to specific Standard rules
No article stands on its own — each one is broken down into numbered, testable rules under the relevant pillar.
2
Rules are attached to the deliverables they govern
During scoping, the applicable rules — and by extension, the Charter articles behind them — are mapped to what's actually being built.
3
Kill-switch and approval flows are tested, not assumed
Where an article implies a mechanical guarantee — stop, approve, export — that mechanism is verified to actually work, not just documented.
4
Any departure is published, scoped, and logged
If an engagement genuinely needs an exception, it gets its own ID and boundary — the same pattern used for INT-01-EMERGENCY — never a silent deviation.
5
The Charter is versioned, not silently rewritten
If an article changes, it changes on the record, with a version noted — not edited away because it became inconvenient for one deal.
5
Charter articles
63
Rules implementing them
1
Documented exception — stated, not hidden

"A backup only counts once it has actually been restored — not once it has been taken." — ENG-01, implementing Article III, Kill-switch, always.

Source: Applied across Engineering pillar builds →

Frequently asked

What's the difference between the Charter and the Qawex Standard?

The Charter is five foundational commitments — the "why." The Standard is 63 numbered, specific rules that implement those commitments in an actual build — the "how." Every Standard rule traces back to one of the five Charter articles.

Can a client ask for an exception to the Charter itself, not just a Standard rule?

The Standard has narrow, published exceptions to specific rules. The Charter's five articles don't get exceptions — they're the baseline the exception process itself has to operate within.

Does the kill-switch commitment apply to every product, including free tools?

The kill-switch article applies where there's an automated system with ongoing effect — agents, workflows, integrations. A static free tool like First Aid doesn't run an automated process on your data, so the article isn't applicable there in the same way; Article II on data sovereignty still is.

Has the Charter ever changed?

It's versioned rather than fixed forever — if an article is refined as our practice matures, that happens on the record with a version note, not as a silent edit.

Where can I see the Charter applied to a real product?

The clearest example is Telemedicine, where INT-01-EMERGENCY shows Article I and Article IV working together — a narrow, published exception to human-in-the-loop for time-critical escalation, logged rather than hidden.

Want to see the Charter mapped to your project?

Tell us what you're building and we'll show you which articles and rules apply before any work starts.

Talk to us
Scroll to Top