1) Generated Model (Ahead-of-Time Bind)
Plan-as-Prediction (Binding across time)
The model forecasts what should be true at each tick: completion, fatigue, anchor integrity, weather exposure, supply lead times. When sensors disagree, we treat that as prediction error and shift attention.
Attention Spotlight (Binding across features)
Only a few things can be bound “together” in the team’s shared workspace. The spotlight is steered by error magnitude and risk coupling.
“Feature-binding” analogue: Work-package object files
Each work package is treated like an object file: it binds “what” (task), “where” (cliff/ledge), “who” (crew), “how” (method), and “constraints” (anchors, weather) so the team doesn’t suffer illusory conjunctions.
“Temporal-binding” analogue: windows + lags
Status updates, procurement lead-times, and hazard dynamics each have different integration windows. Managing the project becomes managing the relative timing of those windows.
2) Sensors + Workspace (Bottom-Up Correction)
Lag Controls (Orchestrating timing)
Adjust lags to see how “late action” arises: if the model runs too slowly, you act late; if sensors are too delayed, you hallucinate stability.
Live Sensors (delayed, noisy)
| Signal | Now | Model | Error |
|---|
Attention Queue (what the team should look at)
Event-File Log (episodic buffer → org memory)
Each capture binds context + decision + outcome into a re-usable episode.
Explainers (button-sized theories → project analogues)
Feature Integration (Treisman): binding needs a controlled spotlight; in projects this is an explicit agenda + shared object files per work package.
Temporal Binding Window: signals bind if they land close enough; in projects: timeboxed standups, alert batching, and “don’t mix” unrelated cues.
Predictive Coding: top-down plan predicts; bottom-up exceptions update; in projects: forecasts + dashboards + exception-driven governance.
Global Workspace: a shared broadcast bus; in projects: a single source of truth + ritualized decision forums.
Event Files (TEC): stimulus-action-outcome bundles; in projects: post-mortems and decision records that are retrievable by cue.
3) How to read the prototype (and how it answers your motivation)
Reading lens
Start by running a few ticks. Then inject a surprise. Watch which signals light up, how the spotlight moves, and how the queue changes. Now adjust lags: you’re tuning the team’s “binding apparatus” (what binds, when it binds, and what gets broadcast).
Scenario anchors
The cliff forces hard coupling: logistics are brittle, weather matters, and safety constraints propagate. That makes prediction error more informative than raw status. Think of each tick as a day on the ledge: a small world, but with real lags.
Mini experiment
Set sensor delay high (5–6) and decision latency high (5–6), then inject a surprise: you will feel the project “hallucinate” stability and then panic too late. Now reduce decision latency while keeping sensor delay: you become “fast but blind” — the queue will oscillate. The sweet spot is context-dependent.