Standards

Every Incubics engagement runs under the same baseline standards. Clients add their own — bank model risk management, healthcare privacy rules, manufacturing safety cases — and we incorporate those in Perceive. What follows is what we hold ourselves to regardless of sector.

Data residency by region

Data and inference stay where you require them: India, UAE, Australia, EU, US, or on-premise behind your firewall. We do not route production workloads through regions you have not approved. Architecture diagrams in discovery show data flows explicitly. Cross-border transfer, if ever needed, is a documented decision with your legal and security teams — never a default.

Multi-region clients get separate environment definitions per region, not one global stack with a toggle. This adds engineering cost upfront and saves regulatory pain later.

Every agent action logged and attributable

If an agent reads a record, writes a field, or sends a message, that action is logged with timestamp, actor identity, tool invoked, inputs summary, and outcome. Logs are retained per your policy and searchable for audit. We design for attribution: which model version, which prompt version, which user session triggered the chain.

Debug logging in development is verbose; production logging respects PII minimisation — enough to reconstruct decisions, not enough to create a secondary data lake of sensitive content unless you want that for compliance.

No client data for shared model training

Your data is not used to train models shared with other clients. Fine-tuning uses your data in your environment or in isolated training runs with contractual guarantees from vendors where APIs are involved. We document what each vendor retains and for how long. If a vendor's terms are incompatible with your policy, we say so in discovery and propose alternatives.

Security in the build path

• Threat modelling for agent tool access and retrieval boundaries.
• Secrets management — no API keys in repositories.
• Dependency scanning and patch cadence for application and infrastructure code.
• Role-based access to environments, evaluation data and prompt libraries.
• Red-teaming for prompt injection, data exfiltration and tool misuse scenarios scoped in discovery.

Security review is parallel to engineering, with findings tracked to closure before production. Critical findings block cutover; there is no waiver process on our side.

Evaluation and model risk

Models are probabilistic. Standards require evaluation evidence before production and ongoing measurement after. For regulated clients, we align documentation to your model risk framework — use case definition, limitations, monitoring plan, change control — without inventing certifications you do not hold.

Human oversight stays where the process or regulation demands it. We do not automate approval steps that your policy reserves for people, unless you explicitly change policy.

Open ownership

Code, infrastructure definitions, prompts, evaluation sets and documentation belong to you. We use standard formats and mainstream tools so you are not dependent on proprietary platforms we operate. Run is a service; it is not a hostage arrangement.

How standards show up in the method

Perceive captures your additional requirements in the governance baseline. Engineer implements controls and tests them. Deliver verifies sign-off criteria. Run monitors that controls still hold after changes. Standards without operational follow-through are posters; we treat them as acceptance criteria.

Evidence, not assertions

Before production, we produce evidence packs aligned to what your security and risk teams ask for: architecture diagrams with data flows, list of subprocessors and regions, sample audit logs, evaluation summary with known limitations, test results for guardrails and access control. We describe what the system does and does not do in plain language. That honesty speeds approval because reviewers are not hunting for gaps we omitted.

Standards evolve as vendors and regulators evolve. When a standard changes — new residency requirement, new logging field — Run includes impact assessment on live systems. Material changes follow the same promotion discipline as model upgrades.

Third-party components — frontier APIs, open models, vector databases — are assessed for licence, data processing terms and exit path before inclusion in architecture. We prefer components your team can operate without us, aligned with open ownership.

Accessibility and fairness

Where use cases affect customers or employees at scale, we test for disparate impact patterns your policy cares about — not as a substitute for formal fair lending or employment review, but as engineering input to those processes. Limitations are documented when sample sizes or context prevent strong conclusions.