A football match nobody scripts, with a record anyone can check.

New finding: the footballworld engine line

The MESSI engine line that was proposed for execution was read at a pinned commit. It fits the project better than the line analysed in G0: the player has body orientation and gaze as states of its own, a composite collision shape, and actions are intents (move, control, pass, shoot, clear, challenge) with continuous parameters Verified from sources. That matches the agent interface this blueprint proposes.

It still has serious gaps: fouls, cards and the winner of each duel are drawn by chance; in the foul file read, advantage is never applied and handball is never emitted; there is no jump; and its authors state that realism is not established Verified from sources.

What starting would require, if authorised

• The lead engineer (role), supported by AI engineering tools.
• An isolated Linux machine that holds no credentials from any other project.
• The decisions listed in Open decisions, in particular a separate GO for step 1a (build the machine and prove isolation, with no third-party code).

Review status

This assessment was reviewed by engineering direction and cross-checked by two AI research assistants. No independent human review has taken place yet; one can be added before any commitment to third parties.

• 22 autonomous virtual players; individual decision-making.
• Cooperation within the team; tactics, positions and strategies.
• Attack, defend, pass, shoot, score, intercept.
• Rules, a referee and ball physics.
• No manual control during the match.
• Result not predetermined.
• Events recorded and verifiable.
• Later visualisation with professional graphics.

Final aspiration: 90 minutes at a quality comparable to a professional broadcast. Not required in the first version.

Binding design rules: the three systems stay separated by project-owned data contracts; body architectures A, D-lite and D/E stay open until evidence selects one; third-party code is always referenced by full commit SHA and line of development.

Supporting components

• Integrity: manifest, prior commitment, seed derivation, sealing (decision log v2, §3).
• Evaluation: independent record validator and plausibility metrics.
• Our own 2D viewer: reads Contract 2 only. Works with any engine.

Illustrative example, not output from any run. Field names are proposals of this project, not taken from any engine.

{
  "illustrative": "not output from any run",
  "decision_tick": 14720,
  "player_id": "home-07",
  "frame": "egocentric, normalised to attack direction",
  "self":     { "pos_m": [-6.0, 7.5], "vel_mps": [0.4, -0.2],
                "body_forward": [0.94, -0.34], "gaze_yaw_rad": 0.30,
                "stamina": 0.81, "has_ball": true },
  "teammates": [ { "id": "home-09", "pos_m": [8.4, 2.6],
                   "vel_mps": [1.8, -0.1], "body_forward": [0.99, -0.12] } ],
  "opponents": [ { "id": "away-04", "pos_m": [-1.8, 5.4],
                   "vel_mps": [-2.6, 0.9], "body_forward": [-0.95, 0.31] } ],
  "ball":   { "pos_m": [-5.6, 7.3, 0.11], "vel_mps": [0.3, -0.2, 0.0],
              "spin_radps": [0, 0, 0] },
  "phase": "open_play", "score": [0, 0],
  "match_clock_ms": 184000, "period": 1,
  "team_instructions": { "block_height": "mid", "press": "high" },
  "memory_hash": "a91c…7e02"
}

{
  "illustrative": "not output from any run",
  "decision_tick": 14720,
  "player_id": "home-07",
  "intent": "PASS",
  "continuous": {
    "move":            [0.20, -0.05],
    "force_to_ball":   0.58,
    "ball_direction":  [0.94, -0.34],
    "elevation_rad":   0.00,
    "spin":            0.00,
    "gaze_yaw_rad":    0.30
  }
}

// events.jsonl  (illustrative, not output from any run)
{ "event_id": 4120, "type": "ball_contact", "tick": 14723,
  "t_contact_us": 184037500, "match_clock_ms": 184000, "period": 1,
  "player_id": "home-07", "contact_kind": "pass_foot",
  "caused_by_decision": { "player_id": "home-07", "decision_tick": 14720 },
  "authoritative": true }

// ball_segments.jsonl
{ "segment_id": 212, "start_tick": 14723,
  "p0_m": [-5.60, 7.30, 0.11], "v0_mps": [14.2, -5.1, 0.0],
  "spin_radps": [0, 0, 0], "model": "rolling+drag", "end": "contact:4121" }

// referee.jsonl
{ "ref_id": 902, "tick": 14807, "rule": "offside: position at the pass",
  "values": { "receiver_x_m": 8.6, "second_last_defender_x_m": 9.1 },
  "decision": "no_offence" }

Coordinates and time (Contract 2)

• Origin at the centre spot; +x towards the goal defended by the away team in the first half (the frame does not flip at half-time); +y to the left looking towards +x; +z up. Right-handed.
• Units: SI (m, m/s, rad, s). Pitch size declared in the manifest (default 105 × 68 m).
• Time: integer tick is the source of truth, plus sim_time_us. The match clock is a separate field that stops and runs according to the rules. Ball contacts carry their own sub-tick t_contact_us.

Observation

Action

At the level of an intent with parameters. The candidate engine already works this way Verified from sources: one intent out of six (MOVE, CONTROL, PASS, SHOT, CLEAR, CHALLENGE) plus eight continuous values (movement, force and direction on the ball, elevation, spin, gaze). There is no jump action; catching the ball is an outcome, not a command.

Cooperation

The 22 actions of one instant are computed on the same state and applied together.

How the agents would be developed

No model of real trajectories with published weights was found: the three reviewed were trained on private data Verified from sources. Published agent weights exist for Google Research Football, tied to that engine and not checked. The strongest learned 11 v 11 result found controls the 10 outfield players with a rule-based goalkeeper, in 3,000-step matches, with industrial-scale compute Verified from sources; the search was not exhaustive.

Attributes

Physical attributes as engine limits; technical ones as execution error; mental ones as explicit degradations of perception and selection, applied outside the decision program so that their effect is monotonic and auditable Engineering hypothesis. The candidate already has per-player profiles with top speed, accelerations and ball control Verified from sources.

How the football is measured

Structural measures (players near the ball, compactness, line coherence, occupation by role, sequence diversity, abnormal dead time); statistics against real-football references; a response test, an attribute-sensitivity test, and blind review by people who know football.

Autonomy does not depend on whether the agent is a neural network, nor on whether the 22 share weights. It depends on where the decision is taken and with what information. One set of weights evaluated 22 times with 22 different observations produces 22 different decisions; role, position and attributes enter as data. This is standard practice in cooperative multi-agent learning.

The record stores, per player and per decision tick, observation → action. An auditor can re-run the sealed policy on the recorded observation and check that the same action comes out. If it does, the action came from the agent and not from outside. Again, that alone does not exclude a central controller, hence tests 2–4.

Do not install by name. Neither messi-env nor messi-football existed on PyPI at reading time, although the tag's documentation shows pip install messi-football. A package appearing under that name would not be verified. Code is fetched only by full commit SHA.

The safety procedure of runbook G1a v1.1 governs any first execution: isolated machine, no network for third-party code, separate user, memory and process limits.

• The tag's own README says “GitHub tag and Release: Not published”. No version is declared released by the author.
• footballworld has a tests/ folder and a CI workflow; its deeper suites are private according to its documentation. Declared dependencies: jax, numpy, filelock; the render extra adds imageio, matplotlib and pillow.
• The step call returns no observation; observations come from separate observe calls. Normal full time is reported as “truncated”, not “terminated”.
• Not verified: whether the obvious-goal-opportunity classifier is called from another module; whether half-time consumes control ticks; the automatic goalkeeper catch path.
• Open question for the author: which line they consider current. Recommended as a non-blocking consultation.

• Unreal Engine 5 as an offline renderer: movie-render and pose search are listed as production-ready in Epic's documentation (delegated reading) Verified from sources.
• Animation: own assessment Engineering hypothesis: pose search solves locomotion but does not, by itself, satisfy contact constraints imposed from outside.
• The hard problem: foot on the ball at the recorded instant, without sliding. In A it is a constrained-synthesis problem; in D-lite and D/E it is avoided by limiting what the player can do.
• Unreal as host of an integrated, deterministic, render-free simulation: a hypothesis without sufficient documentary support. Async physics is listed as experimental and Unreal's Python only runs in the editor Verified from sources.
• Motion data: the largest licensed pack found has 308 clips; the commercial reference declares capture from more than 180 matches (EA page, delegated reading). Covering the repertoire will almost certainly require our own capture Engineering hypothesis.
• Generative video: not chosen as a renderer; it does not guarantee fidelity to the record.

• D/E is demonstrated in the Gameplay Football engine behind Google Research Football: clips selected by query, position from clip root motion plus a correction, ball touch fired on an animation frame, inside the simulation loop, and it runs without rendering Verified from sources.
• D-lite is demonstrated in parts: clip metadata in that engine acts as a primitive table, and the motion-graph and search-tree literature shows planning over clips with known displacement Verified from sources.
• “Replay the exact clip” is not demonstrated: that engine needs per-frame position and rotation offsets to reach the ball Engineering hypothesis (pending validation PV11).
• No open-source, permissively licensed, animation-driven football match was found in Unreal, Unity or Godot.

body_part_hint is a hint for animation, not a sporting fact, except when a rule depends on the body part (handball). The position tolerance (how far the animated pelvis may drift from the simulated point) is a contract parameter, to be measured.

Checks possible afterwards

1. Hash integrity: the chain and root match what was published.
2. Internal consistency: every event follows from the state (a goal is a line crossing; offside matches positions at the pass; the score is the sum of goals).
3. Autonomy: re-evaluating each sealed policy on the recorded observation gives the recorded action.
4. Re-simulation in the pinned environment from manifest and seed: same root. Reported even if it does not match.
5. Video against record: score, clock and events in the master match the record.

Checks 1–3 do not depend on numerical reproducibility across machines; check 4 does, so it is reported separately.

Record size: a calculation, not a measurement

Assuming 100 simulated minutes, 22 players × 12 float32 values, 10 ball values and 64 bytes of other data: ≈ 1.2 kB per tick; ≈ 70 MB at 10 Hz, ≈ 700 MB at 100 Hz, uncompressed. Full per-player observations, if stored instead of their hashes, would be a few GB per match. Record storage is negligible; video and intermediate frames are not.

One match, many broadcasts

The record contains no cameras. Any number of renders (wide shot, tactical camera, replays, commentary languages) can be produced from the same sealed record, and each video publishes the root hash of the record it came from.

The scheme matches the recipe NIST publishes for using its beacon (NISTIR 8213, 2019 draft, §7.2): commit in public to the hash of the program and its inputs, then derive the seed by combining that commitment with the beacon value. The same document requires that everything about the use of the future random number be specified in advance, and that the program be entirely deterministic given the beacon pulse and the other inputs.

Not verified: drand's current node count and threshold; any precedent of a sports body using these beacons (not searched). drand publishes no service-level agreement.

Common stop rule

Each stage has a maximum effort fixed before it runs. If it is consumed without passing the criterion, the stage stops and project direction decides. The numeric thresholds of each stage are registered in the repository, dated, before the stage runs, and shared with the promoters and the cross-review. They are not changed after results are seen; a justified change is recorded as a deviation.

Work that could run in parallel, only if authorised, with no execution

Contracts 1 and 2; the integrity protocol; inventory of licensed motion data; legal reading of the licence texts; search for the animation specialist.

Dependencies

• 1 → 2 → 3 is a chain.
• 4a needs stage-3 records and the animation specialist; 4b needs engine and Brain from stages 1–3. They can run in parallel.
• 5 depends on 4a, gate B and motion data; 6 on 5 and gate C; 7 on 6, 4b and the integrity protocol; 8 on 6.
• Beyond stage 3, no weeks are given: they depend on measurements that do not exist yet.

What could force a schedule revision

MESSI compatibility and CPU performance; configuring a 5-minute two-half match; per-player Brain separation; the chance-based referee; the upstream project changing or disappearing; failing to achieve minimum isolation; behaviour quality (the most likely cause of delay in weeks 6–16); AI tool usage limits; availability of the single lead-engineer role; availability of a specific cloud plan.

• Criteria fixed in advance. Advance and stop conditions are written and approved before each stage starts.
• Cheapest tests first. The two decisive questions are tested at the smallest possible scale.
• We own the connections. The contracts let a third-party engine be replaced without starting again.
• Three body designs kept open until evidence favours one.
• Honest reporting. Negative results are documented with the same care as positive ones.
• Two technical stop points (stages 2 and 5) and three engineering gates (A, B, C).