Written down before the first call.

01

Data residency & sovereignty

Residency is an architectural decision, so we make it first. Regulated data stays inside the boundary you define — national cloud, sovereign cloud regions, or your own infrastructure — and that boundary constrains everything downstream: where inference runs, where retrieval indexes live, where logs are written, and what may transit a third-party model API. Deployments are designed so that changing a model vendor never means renegotiating where your data lives.

• Residency boundary agreed in writing before architecture work begins
• Inference, retrieval, logging, and fine-tuning mapped against that boundary
• Third-party API egress explicitly documented and approved, or designed out

02

PDPL-aligned delivery

We treat the Personal Data Protection Law as a set of build requirements, not a compliance review at the end. Purpose limitation is encoded in pipelines; consent boundaries decide what may become training or evaluation data; and data-subject rights — access, correction, deletion — are answerable because lineage is tracked from ingestion onward.

• Data classification before system design, not after
• Consent and purpose boundaries enforced in code, not policy documents
• Subject-rights requests answerable from lineage, in minutes not weeks

03

Security engineering

The security posture of every build follows the same defaults: least-privilege access for humans and agents alike, secrets in managed vaults rather than configuration files, encrypted transport and storage, and segregated environments from development through production. Agentic systems get additional treatment — permission tiers per action, human checkpoints where risk warrants, and red-team exercises before go-live.

• Least-privilege by default; production access logged and reviewed
• Red-teaming and abuse testing before any user-facing release
• Incident runbooks written and rehearsed with your team before launch

04

IP & ownership

Everything an engagement produces belongs to you: source code, model weights and adapters, evaluation suites, prompts, documentation, and runbooks — delivered into your repositories under your accounts as we work, not in a handover ceremony at the end. We retain no license to your deliverables and keep no capability back to rent to you later. Where we reuse our own pre-existing tooling, it’s identified up front and licensed to you perpetually.

• Work product in your repositories, under your IP, from the first commit
• No proprietary runtime you’re forced to keep paying for
• Pre-existing Kindi tooling identified and perpetually licensed

05

Model & data governance

Client data is never used to train anything that serves anyone else — no cross-client models, no shared indexes, no exceptions. Every model in production has an owner, an approval record, an evaluation history, and a rollback path. When we benchmark vendors on your workloads, the results and the decision rationale are yours to keep and to show a regulator.

• No cross-client training or shared artifacts, contractually
• Model inventory: owner, version, eval history, rollback path per model
• Vendor benchmark results documented and handed over

06

Confidentiality & engagement conduct

We work under NDA as a default, not a negotiation. We don’t disclose client names, and we don’t use your engagement in our marketing — our public materials describe methods and blueprints, never your systems. Team members are named before they start, background-checked where your sector requires it, and bound individually to the same confidentiality terms.

• NDA-default engagements; no client names in our marketing
• Named team, individually bound, checked to your sector’s standard
• Clean-room handling for competitively sensitive material