A release is small enough to reverse cheaply. If it is not, it is not a release — it is a bet.
Every deploy is scoped to what a single revert plus one redeploy can undo. The unit of shipping is one behavior change, not one PR. Business-hours production deploys are prohibited (9am–6pm ET, Monday–Friday) because a rolling deploy is a user-visible event, and we take our visible events outside the workday. Feature flags are not a substitute for small releases — they are inside them: land the code dark, verify byte-identical behavior, then flip the flag as its own small step.
The test
If this release breaks in production at 3 AM, what does one on-call engineer do? If the answer is longer than one sentence, we split the release.
What this means for you
You will never wake up to a LightLeapAI product that changed silently and cannot be put back. Every release we ship is designed to be reversed cheaply. When something goes wrong — and eventually something will — you get the old behavior back in minutes, not days.
Trust the agent to author. Verify with evidence. Never on prompt shape. Never on adjacent paths. Never on “it should work.”
Every AI action in a LightLeapAI product pauses on an inline confirmation card before the write lands. The AI proposes; a human commits; the server re-verifies against live authority; and only then does the audit trail record what happened. Guards fire on evidence (did the tool actually succeed?) — never on shape (did the request look like an action?). Every proof of a release is captured on the same path a customer takes — same URL, same authentication, same headers. And every Complementary User Entity Control we've told our SOC 2 auditors that you perform (user management, audit review + export, incident reporting, notification-recipient update, access review) is a first-class product surface, not a policy on paper.
The test
For any completion claim an AI makes (“scheduled,” “created,” “sent”), we can point to the audit row that proves it. No row means the guard failed.
What this means for you
You will never see an AI in a LightLeapAI product claim it did something it did not do. Every action lands with a receipt, or it does not land at all. And every control we told your compliance team you perform, you can actually perform — through a UI we ship, not a spreadsheet we email.
Agent Autonomy
An agent's autonomy is proportional to the tightness of its authority clamp. More autonomy, more clamp — never the other way around.
Every write in a LightLeapAI product enforces role, tenant, and idempotency before the first line of business logic runs. An AI agent's tool catalog is derived from the current principal's authority at each turn — never from a cached ceiling, never from the author's ceiling. Authorship is separated from execution: the agent proposes; the server resolves at apply-time against live authority; pre-computed plans are never trusted. Least autonomy is the default. New capabilities ship with the tightest usable clamp and loosen only with evidence that they can be trusted with more.
The test
For any new AI authoring capability, we can name three roles that MUST be denied — and prove each denial with an audit row.
What this means for you
An AI agent in a LightLeapAI product cannot do anything a human in the same role could not do. If your student cannot roll grades, our agent cannot roll grades on their behalf. AI does not become a back door around your permissions — it is bound by them.
Reversal Discipline
The reversal window is only cheap if we defend the mechanics that keep it cheap.
Deploy freezes are hard gates, not requests. Business-hours production deploys (9am–6pm ET, Monday–Friday) are prohibited. Production writes are single-writer — one deployer, one merge, one push at a time to the main branch. Every push is preceded by fetching the current state and comparing to the expected base; divergence aborts the push; force-pushing to production is prohibited. These are the machinery that make Article I's promise (cheap reversal) hold in practice.
The test
Before any push to production: (a) inside the deploy window? (b) is main at the expected state? (c) am I the only writer? Any “no” or “not sure” — the push waits.
What this means for you
Your LightLeapAI products are not deployed in ways that make problems compound. Our deploy machinery is boring on purpose. You should feel nothing when we ship.
A release's true cost is not the code we wrote to ship it — it is the cost of unwinding it if it goes wrong.
Every architectural decision in a LightLeapAI product is evaluated against the cost of reversing it. Cheap-to-reverse decisions ship freely. Expensive-to-reverse decisions (schema changes touching shared tables, new external runtime dependencies, cross-tenant features, autonomous-AI expansions) require an ADR in docs/adr/ that names the reviewers, the alternatives considered, and the exit strategy. We are not romantic about clever architecture. We are ruthless about keeping the reversal window cheap so Article I's promise stays real.
The test
For any architectural decision on the roadmap, we can name one concrete way to reverse it inside a single sprint. If we cannot, the decision waits for an ADR.
What this means for you
You are never paying — in downtime, data loss, or eroded trust — for our decision to move fast. Speed and reversibility are the same discipline; we do not trade one for the other.
Multi-Tenant by Construction
Tenant isolation is the frame, not a feature. Every entity, query, log, metric, event, cache key, vector search, and AI prompt is tenant-scoped by the framework — not by developer discipline.
Every table in a LightLeapAI product has a non-nullable tenant_id column with an index and a Postgres Row-Level Security policy that enforces tenant_id = current_setting('app.tenant_id'). Every request carries a verified tenantId derived from authenticated identity — never from a query string, header, or body. Every background job, webhook, AI agent, and cron task explicitly sets tenant context before doing work. Cross-tenant queries live in a separate admin namespace with elevated authentication and audit logging, and require an ADR to introduce. There are no “system-wide” jobs that touch tenant data without iterating tenants explicitly.
The test
For every data-access path in every product, we can point to a test that fails if a query leaks across tenants. No test, no ship.
What this means for you
Your data is never one bug away from another customer's. Tenant isolation is not a feature we enable for you at onboarding — it is the frame every LightLeapAI product is built on. A leak here is not a bug; it is a violation of Article VI.
Accessibility With a Test
Accessibility has a test in our pipeline that fails the build. It is not a checkbox in a spreadsheet, and it is not a promise on a marketing page.
Every LightLeapAI product is authored and tested to WCAG 2.2 Level AA. A reproducible axe-core harness runs against every route of the running application, at desktop and mobile viewports, in fresh unauthenticated and authenticated sessions, and fails the build on any WCAG 2.0, 2.1, or 2.2 A/AA violation. Formal Accessibility Conformance Reports (VPAT 2.5Rev / Revised Section 508) are on file today for Illuminate 3.8.4.5 (November 2025) and LightLeapAI Orion analytics-ui v0.1.0 (August 14, 2026 — 28 real routes × 2 viewports, zero A/AA violations). Additional product ACRs publish as each product completes formal conformance review; the harness applies to every product regardless of whether a formal ACR has been authored yet.
The test
For any LightLeapAI product, we can point to the axe-core harness in the repository, the routes it covers, and the last CI run that made it green. No harness, no ship.
What this means for you
Your users with disabilities are not an afterthought. Accessibility runs in our pipeline the same way tests do: if a route breaks WCAG 2.2 AA, the build fails and the release does not happen. Ask for the harness; we will show it to you.
Regulated-Data Respect
Regulated data is radioactive. It is tagged, contained, audited on every read, redacted from logs by construction, encrypted at rest, and never leaked to a third party without your written permission.
PII, education records (FERPA), financial data (GLBA), and authentication secrets are classified and tagged at the schema level. Log fields that may contain them pass through a redaction layer enforced by lint. High-sensitivity fields (SSN, DOB, government IDs) are field-level-encrypted at rest. No regulated data is sent to a third-party LLM without a signed BAA/DPA and explicit tenant consent, or without tokenization/field-level redaction before the call. Every export or download of regulated data emits an audit event carrying actor, tenant, resource, fields, and reason. Retention is configurable per tenant and defaults to the strictest applicable regulation. There are no “permanent” tables of PII in a LightLeapAI product.
The test
For every regulated-data field in every product, we can name the classification tag, the redaction rule, the encryption boundary, the retention policy, and the audit event emitted on read. If any of the five is missing, the field is a Article VIII violation.
What this means for you
The regulated data you trust us with is treated like radioactive material. You can see who read what, when, and why — because every read leaves an audit row. You can retract consent for third-party LLM processing at any time — because we never sent the raw data without your permission in the first place.
Reuse Over Reinvention
Enterprise infrastructure — authentication, tenancy, audit, email, LLM orchestration, chat persistence — is consumed from shared platform assets. It is never re-implemented per product.
The LightLeapAI platform ships one canonical implementation of each enterprise capability. Every product consumes it — via a published package, a service SDK, or a versioned API — not a copy. Product-local infrastructure is permitted only as a marked stopgap, behind a versioned seam, with a written convergence plan recorded in an ADR. We do not accept a “phase 2 platform” inside a product repo when the platform already exists elsewhere in the organization. When we improve authentication, or audit, or LLM safety in the shared asset, every product inherits the improvement in the next release — because they share the same spine, not a copy of it.
The test
For any enterprise capability (authn, tenancy, audit, email, LLM, chat), we can point to the one shared asset that owns it, and every product's consumption of that asset. Two implementations of the same capability is a Article IX violation.
What this means for you
Every LightLeapAI product you buy is the same platform underneath. Improvements to security, accessibility, observability, or AI safety land in every product at once — because they share the spine. You are not buying seven independent products that will drift apart; you are buying one platform that will grow together.
Observable or Not Shipped
If it is not observable, it is not shipped. Off-the-record work does not exist in a LightLeapAI product.
Every LightLeapAI service emits structured JSON logs with tenantId, userId (when present), traceId, spanId, service, environment, and event on every log line, through a shared logger with automatic PII redaction. Every inbound request, outbound HTTP call, database query, queue message, and LLM invocation is auto-instrumented with distributed tracing. Metrics follow RED for services and USE for resources. Regulated-data reads and writes, authentication events, permission changes, data exports, and AI tool invocations against tenant data are emitted to a separate audit stream — write-only, immutable, retained per tenant policy — carrying actor, action, resource, tenant, before, after, and reason. There are no console.log statements in shipping code. Ever.
The test
For any incident in production, we can produce — within one on-call turn — the log lines, the trace, the metrics, and (for regulated actions) the audit-stream events that show what happened. If we cannot, the observability was insufficient and the release was in violation of Article X.
What this means for you
When something goes wrong in a LightLeapAI product, we can tell you exactly what happened, when, to which record, initiated by whom. No mystery incidents. No “we're looking into it” for days. The evidence is captured before the incident, not reconstructed after it.
Contract-First Modules
Every module publishes a versioned, typed contract. The platform supports the current and previous major version simultaneously. Breaking changes ship on a six-month deprecation clock.
Every LightLeapAI module — HR, Student, ERP, and every customer-owned module — publishes an OpenAPI schema generated from code, not hand-written docs. Endpoints are versioned; additive changes ship freely; breaking changes get a new major version and a minimum six-month deprecation window announced in writing to every affected tenant. Every mutating endpoint accepts an Idempotency-Key header and dedupes for at least 24 hours. Customer-owned modules run through the platform SDK's sandbox, which enforces tenant context, authorization, rate limits, and audit logging by construction — customer code cannot escape those guarantees. Modules do not read another module's database directly; they use the API or subscribe to events.
The test
For every module contract in every product, we can point to the OpenAPI schema generated from the code, the version, the deprecation announcements sent to affected tenants, and the SDK sandbox that enforces authorization on customer-owned modules. Missing any of these is a Article XI violation.
What this means for you
The module you build on top of a LightLeapAI product today will still work in two years — because we version contracts, not implementations. When we change how something works underneath, your integration keeps working; when we retire an old version, you get six months of written notice, not a surprise on a Monday morning.
This doctrine is signed, dated, and re-ratified. Every article has an owner. Every violation is a personal responsibility — mine.
The Quantum Mandate is not a marketing statement. It is signed by the Founder and CEO, dated, and re-ratified on every major platform release. Every article names an internal owner responsible for keeping its enforcement machinery green. Every violation triggers a written post-mortem, a fix, and — when appropriate — a customer notification. The internal form of this doctrine (v1.7) is the operating constitution every human builder, every AI agent, every subagent, every contractor, and every customer-owned module at N2N/LightLeapAI is bound by. This public form (v2.0) is what our customers can expect from us on every release, every quarter, every year — regardless of how fast AI accelerates, how the market shifts, or how large we grow.
The test
For every article of this Mandate, we can name the internal owner, the enforcement machinery, the most recent green run of that machinery, and the date the article was last ratified. If any article cannot answer, it is not in force.
What this means for you
If a LightLeapAI product ever fails you on any of the twelve, that is a violation of my constitution — not a support ticket. Tell my security team directly at security@n2nservices.com, and it will reach me.