# ADR-0001 — Go as the implementation language

**Status:** accepted · **Date:** 2026-09-04

## Context

fluid-core had no implementation. Three stacks were credible: Go, TypeScript
and Python. The specification (`ArchitectureBlueprint.md` §42–43) points at a
long-running gateway, a router, an append-only store and, later, a Kubernetes
controller with custom resources.

Python is the obvious first reach — pydantic maps almost literally onto the
record schemas, and it matches existing tooling in sibling repositories.
TypeScript is attractive because the first consumers are platform SDKs with
strong TypeScript clients.

## Decision

fluid-core is written in Go.

## Rationale

The always-on component is infrastructure: proxy, router, registry, evidence
store. That is Go's centre of mass. A single static binary is also the most
credible form of "drop this in front of any API" — the promise ADR-0002 makes.

Blueprint §43 maps 1:1 onto controller-runtime, so the Kubernetes path stays
open at no extra cost.

Go is the lowest-entropy of the three to debug, which matters under a per-task
budget policy.

## What we gave up

Record modeling is more verbose in Go than in Python. This is paid once, behind
generated types (ADR-0003), rather than continuously.

The generative Daimon (Blueprint Phase D) would be easier in Python. ADR-0002
makes that a non-issue: the Daimon is a separate process speaking the wire
contract, so it may be written in whatever suits it.

## Consequences

- No third-party Go modules are used where the standard library suffices; the
  build stays offline-capable.
- Python remains a build-time dependency for schema validation only.