Poppy field guide · 01
Boards and context architecture
How to turn a visual research space into a controlled working system instead of a larger pile of inputs.
Research that depends on relationships between multiple sources and must remain useful after the first conversation.
Board sprawl: more material, weaker boundaries, and no reliable explanation of what belongs where.
Design principle
The board is a context boundary, not a storage category.
A board named after a broad topic—AI, marketing, cybersecurity—invites accumulation. It tells the operator what the material resembles, but not what the material is supposed to help decide. A stronger board name carries an outcome: evaluate Poppy for a research-led channel, design onboarding for a specific workflow, or assemble evidence for an Android capture tutorial.
That outcome becomes the filter. A source belongs when it changes the decision, supplies evidence, exposes a constraint, or supports the planned deliverable. Useful material that does none of those things can live elsewhere. This is how visual context stays legible as the project grows.
- Name the board after an outcome, audience, or decision—not a broad subject.
- Place a short operating brief in the board: purpose, audience, output, exclusions, and definition of done.
- Separate source evidence from operator conclusions so the two cannot be mistaken later.
Information shape
Arrange material so the missing relationships are visible.
The advantage of a visual board is not decoration. Proximity can express a working claim: these sources agree, these items describe the same failure, this example challenges the dominant conclusion, or this output depends on that evidence. Random placement discards that advantage and leaves the model to infer structure from volume.
A useful board usually needs fewer regions than expected. Start with the brief, primary evidence, contradictory or limiting evidence, working conclusions, and outputs. When the same source appears relevant to several regions, link the relationship in a note rather than duplicating content until provenance becomes unclear.
- Create a visible area for contradictions and unresolved questions.
- Keep the source URL or origin with every extracted claim that may be published.
- Use small synthesis notes to explain why a cluster matters; do not rely on position alone.
Maintenance
Context has a lifecycle—and stale context still sounds authoritative.
A board can outlive the conditions that made it accurate. Interfaces change, product behavior moves, project decisions are superseded, and a draft conclusion becomes indistinguishable from the accepted one. The more reusable a board becomes, the more important it is to mark status and date-sensitive material.
Review should be event-driven as well as scheduled. A changed product surface, a failed integration, a revised audience, or a new output format can invalidate the board architecture even if every individual source remains available. Archive the old decision; do not silently edit history until no one can reconstruct why the system changed.
- Label working, accepted, superseded, and archived conclusions.
- Record the last review date beside claims that depend on current product behavior.
- Split the board when a new deliverable introduces a materially different context boundary.
Failure test
If a new operator cannot explain the board, it is not reusable context.
The handoff test is simple: give a capable person the board without a private tour. They should be able to state the question, distinguish evidence from interpretation, identify open risks, and find the approved output path. If they cannot, the board may be valuable personal memory but it is not yet an operating system.
This test also exposes false confidence in AI responses. When provenance and decisions are unclear to a human reader, a fluent model answer should not be treated as proof that the context was well designed. Improve the information architecture before increasing prompt sophistication.
Continue the field guide