Operating Philosophy

OPERATING PRINCIPLES

/// GUIDING_BELIEFS The beliefs and practices that guide every technical decision, partnership criteria, and product development choice we make.

EXPLORE PRINCIPLES BRIEFING ANFORDERN
Structure Permanence Verification

Foundation

Five Operating Principles

These principles drive our technical decisions, partnership criteria, and product development.

PRINCIPLE_01

Structure over novelty

Clarity beats cleverness. We choose obvious, maintainable solutions over complex innovations. Every system should be understandable to the people who depend on it.

IN_PRACTICE

  • Explicit configuration over convention
  • Clear API contracts
  • Readable code and documentation

WE_AVOID

  • Magic or hidden behaviour
  • Unnecessary abstractions
  • Cutting‑edge tech without clear benefits

PRINCIPLE_02

Permanence over velocity

We build for decades, not quarters. Every system includes versioning, migrations, and export by default. Speed comes from not having to rebuild.

IN_PRACTICE

  • Schema versioning from day one
  • Export functionality built‑in
  • Backward compatibility policies

WE_AVOID

  • Breaking changes without migration paths
  • Lock‑in without export options
  • Technical debt for short‑term gains

PRINCIPLE_03

Verification over claims

Everything important should be measurable, testable, and auditable. We produce artifacts, tests, and evidence objects rather than promises.

IN_PRACTICE

  • Public benchmarks and model cards
  • Evidence objects for key decisions
  • Reproducible builds with checksums

WE_AVOID

  • Marketing claims without backing data
  • Black box systems
  • Unverifiable performance promises

PRINCIPLE_04

Duty of care over convenience

Especially in health, safety, and compliance contexts, we prioritise the welfare of end users over ease of implementation or time to market.

IN_PRACTICE

  • Safety guardrails that cannot be bypassed
  • Privacy by design in all systems
  • Fail‑safe rather than fail‑fast

WE_AVOID

  • Shortcuts that compromise safety
  • Data collection without clear benefit
  • Features that could cause harm

PRINCIPLE_05

Integration over isolation

Real institutions don't replace everything at once. We design for integration with existing identity systems, records, and regulatory frameworks.

IN_PRACTICE

  • Standard protocol support (OIDC, SAML)
  • Import/export in common formats
  • Adapter patterns for legacy systems

WE_AVOID

  • Proprietary protocols without alternatives
  • All‑or‑nothing deployment requirements
  • Systems that ignore existing workflows

Core Beliefs

Signature Phrases

These phrases capture our philosophy. We use them sparingly but they represent our core beliefs.

"We don't disrupt. We impose structure."

Our role is to bring order and reliability to sectors that need it, not to break what works.

"We're building what should already exist — and building it to last."

Many sectors lack basic institutional infrastructure. We fill those gaps with permanent solutions.

"Software should feel inevitable — not improvised."

Good institutional software integrates so seamlessly that it feels like it was always there.

"Designed for institutions that think in decades, not quarters."

Our timeline matches the longevity requirements of the institutions we serve.

Implementation

Security & Governance

How we implement our principles in operational practice.

SECURITY_POSTURE

Security posture

  • Responsible disclosure with coordinated vulnerability disclosure process
  • Least‑privilege access with audited changes and tamper‑evident logs
  • Encryption in transit and at rest with key rotation policy

DATA_GOVERNANCE

Data governance

  • Retention matrices per product/API with clear export procedures
  • Schema‑embedded version tags for all stored data
  • Residency pinning where required; DPIAs for sensitive deployments

ASSURANCE_FRAMEWORK

Assurance framework

  • Evidence objects: hash‑addressed, immutable event records
  • Verification Notes (quarterly): what we tested, what broke, what we fixed
  • Assurance Pack: control catalog, test coverage, evidence samples

CHANGE_MANAGEMENT

Change management

  • Semantic versioning with clear breaking change policies
  • Deprecation calendars with minimum 90‑day notice
  • Signed releases with checksums and migration notes

Transparency

Publication Cadence

QUARTERLY

Quarterly

  • Verification Notes
  • Roadmap updates
  • Security reviews

MONTHLY

Monthly

  • Change logs
  • Deprecation notices
  • API updates

AS_NEEDED

As needed

  • Security advisories
  • Model releases
  • RFC publications

Partnership

Align with our principles?

We work with partners who share our commitment to structure, permanence, and institutional value.

BRIEFING ANFORDERN