Documentation

The canonical answer: an AI Engineering Operating System that records the engineering act behind an AI system and reasons over it.

The category explained: the problems AI teams face, why observability is not enough, and what an operating system for AI engineering has to model.

Run the stack, register your first agent, dataset and prompt, evaluate them, and read the engineering record that results.

Forge Kernel, Registry, AI Git, Forge Graph and Engineering Applications — what each layer owns and why the order matters.

Artifacts, revisions, evaluations, runs, and the derived reasoning objects — Observation, Claim, Decision, Evidence and Knowledge.

How Broks Forge derives observations, claims, decisions, evidence and knowledge from real engineering work, without anyone writing them down.

Why a system that remembers why things are the way they are behaves differently from one that only remembers what happened.

Durable engineering facts that emerge from decisions and evidence — never authored, never fabricated, always traceable.

Traces answer what happened. Engineering questions are about why, what changed, what it means and what to do — a different data model.

Why the reasoning layer is a deterministic engine over real records rather than a language model, and what that guarantees.

One catalog of every engineering artifact and every piece of knowledge derived from it — discovery in one place, not per module.

Version control for engineering reasoning: revisions, promotions, rollbacks and the rationale behind each change.

Your AI organization as a connected system — artifacts, their real relationships, and reasoning layered on top of them.

The runtime path of a single evaluation run, reconstructed from its own telemetry — and the same graph narrowed to where the chain broke.

Lineage and blast radius: what an artifact depends on, what depends on it, and what a change here would affect.

Ask engineering questions in plain English and get answers read from your own record, each one declaring how it is known.

The Engineering Investigation Workspace: a chronology, a cause at four depths, and every chain of evidence behind a failure.

Reproducible measurement: pinned configurations, real runs, the metric catalog and the failure classifier behind them.

Problem → Execution → Evidence → Knowledge → Decision → Revision → Promotion → Deployment → Learning, end to end.

Four worked scenarios: a failing deployment, a prompt regression, an unexplained cost rise, and a promotion nobody can defend.

How to get a trustworthy engineering record: what to version, what to evaluate, and what to record a reason for.

Where Broks Forge sits relative to tracing, evaluation, gateway and experiment-tracking tools — and where it overlaps.

Tracing and evaluation for LLM apps, compared with an engineering record and reasoning layer.

The LangChain-native observability and evaluation suite, compared with a framework-agnostic engineering OS.

A developer-first prompt testing CLI, compared with a persistent, multi-user engineering record.

An LLM gateway and observability proxy, compared with a platform that reasons about engineering decisions.

Experiment tracking built for model training, compared with engineering intelligence for AI systems in production.

The system in one page: Spring Boot modules, the Next.js app, the derivation pipeline and where each layer lives.

What is stored versus what is derived — the persisted tables, the composite ids, and the reasoning objects computed on read.

Conventions, authentication, tenancy, pagination and errors — plus the endpoints for every capability.

How the backend and frontend are organised, and the rules a new module has to follow.

Adding a provider, a metric, a Brok intent, a brief or an investigation cause — the seams designed to be extended.

Prerequisites, running the stack, the test suites, and the build commands that gate a change.

The rules the codebase is held to: one product, evolve don't duplicate, derive don't store, never fabricate.

Straight answers about scope, cost, self-hosting, model support, data handling and maturity.

Every term Broks Forge uses, defined once and used consistently across the product and the docs.

The full internal architecture reference.

How the team works: standards, review and delivery.

Day-to-day development reference.

Non-negotiable rules for changes to this codebase.

Language-level conventions for Java and TypeScript.

REST conventions every endpoint follows.

Authentication, authorization, tenancy and credential handling.

How failures are represented and surfaced.

What is tested, at which level, and why.

Performance budgets and the practices that hold them.

Running Broks Forge in a real environment.

How to propose and land a change.

What exists today and what is planned.