Security & architecture
Architecture designed for approval
This page describes how the environment is designed to keep code and AI processing inside an approved boundary — and is honest about what runs today versus what is still designed. The governance, audit, and context layers are designed, not yet built.
Model-agnostic routing
The environment runs as an IDE that routes across hosted and self-hosted open models. A team chooses where models run and is not tied to a single provider. This is the part that works today — the founders use it on real codebases.
Control boundary
A control boundary, by design
Our approach is to keep source code and AI processing inside an approved, customer-controlled or Swiss-hosted environment. The boundary is designed to define what may cross it and what stays inside — today it is a design, not a running control.
Approved, customer-controlled or Swiss-hosted environment
- Developer & IDE
- Model-agnostic routing — hosted & self-hosted open models
- Governance & policy-enforcement layer
- Audit & traceability layer
- Enterprise context layer
- Works today
- Designed, not built
- Not yet enforced — design intent
Designed, in development
The layers that make it approvable
- Designed · in development
Governance & policy-enforcement
Designed to express an organisation's policy as rules the environment applies to AI-assisted changes — which models may be used, on which repositories, and what needs human sign-off.
- Designed · in development
Audit & traceability
Built for a tamper-evident record of AI-assisted work — the prompt, the model, the suggestion, and the human decision — intended to make a change defensible under review.
- Designed · in development
Enterprise context
Designed to bring an organisation's own codebases, standards, and systems into the environment as context, intended to stay inside the boundary rather than be sent to an outside service.
Jurisdiction
Built with FINMA and the revised FADP in mind
The design targets the realities of regulated Swiss software teams: keeping processing in an approved jurisdiction, and being able to show who did what. We do not claim any certification or formal compliance — the aim is a model a team can take to its own risk and approval functions.
This website
How this site itself is built
A small thing, but telling: the site practises the restraint it describes.
Strict content security policy
Scripts and styles run only with a per-request nonce — no inline-script injection, no third-party origins.
Hardened response headers
HSTS, content-type nosniff, a strict referrer policy, and a locked-down permissions policy on every response.
No analytics, minimal data
No third-party analytics or trackers. The enquiry form collects only name, work email, organisation, and your message — and stores nothing.
Accessible by default
Semantic structure, full keyboard navigation, visible focus, and WCAG 2.2 AA contrast.
Honest limitations
What is not built yet
Works today
Model-agnostic routing across hosted and self-hosted open models, used by the founders on real codebases.
Designed, not built
The governance, audit, and context layers — and the control boundary itself — are designed end-to-end but not yet implemented.
Not operational
Nothing here describes a running, verified control. Treat the architecture as design intent for first pilots in H2 2026, not as something to rely on today.