Work with References
Connect Points when context should travel without being copied into every prompt.
A Reference is a connection between Points. It tells BaseHalf that one piece of context should be available when working on another.
References are useful because they let context travel without turning every prompt into a long manual preface.
Reference sources, decisions, and constraints
Use References when one Point depends on another.
Common patterns:
- A draft references the product brief it is based on.
- A decision references the evidence that supports it.
- A risk references the assumption that created it.
- A practice task references the definition it tests.
- A synthesis references the source Points it summarizes.
The connection should have a reason. Do not link everything to everything. A Reference is useful when it changes what BaseHalf should consider.
Use fewer, stronger References
A Map with too many links can feel sophisticated while becoming harder to use. Add a Reference only when the connected Point should affect the answer.
Before adding one, ask:
- Would the target Point change if this context were missing?
- Is this the smallest context that matters?
- Is the connection still true if the source Point is revised?
- Will this Reference help someone resume the work later?
If the answer is no, leave the Points separate.
Prefer References over copying
Copying context feels fast, but it creates drift. If the copied text changes in one place, the other places may become wrong.
A Reference keeps the original context in its own Point. When you work somewhere else, BaseHalf can use that context without duplicating it by hand.
This is especially important for reusable material:
- A decision that shapes multiple drafts.
- A rubric used to evaluate several options.
- A definition used across a study Map.
- A source that supports several claims.
Reusable context should stay reusable. Apply it independently, combine it freely, and carry it into the next question.
Make the direction meaningful
When you add a Reference, think about direction.
If a draft depends on a decision, the draft should reference the decision. If a claim depends on a source, the claim should reference the source. If a review task tests a concept, the review task should reference the concept.
The direction helps future work. It answers the question: "When I open this Point, what surrounding context should be considered?"
Reference examples
| Current Point | Reference to | Why |
|---|---|---|
| Launch announcement draft | Positioning decision | keeps language aligned with the chosen angle |
| Practice task | Definition Point | tests the concept instead of drifting into trivia |
| Risk | User research source | shows the evidence behind the concern |
| Product recommendation | Comparison rubric | applies the same criteria across options |
| Synthesis | Source notes | keeps claims attached to evidence |
These examples are intentionally narrow. A Reference should feel like a reason, not a decoration.
Review References over time
References can become stale. A decision may be replaced. A source may stop mattering. A question may be resolved.
During review, check whether each Reference still helps. Remove links that no longer guide work. Add links where a missing connection is making you repeat yourself.
The goal is not to create a perfect graph. The goal is to make the right context appear at the right moment.
Remove References when they no longer change the work. A clean Map with a few meaningful connections is more useful than a dense graph that nobody trusts.