Capability Acceptance Matrix
Documentation completeness is not implementation evidence. A capability is offered to users and AI only after every required lane passes.
Universal promotion lanes
| Lane | Required evidence |
|---|---|
| Contract | Request, progress, result, errors, permissions, resources, units, defaults |
| Java mechanism | Stable protected implementation and client-thread boundary |
| Lua binding | Registry-generated or registry-verified binding |
| Lifecycle | Success, failure, timeout, cancellation, stop, reload, world unload |
| Security | Allowlist, budgets, redaction, capability denial, adversarial inputs |
| Portability | Core fixture without server semantics |
| Pack | Server-specific fixture with version/provenance checks |
| Production | Representative script or workflow parity |
| AI | Generation, selection, boundedness, and repair evaluation |
| Live | Named distributed build, Minecraft task, telemetry, rollback |
Domain matrix
| Domain | First representative task | Principal resources | Highest-risk failure |
|---|---|---|---|
| Runtime | Cancel a synthetic action in every state | scope | leaked work or callback concurrency |
| Navigation | Reach a point through changing terrain | movement, camera | stuck input or invalid pack edge |
| Mining | Harvest Galatea-equivalent resources | movement, camera, interaction, hotbar | mechanism duplicated in Lua |
| Inventory/GUI | Execute a semantic sell transaction | inventory, screen | wrong click after revision change |
| Combat | Engage then safely disengage | combat, camera, interaction, movement | attacking an invalid target |
| Camera | Track a moving subject with override | camera | fighting user input |
| World | Query and revalidate a target | none | stale mutable game state |
| Events | Survive a burst with bounded queues | subscription | client-thread stall or memory growth |
| HUD/config | Render and migrate script state | HUD scope | per-frame Lua or stale persistence |
| Side effects | Report progress to an approved origin | network/storage budget | data leak or post-stop send |
| Raw | Perform a scoped custom interaction | declared raw resources | bypassing safety or cleanup |
Evidence record
An implemented page must identify:
- source commit and capability-registry revision;
- focused test names and results;
- script fixture and expected telemetry;
- pack fixture when applicable;
- AI evaluation set and score thresholds;
- distributed artifact identity;
- live test date, environment, and operator;
- known limitations and rollback method.
The page frontmatter then changes to:
hexis_status: implemented
executable: true
ai_context: api
implementation_ref:
commit: "<full commit>"
registry: "navigation.go@1"
tests: "NavigationContractTest"
live_evidence: "<evidence record>"
The validator rejects implemented without this record.
AI evaluation gates
At minimum, prompts must test:
- correct capability selection from a user goal;
- correct units, required fields, and manifest permissions;
- high-level action preference over raw;
- terminal failure handling;
- timeout and cleanup behavior;
- pack-neutral and pack-specific variants;
- repair from structured diagnostics;
- refusal to invent unimplemented or deprecated calls.
Track first-pass validity, invented-call rate, raw-overuse rate, repair turns, permission accuracy, Lua size, and live task success. A repeated model mistake is a contract or documentation defect until evidence shows otherwise.
Current state
The v4 cross-cutting contracts are documented. No v4 capability is yet marked
Implemented, so /llms-api.txt intentionally offers no runnable target API.
Navigation is first in the implementation queue.