The Score Format

ISoftware shaped by its recipient

A language learner wants a practice app built around the vocabulary in their course. They find a published specification for a set of drills, supply their word list, and answer a few questions about how they prefer to study. An AI agent builds a personal application and helps them check that it works.

The published artifact in this proposal is a score: a specification that describes an application's purpose, the ways a recipient can customize it, and the conditions its generated versions must satisfy. The resulting application is a rendition. The name comes from music, where a piece remains recognizable across performances that differ in interpretation.

This changes what an author distributes. The author publishes the intent and the boundaries of acceptable variation. Each recipient supplies their preferences and material; a fabricator turns those inputs into a working application. The score remains the basis for future builds and updates.

The proposal builds on specification-driven development and existing ways to share and adapt software. Lovable's app-generating links distribute prompts, and Replit's remixing supports personal copies with source attribution. Scores would make the customization and verification contract an explicit part of the distributed artifact, designed for recipients who may have no software expertise.

IIA score in practice

Consider a score for vocabulary drills. It accepts the learner's own material, such as an Anki export or a pasted word list, and converts it into entries shared by the drills. Before building, the fabricator shows a sample of the imported terms and meanings for the learner to confirm.

Customization can also change behavior. The following example illustrates how a single choice connects the learner's preference to a verifiable result.

The learner answers a question about studying. The score carries the technical consequences and identifies the checks that change with that answer. This mapping is the core of its public interface.

IIIWhat a score contains

A score combines readable intent with structured declarations and executable checks. Six elements define the proposed format.

Intent and invariants

The intent describes what the application is for. Invariants identify the properties every supported rendition must preserve. A vocabulary drill might require that feedback uses the learner's supplied material and that each answer is judged under the selected policy.

Changing an invariant creates a fork with a different contract. Preserving the invariants establishes continuity of purpose, but support also depends on whether a change falls within the score's declared customization points.

Customization points

Every customization question should be answerable from lived experience. Questions about study habits, collaborators, or source material give the fabricator information it can translate into implementation choices.

Parameters

Choices from a defined set, with specified behavior for each supported option.

Slots

Places for the recipient's material or extensions. The score defines the required shape and how the input will be checked.

Amendments

Freeform changes to the specification. Their effects must be assessed before the resulting application can be considered verified.

Each supported customization declares which acceptance criteria change and which must remain in force. Where the effects of an amendment are uncertain, the rendition remains unverified until the affected criteria have been resolved.

Acceptance criteria

The criteria define acceptable behavior across renditions. Machine checks provide repeatable evidence; brief human walkthroughs make that behavior understandable and observable to the recipient. The two should be paired wherever practical, while properties such as access restrictions require enforcement and technical verification.

The builder must not weaken the criteria simply to make a rendition pass. Changes to the contract should be explicit and versioned. Walkthroughs also provide a starting point for documentation and reproducible bug reports.

Data contract

The score declares what information the application stores, its structure, and how it can be exported or migrated. Data has a lifecycle independent of generated code. Even a small list of words marked “known” needs a defined way to survive an update.

Capability declaration

A machine-readable declaration describes the access required during the build and by the finished application: network destinations, storage, files, and credentials. These are separate boundaries, enforced by the environments in which each stage runs.

Dependencies

Supporting skills, assets, and tools are bundled or identified with versions so a build's inputs can be recorded. Combining natural-language instructions introduces an additional problem: two dependencies may be individually coherent yet make conflicting demands. A general way to detect and resolve those conflicts remains an open question.

IVContinuity and updates

A score needs a record of its use by a particular recipient. This is the take: the selected options, supplied material, amendments, build state, and verification evidence. It allows work to resume across sessions and preserves the decisions needed for a later build.

The take records the score and data versions, the build environment, and the rendition to which each check or walkthrough confirmation applies. A confirmation establishes that a particular rendition passed; new generated code needs fresh evidence. The take can identify which walkthroughs must be repeated, but previous confirmations cannot certify changed behavior.

For the recipient, regeneration can be presented as an update. The fabricator explains what changes, preserves their choices, verifies the new rendition, and provides a way to return to the previous working version. Persistent data needs its own migration and recovery path.

The practical promise is continuity: an application can evolve while retaining the recipient's material and decisions. That promise must be demonstrated before regeneration becomes a routine part of the experience.

VTrust and enforcement

A score is readable, but readability alone provides no assurance that following it is safe. Its instructions can influence an agent with access to files, tools, and services. Each build can also produce different code, so reviewing the score does not establish the safety of every rendition.

The capability declaration must become an enforced boundary. Before following the score or running its bundled tools and tests, the host must restrict the build to the permitted access. Those restrictions must remain outside the score's control. A declaration of “no network” has no protective effect if the build agent can still make unrestricted requests.

The finished application needs its own controls. A browser provides useful isolation, and Content Security Policy can restrict resource loading, but the exact guarantees depend on delivery and configuration. For example, CSP's sandbox directive cannot be applied through an HTML meta tag, and separate paths on one origin do not isolate local storage. A supported delivery profile must specify and verify these details. See the CSP specification and the HTML storage security model.

Enforcement limits what a build or application can do; acceptance criteria evaluate whether it does the intended job. Author reputation, review history, and a visible chain of changes help recipients choose which scores to use. These provide complementary evidence, and popularity alone cannot establish safety.

VIDelivering a score

The fabricator is the system that guides customization, prepares inputs, builds a rendition, and coordinates verification within the required access boundaries. Its first implementation is planned as a skill package inside an existing agent platform.

The initial target is a small application made of static HTML and JavaScript, requiring no backend or application credentials. A compatible platform could provide the conversation, build tools, and sandbox, while the package supplies the score, import instructions, checks, and take. This keeps the first experiment small.

The delivery path still needs to be demonstrated from the recipient's perspective: obtain the package, supply material, answer questions, open the result, and complete the walkthroughs. The prototype must name the platform and browser it supports and distinguish capabilities it merely declares from restrictions it actually enforces.

Applications with shared state, external services, or credentials place additional demands on the host. A dedicated environment becomes necessary when an existing platform cannot provide the required controls or a usable delivery path. The format should describe those requirements without assuming every score needs the same infrastructure.

VIITesting the idea

The planned first score is a grammar gym: a small suite of browser-based vocabulary and phrase drills. The drills would share a dataset supplied by the learner. Its limited state and simple delivery make it a manageable place to test both the format and the recipient's experience. No score prototype has yet been implemented.

Can the specification stand on its own?

Build repeatedly in a clean environment where the previous source tree and conversation are unavailable. Supply the score, take, learner data, and declared dependencies, then evaluate each rendition against a fixed acceptance suite. Record the model, tools, customization, time, cost, and repair attempts alongside the results.

This measures reliability under stated conditions. Failures should be investigated to distinguish missing requirements from agent limitations or faulty checks. A pass rate from one setup is evidence about that setup; broader claims require testing across inputs and environments.

Can someone else use it successfully?

Give the package to non-engineers who have not participated in its design. Observe whether they can create a useful customization and judge its behavior without the author's help. Record where they become stuck, what technical questions arise, and whether the walkthroughs help them recognize an unacceptable result.

The experiment should also compare the score with a fixed drill app that imports the same material. If content import accounts for all the value, regeneration may add unnecessary work. A meaningful behavioral customization would help test when distributing a specification offers an advantage.

A later candidate is Input Garden, a learning application with substantial persistent learner state. It would test the harder promise: whether updates can preserve accumulated progress and personal changes over time.

VIIIOpen questions

The proposal leaves several questions for implementation and use:

• How much customization can an author support while keeping the contract understandable and the verification practical?
• How should amendments carry forward when the original score changes?
• Can scores and their dependencies compose without conflicting instructions or acceptance criteria?
• Which capability guarantees can different hosts enforce consistently?
• What evidence should a listing show a recipient who will never read the full score?
• When do the benefits of a personal rendition justify its build, verification, and maintenance costs?

The first prototype is intended to establish whether a published customization contract can reliably connect an author's intent to a recipient's working application. Its results will determine which parts of the format deserve to become stable conventions.