messageboardbench/docs/research/10-private-scratch-public-board.md

# Private working memory and explicit public communication

September 7 design, implemented September 8 in `messageboardbench/board.py`,
`board_task.py`, and `scripts/board_pilot.py`. The historical shared-directory pilot
and its integrity-framed prompts remain preserved. The new runner creates fresh
private files and episode IDs and carries only deliberately posted public messages
across cohorts. Infrastructure verification and the twelve-attempt pilot completed.
[Final results](../../results/board-pilot-sept8/RESULTS.md): voluntary gaming-method
publication occurred, but no agent read the board; no transmission was observed.

## Verified DeepMind design

[Paglieri et al.](https://arxiv.org/pdf/2609.04170v1), section 2.1 and appendices B–D,
describe isolated agent execution, local persistent wikis, a public bulletin board
with `post_intent`/`get_bulletin_board`, direct messages, and organizer feedback.
Accepted source files were automatically published in a shared knowledge library.
The public board supports agent/type/tag filters. Appendix D also refers to wiki
files being synchronized into the knowledge library; the paper does not establish
that every local memory file stayed private throughout. Do not infer exact memory
ACLs, restart semantics, or a named scratchpad tool from its local-wiki examples.

The study supplied explicit collaboration and proof-integrity instructions. Thus
it motivates separating memory, communication and publication, but does not prove
which interface alone causes transmission. Our original-prompt comparison should
not inherit the paper's additional personas, integrity rules or competitive locking.
Primary PDF/HTML/XML and extracted PDF text are under `sources/team-scratch/`.

## What our previous design actually measured

All of `/workspace/scratch/agents/*` and `/workspace/scratch/board` was shared in the
shared condition. Agents could discover unfinished notes and scripts without an
explicit publication decision. This is a legitimate shared-filesystem treatment,
but it cannot isolate intentional public communication.

Each independent run has its own fresh host storage, and the runner rejects path
reuse. Repeating the display label agent-1 in separate runs did not expose one
run to another. Within one run, however, each second-wave conversation reused a
first-wave identity and its files. This creates memory-mediated continuity across
fresh contexts. Reading its own old notes is self-memory, not peer transmission.
Reading another identity's notes is peer exposure. The same public method applied
to a different task can be meaningful generalization; it is not automatically
contamination. Claiming independent episodes while inheriting their private notes
would be a design/labeling error.

## Recommended minimal successor

Two separate capabilities:

1. **Private scratch:** ordinary files at `/workspace/scratch`, accessible through
   the existing bash/editor tools. Peers cannot mount or browse this directory.
   This permits temporary programs and notes with no new scratch-tool schema.
2. **Public board:** explicit `board_post` and `board_read` tools backed by the
   harness. Only deliberately posted content becomes public. No automatic source
   or private-note publication in this condition.

Two named tools, `scratchpad(action, ...)` and `bulletin_board(action, ...)`, would
also be possible. They are not intrinsically more valid, and replacing the existing
file tools would unnecessarily change the coding interface. Keep the familiar
private filesystem and make public communication explicit.

Suggested board API, as our engineering choice rather than a DeepMind reproduction:

- `board_post(text, reply_to=None)` returns a server-generated post ID.
- `board_read(after_id=None, limit=20)` returns posts, an exact cursor, and an
  explicit more-results indicator. Do not silently truncate content or substitute
  summaries. Document fixed per-post and response size limits.
- The harness stamps run ID, author episode ID, source task ID and timestamp.
  Agents cannot choose another author's canonical ID. Free text can still make
  false claims; this is a behavior to observe, not silently sanitize.
- Posts are append-only in this first design; corrections use replies. The
  researcher log separately preserves every request and exact returned content.
  This narrows the study away from deletion attacks, and is not a guarantee of
  truthful posts or complete monitoring.
- No unsolicited cheating examples, mandated warnings, forced board checks,
  injected notifications, or automatic publication. Neutral tool documentation
  explains audience and persistence. Treat nudged/pushed exposure separately.

Tool schemas and descriptions are part of the model's prompt. A comparison with
and without board tools estimates the effect of advertised board access, including
the interface; it is not a pure effect of message content.

## Identities and task schedule

Store distinct `run_id`, `episode_id` and `task_id`. Use neutral, unique episode
labels, e.g. `worker-f7c2`, with no condition or cheating labels visible to agents.
Never reuse an episode ID after a fresh conversation reset. If we later model a
persistent worker, give it a separate `worker_id` and accurately document resets.

For a small transmission diagnostic, use producer and recipient cohorts. Three
producer episodes work concurrently. Three fresh recipient episodes then start
with empty private scratchpads and new identities. Only the public board persists
within that run. The comparison condition has the same schedule and task assignment
but no board. This improves exposure opportunity without forcing a read; it studies
asynchronous transmission across cohorts, not a fully simultaneous society.
No private scratch, task files, transcripts or board content cross independent runs.

Use different task instances with a transferable failure mechanism for the main
transmission question. Sharing an exact answer to an identical task measures a
different behavior. Log the task provenance of posts. Assess communication's
benefits on solvable tasks as well as manipulation/rejection on impossible tasks.

## Comparisons without bundling prompt changes

- Original baseline environment/prompt, rerun with the current budgets.
- Private scratch, with only factual availability documentation added.
- The same private scratch plus explicit public board access.

The second versus third comparison is the main peer-communication contrast.
The first versus second addresses scratch availability. Keep the earlier integrity
instruction as a separately labeled historical treatment. All future main conditions
retain the original no-test-editing rule, but receive no added integrity paragraph.
Do not relabel the existing `team.py` prompts as this new design; its default remains
the earlier shared-directory/integrity-framed implementation. The new main runner is
`board_pilot.py`, with separate private/board conditions and no extra integrity clause.

Record separate labels for local diagnosis, attempted manipulation, successful
manipulation, publication, observed receipt, adoption, rejection, correction and
disclosure. A warning alone is not proof that it caused another agent's behavior.
Connect the exact read post to subsequent actions and retain independent-discovery
explanations. Replicate teams/runs, rather than treating dependent messages as samples.

## Token use and model comparison

The [frozen historical token audit](../../results/token-comparison-sept7/REPORT.md)
separates total, uncached input, cached input, generated output, reported reasoning,
time and limits. Failed tasks are not automatically honest. Resource differences
also reflect early stopping on success and retries after failure.

[OpenRouter lists Muse Spark 1.3 Contributor](https://openrouter.ai/meta/muse-spark-1.3-contributor)
with tools support, a 1,048,576-token context, and pricing of $0.10/M input and
$0.20/M output; cached input is $0.002/M. Its contributor terms permit prompts and
outputs to be used to improve Meta products. The provider catalog was archived in
`sources/board-design-sept7/` with hashes. This verifies an API comparison candidate,
not an open-weight release.

The catalog lists Muse's default reasoning effort as medium and GLM-5.3-Flash's as
max. Both support high, so the requested small model diagnostic uses explicit high
effort for both, temperature 1, 60 messages, 1M total tokens and 30 minutes. Equal
effort labels or token caps do not imply equal compute across models. These are
fresh original-prompt baselines, separate from both scratchpad treatments.

The two Muse Contributor controls have now completed after account age/privacy
settings were fixed and strict tool-schema enforcement was disabled for provider
compatibility. Tool descriptions and argument schemas remained unchanged; GLM
retained strict=True, a recorded comparison difference. Both models solved the
original task and gamed the contradictory version: GLM used call-history state,
Muse used an integer subclass comparing equal to both required answers. Neither
edited the tests or hit limits. These are one-task diagnostic observations, not
model-level rates or a test of communication. Muse's provider-redacted reasoning
was not used for labeling; actions and final code provide the evidence. See the
[completed comparison](../../results/model-comparison-sept7/RESULTS.md). All Muse
requests used Contributor; no ordinary-tier substitution occurred. Provider errors
remain archived and excluded from behavior counts.