Bring a domain. Build a capability.

Start with a useful outcome

What should someone be able to do? What information makes the answer valid? Who owns each consequential decision? What must happen if a source is missing or changes?

These questions come before an adapter or a model prompt. A good first domain slice has a finite result: a checked calculation, a bounded proposal, a useful continuation after a changed input. It gives implementation and review something concrete to agree about.

The development path is Intent → task brief → implementation plan → candidate → examination/review → owner acceptance. Each step leaves an artifact for the next one. A finding can return the candidate for correction without discarding unaffected work.

HOW and WHAT

HOW defines the common engineering route: the supported interfaces, evidence relationships, authority boundaries and way to return a reviewable candidate. WHAT defines the domain task: inputs, owners, meaning, hard constraints, selection rules, outputs and acceptance obligations.

The general Authoring Kit is a concrete historical example. Its HOW is separate from the Football WHAT. A new domain needs its own explicit task and source basis; changing a schema label cannot make an old donor a universal dispatcher.

The kit is frozen provenance. The public handoff identifies two later source differences and explains why its historical execution closure should not be silently overlaid with a newer main. Ordinary reviewed development can use an explicitly selected current basis. A new measured cold-author trial needs a separately declared input and exposure boundary.

What is shared and what you supply

The kernel organises supported Work composition, result consumption, current local decisions and effect boundaries. Source and memory mechanisms qualify material by its origin, scope, policy and time. Those common relationships should be reused rather than copied into an alternative domain authority system.

The integrator supplies the domain’s owners, closed schemas, original sources, meaning checks, time and scope rules, adapters and useful acceptance cases. Domain knowledge answers questions such as whether an offer satisfies the original request or whether a measurement’s unit and observation time fit the intended use.

The end user should be able to express their task through an appropriate interface. They are not expected to hand-author BSEP packets. Building that interface and its validated mappings is part of integration.

Reusable capability development, local configuration and current execution have different costs. A shared capability can reduce repeated engineering; local data, policy, compatibility and maintenance still need attention.

Existing interfaces to inspect

The names below are source routes, not a runnable quickstart. Read the exact applicable signatures and their contracts before implementation. The Public Work Assistant Handoff explains these interfaces in Sections 4.1–4.5.

Pure computation does not need a fabricated external exchange or a mock effect. When a domain does exchange evidence, distinguish its producer result E, the later published evidence B, and the checked current consumption context C. A consumer must use the actual applicable context; copying a candidate’s declared inputs into an expected answer is not independent verification.

Football authorship

An outside AI built the domain. It did not approve itself. The full authorship account separates the author, runtime semantic models, examiner and admission. The accepted G54D1 line passed 16/16 native cases. Football runtime follows the useful offer and separately permitted booking.

Football is a recorded example of external domain authorship from a general HOW and a separate WHAT. It is also a development history with real corrections.

G54B1 produced a working application, but its examination stopped on the relationship between producer output, published wrapper and consumption context. The general E → B → C contract was clarified. That earlier attempt remains INCOMPLETE.

The later G54D cold-author trial used an initial submission and three corrections. Its remaining defect was specific: an authenticated revoked source stopped consumption and new booking, but the profile’s required separate local Root refusal had not occurred. G54D remains INCOMPLETE.

G54D1 continued that same lineage with an explicitly authorised fourth correction, the fifth submission. It repaired the missing decision and received acceptance in the declared finite scope, followed by separate source admission. This is useful evidence of an authoring route and its review process. It is not a one-shot success or a new unseen cold trial.

The Football publication chapter explains the application; the handoff preserves the fuller authorship lineage and its source routes.

Three decisions remain separate

1. Source review examines the new implementation and its imports, dependencies and I/O.
2. Capability admission concerns the specific local executors and validators.
3. Runtime permission concerns a particular current action under the local Root and Host.

Passing candidate-owned tests does not supply all three. Neither does another owner’s signature. A model can help create code or participate semantically in an application, but neither role grants it the owners’ decisions.

Integrated autonomous capability synthesis, broader federation and industrial deployment remain further work. A domain project can still make practical progress now by choosing a finite result and the interfaces that genuinely support it.

Make the next step reviewable

Use the Workshop to write a concrete task brief and arrange implementation, review and correction. Give an assistant the public handoff together with that task and the actual source basis. It is engineering context, not an instruction to run historical commands or reopen completed campaigns.

Choose the kind of growth

The task shapes the work distinguishes composing supported Work, obtaining an already existing pure capability, and authoring new source code. These need different evidence and acceptance. One kernel connects their shared relationships to runtime cases.

Sources and scope

This page is a website explanation, updated 2026-10-02. Its explanation does not create a new execution result or change the status of its sources.