203 lines
7.5 KiB
Markdown
203 lines
7.5 KiB
Markdown
|
|
---
|
|||
|
|
title: "Nudge Space — Concept v0.1"
|
|||
|
|
type: concept
|
|||
|
|
status: draft
|
|||
|
|
repo: nudge-space
|
|||
|
|
domain: infotech
|
|||
|
|
created: "2026-10-04"
|
|||
|
|
updated: "2026-10-04"
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Nudge Space — Concept v0.1
|
|||
|
|
|
|||
|
|
Nudge Space is a parking lot for the ecosystem. A participant encounters
|
|||
|
|
something relevant, and the encounter is not worth a task. The thought is
|
|||
|
|
also too interesting to drop on the floor. It goes into peripheral view:
|
|||
|
|
kept, searchable, and able to show its face again if it keeps coming back.
|
|||
|
|
|
|||
|
|
This is the earliest layer of value and product discovery. The material is
|
|||
|
|
semi-structured on purpose. It is a collection of hunches, not a product
|
|||
|
|
backlog and not a design.
|
|||
|
|
|
|||
|
|
A **discovery topic** in this document is a theme that emerges from many
|
|||
|
|
nudges, the way a word cloud grows. That is a different thing from a State
|
|||
|
|
Hub topic, which is the registration bucket this repository sits in.
|
|||
|
|
|
|||
|
|
## The situation it answers
|
|||
|
|
|
|||
|
|
Work in this estate is coordinated by work records: intakes, workplans,
|
|||
|
|
tasks, decisions. That backbone is for things someone has decided to carry.
|
|||
|
|
The path into it is easy to overuse. A sharp remark in a review, a repeated
|
|||
|
|
irritation, a half-seen product shape, a tool that might matter next year:
|
|||
|
|
each of these can be written up as a task in a minute, and each such task
|
|||
|
|
competes with the work that already has the floor.
|
|||
|
|
|
|||
|
|
The other failure is silence. The same hunch appears in three repositories
|
|||
|
|
over a month, and nobody can see that, because each encounter was forgotten
|
|||
|
|
at the end of the session.
|
|||
|
|
|
|||
|
|
The parking-lot rule from agile meetings is the remedy. The thought is
|
|||
|
|
acknowledged, written where it can be found, and left alone. Attention
|
|||
|
|
returns to the agenda. Later, if the thought is still there, or if it has
|
|||
|
|
accumulated neighbours, someone can choose to pick it up.
|
|||
|
|
|
|||
|
|
## What a nudge is
|
|||
|
|
|
|||
|
|
A nudge is a short note of an encounter.
|
|||
|
|
|
|||
|
|
It has:
|
|||
|
|
|
|||
|
|
- something that was noticed
|
|||
|
|
- where it was encountered
|
|||
|
|
- when
|
|||
|
|
- enough words that a later reader can recognise it
|
|||
|
|
- optional tags, which are the seeds of the heatmap
|
|||
|
|
|
|||
|
|
It has no status, no owner, no estimate, and no acceptance criteria. It is
|
|||
|
|
not finished or cancelled. It sits.
|
|||
|
|
|
|||
|
|
A nudge is earlier than an intake. An intake, in the fleet work-record
|
|||
|
|
standard, is a spark someone has decided should enter coordination. A nudge
|
|||
|
|
is the spark before that decision. The kind registry of work records stays
|
|||
|
|
closed. A note with no lifecycle is already outside that registry: the
|
|||
|
|
standard says so for `RISK-N-*` notes, and the same line is drawn here.
|
|||
|
|
|
|||
|
|
Promotion, when it happens, happens somewhere else. A person or an agent
|
|||
|
|
creates an intake or a workplan in the repository that should own the work,
|
|||
|
|
and may then add a `promoted` pointer on the nudge. The nudge file stays in
|
|||
|
|
place, so the periphery still shows that the thought existed and where the
|
|||
|
|
work went.
|
|||
|
|
|
|||
|
|
## Where nudges live
|
|||
|
|
|
|||
|
|
A repository connects to Nudge Space by keeping its nudges in a top-level
|
|||
|
|
folder named `nudges/`.
|
|||
|
|
|
|||
|
|
The folder is the whole integration. There is no registration call per
|
|||
|
|
nudge, and participants do not copy their notes into this repository. The
|
|||
|
|
note stays next to the work where it was encountered, and it is published
|
|||
|
|
the same way the rest of that repository is published: a commit on Forgejo.
|
|||
|
|
|
|||
|
|
This repository follows the same convention for hunches encountered while
|
|||
|
|
working on Nudge Space itself. Its `nudges/` folder is a participant folder.
|
|||
|
|
The index this repository will eventually build is a projection of many such
|
|||
|
|
folders, including its own.
|
|||
|
|
|
|||
|
|
### File shape
|
|||
|
|
|
|||
|
|
One nudge is one Markdown file.
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
nudges/YYYYMMDD-short-slug.md
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
The date is the day it was first written. The slug is stable. Renaming is a
|
|||
|
|
later problem for the reader; until then the path is the identity, together
|
|||
|
|
with the repository that holds it.
|
|||
|
|
|
|||
|
|
```yaml
|
|||
|
|
---
|
|||
|
|
title: A few words naming the hunch
|
|||
|
|
noticed: 2026-10-04
|
|||
|
|
origin: repo, conversation, document, or url — specific enough to find again
|
|||
|
|
tags: [kebab-case, another-theme]
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
What was noticed. A few sentences of the original thought are enough.
|
|||
|
|
|
|||
|
|
Why it is parked. One or two sentences on why it should stay in the periphery.
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Optional fields, used when they are true:
|
|||
|
|
|
|||
|
|
| Field | Meaning |
|
|||
|
|
|---|---|
|
|||
|
|
| `recurrence` | Whole number. Bump it when the same hunch shows up again. Absent means once. |
|
|||
|
|
| `see_also` | Paths or URLs that belong to the same encounter. |
|
|||
|
|
| `promoted` | Id of a work record created elsewhere, after a deliberate promotion. |
|
|||
|
|
|
|||
|
|
The body can be rough. Write the thought in the words it arrived in. Do not
|
|||
|
|
add a task list, a design, an estimate, or an owner. Those are the marks of
|
|||
|
|
work, and work belongs in a work record.
|
|||
|
|
|
|||
|
|
A future reader skips, and does not index as nudges:
|
|||
|
|
|
|||
|
|
- `README.md`
|
|||
|
|
- names that start with `.` or `_`
|
|||
|
|
- anything outside `nudges/`
|
|||
|
|
|
|||
|
|
## How this repository reads them
|
|||
|
|
|
|||
|
|
The intended reader is Nudge Space, fetching participant folders through
|
|||
|
|
Forgejo.
|
|||
|
|
|
|||
|
|
The shape of that read:
|
|||
|
|
|
|||
|
|
1. The set of repositories is the set this estate already publishes on
|
|||
|
|
Forgejo. The remote form already used here is
|
|||
|
|
`forgejo-remote:coulomb/<repo>`.
|
|||
|
|
2. The reader fetches a repository read-only and takes `nudges/**/*.md` at a
|
|||
|
|
commit.
|
|||
|
|
3. It does not commit back into participant repositories.
|
|||
|
|
4. It uses whatever Forgejo read access the estate already has. This concept
|
|||
|
|
opens no new credential lane.
|
|||
|
|
5. A collected nudge is identified by repository plus path. Frontmatter
|
|||
|
|
enriches that identity. It does not replace it.
|
|||
|
|
|
|||
|
|
Search and exploration sit on top of that collection: words, tags, origin
|
|||
|
|
repository, and date. Opening a tag shows the files that fed it, each still
|
|||
|
|
pointing at its home repository.
|
|||
|
|
|
|||
|
|
v0.1 does not build that reader. It fixes the place the notes live and the
|
|||
|
|
shape they have, so a later reader has an honest corpus.
|
|||
|
|
|
|||
|
|
## The heatmap
|
|||
|
|
|
|||
|
|
Over time the collection develops a topic heatmap, close to a word cloud.
|
|||
|
|
|
|||
|
|
Tokens come from `tags`, from `title`, and from phrases that repeat in the
|
|||
|
|
bodies. A token gains weight when more nudges carry it, when they come from
|
|||
|
|
more than one repository, and when they recur or arrive recently. The exact
|
|||
|
|
weighting waits until there is a body of nudges to look at. Choosing a
|
|||
|
|
formula against an empty collection would be ceremony.
|
|||
|
|
|
|||
|
|
The heatmap is a perception aid. It answers "what keeps coming back?" It
|
|||
|
|
does not sort a backlog, assign an owner, or create a task. A bright topic
|
|||
|
|
is a reason to look. Looking is optional.
|
|||
|
|
|
|||
|
|
## Where this sits in discovery
|
|||
|
|
|
|||
|
|
Earliest first:
|
|||
|
|
|
|||
|
|
1. **Nudge.** Noticed, parked, still peripheral. This repository.
|
|||
|
|
2. **Intake.** Someone decides the spark should enter coordination. The
|
|||
|
|
owning repository.
|
|||
|
|
3. **Workplan and tasks.** The spark has a body of work. The owning
|
|||
|
|
repository.
|
|||
|
|
4. **Product, tool, or canon.** The work has a durable home.
|
|||
|
|
|
|||
|
|
Nudge Space owns step 1. Steps 2–4 stay in the repositories that take the
|
|||
|
|
work up. State Hub remains the read model for those work records. Nudges are
|
|||
|
|
not projected into it as tasks.
|
|||
|
|
|
|||
|
|
## What v0.1 establishes
|
|||
|
|
|
|||
|
|
- This intent and concept.
|
|||
|
|
- The `nudges/` convention and the file shape above.
|
|||
|
|
- Registration of the repository with State Hub, so the place has an address
|
|||
|
|
in the estate.
|
|||
|
|
|
|||
|
|
## What stays undesigned until someone promotes it
|
|||
|
|
|
|||
|
|
These are named so they are not forgotten. They are not tasks.
|
|||
|
|
|
|||
|
|
- The Forgejo fetch and the index.
|
|||
|
|
- The search and exploration space.
|
|||
|
|
- The weighting of the heatmap.
|
|||
|
|
- Any view that spans private repositories beyond the Forgejo access that
|
|||
|
|
already exists.
|
|||
|
|
|
|||
|
|
A recurring theme in the corpus is the evidence that one of these, or any
|
|||
|
|
other hunch, might deserve an intake. The evidence is the recurrence. The
|
|||
|
|
decision to promote stays explicit, and it is made outside this folder.
|