ARCHITECTURE

One core.
Three ways into it.

Core owns the scoring model. App provides the local tools. Gateway exposes the model over HTTP. The portal presents those existing capabilities and sends browser requests to the Gateway.

Core / DevKit

statline.core

Public Python API, adapter loading and mapping, scoring, datasets, and StatPacks.

App / Local

statline.app

CLI and StatLine OS. The OS executes the canonical command tree in-process.

Gateway / API

statline.gateway

HTTP operations, OpenAPI, API-key access, device proofs, scopes, and approvals.

Python applicationCLI / StatLine OSHTTP client

Same StatLine scoring engineAdapter → mapped metrics → profiles → results

Separation you can inspect.

Core has an enforced no-App/no-Gateway import boundary. Optional extras add the layers you need, and the canonical repository generates standalone component mirrors.

The website is a static portal. It runs no scoring service, stores no accounts, and doesn't issue keys. Existing Gateway policies govern every live operation.

CAPABILITY EXTRAS

statline
statline[app]
statline[gateway]
statline[all]

Same output, checked

Generation compares Python scoring, Gateway scoring, rendered StatPacks, and the existing CSV runner.

Facts from the source

The catalog, public signatures, source version, required Python range, and OpenAPI are generated from this checkout.

Rules that travel

StatPack samples package the adapter sections, metadata, dataset, and runner instead of duplicating the scorer.

Inspect the repository architecture

One core.Three ways into it.