libLogit

libLogit v1 Beta Readiness Rubric

This rubric defines how libLogit readiness percentages should be interpreted. It exists to keep status updates honest and repeatable.

Why This Exists

The project already has enough code that vague phrases like “almost there” stop being useful. We need a way to say:

• what counts toward Beta
• what does not count yet
• how documentation and planning work moves the project forward
• why a language can be real but still not count as Beta-supported

Readiness Categories

Beta readiness is measured across twelve weighted categories:

Category	Weight	What counts
Documentation foundation	8%	README, docs home, getting-started path, install docs, architecture, limitations, examples routing, roadmap, and public planning.
LOGIT contract stabilization	12%	Portable field names, defaults, call semantics, lifecycle rules, unsupported-field rules, and compatibility notes.
Config/schema stabilization	10%	Versioned schema, migration rules, examples, overrides, and contract alignment.
Cross-language conformance	14%	Shared fixtures, runner contract, machine-readable reports, baseline parity, advanced parity/waivers, and drift visibility.
Package/install maturity	12%	Public package identity, install commands, artifact checks, consumer smoke tests, and release evidence.
Local output/rotation/retention	10%	Path rules, file append behavior, rotation semantics, database retention semantics, and close/flush semantics.
Remote output/transport strategy	6%	Remote-path baseline, transport scope decision, sink interface, test harness, and security rules.
Viewer/SQL workflow	8%	Frozen SQLite schema, viewer packaging, viewer filters, starter SQL docs, and UX polish.
OS/hardware validation	8%	Supported matrix definition and Windows/Linux/macOS plus hardware/resource validation.
Language expansion path	4%	Intake governance, new-binding template, and first expansion-track plans.
CI/release gates	5%	Local verifier, hosted parity, artifact manifest, and final release gating.
Beta exit evidence	3%	Readiness rubric usage, release notes, hosted evidence, RC evidence, and launch checklist.

Total: 100%

Scoring Rules

Each category is scored using the same three-state model already used in the burndown:

• Done = 1.0
• In progress = 0.5
• Not started = 0.0

The project readiness percentage is:

sum(category_weight * category_completion)

Task-level status in the burndown rolls up into category completion. A category should only be called done when its acceptance criteria are actually met, not when the repo contains a draft.

What Counts As Beta-Support Evidence

A binding can only count toward the supported Beta matrix when all of the following are true:

1. The install path is public and normal for that ecosystem.
2. Package identity and version are documented.
3. Direct blank-LOGIT setup is shown publicly.
4. Structure-fed or builder-style setup is shown publicly.
5. Config-loaded setup is shown publicly.
6. Shared conformance evidence exists.
7. Known limitations are public.
8. Release verification evidence exists.

If one of those is missing, the binding may still be valuable, but it should be scored as incubating rather than supported.

What Counts As Documentation Progress

Documentation work counts when it reduces uncertainty for a real developer or binding author. Examples:

• clarifying SDK/API/binding terminology
• publishing install routes
• publishing the LOGIT mental model
• publishing known limitations
• publishing roadmap and readiness rules
• linking examples so people can succeed without reading source trees by hand

Documentation does not count as completion for code-heavy categories like conformance, packaging, or platform validation unless it is accompanied by the required technical evidence.

Alpha Versus Beta Interpretation

Alpha readiness

Alpha readiness tracks whether the product works as a functional showcase:

• import or include the SDK
• create a LOGIT
• write to console and local output
• retain local history in SQLite
• inspect that history through SQL or a minimal viewer

Beta readiness

Beta readiness tracks whether the product is stable, documented, testable, and repeatable across languages and environments.

That means Beta can trail Alpha even when Alpha functionality is strong, because Beta asks a different question: can new users and new bindings depend on this without guesswork?

Current Interpretation Guidance

When reporting status at the end of a run:

1. Quote both Alpha and Beta percentages.
2. Name the specific categories that moved.
3. Avoid inflating Beta readiness from documentation alone.
4. Call out whether progress was in code, packages, tests, docs, or planning.

Exit Standard

libLogit should not be declared v1 Beta-ready until:

• all supported Beta categories are done or have documented accepted waivers
• supported bindings have public install plus conformance evidence
• hosted CI evidence exists for the release commit
• the README, docs, package pages, examples, and limitations all agree

The burndown remains the detailed execution source. This rubric defines how to measure it.