Worked Campaign Examples

These examples show how organizations can use Tokens for Progress as a coordination substrate.

They are not additional product concepts. They are design stress tests: each example starts from a real coordination goal and asks how far the existing primitives can carry it.

The recurring pattern is:

flowchart TD
    O[Community defines a standard] --> S[SkillVersion]
    S --> P[Problem]
    P --> A[Attempts]
    A --> R[Structured Artifacts]
    R --> SUB[Submission]
    SUB --> V[Verification / Review]
    V --> T[Trusted result]
    T --> N[More Attempts]
    T --> PP[ProblemProposals]
    T --> Q[Campaign-wide analysis]

A community can define a domain-specific artifact — a reproduction plan, commercialization dossier, provenance record, or proof certificate — without TfP creating a special database object for it.

The standard can live in a Skill:

SKILL.md
schemas/
examples/
scripts/
preflight/

Problems ask contributors to produce Artifacts following that standard. Verification and Review determine which results are trustworthy. Trusted outputs can then become inputs to more work.

Persistent Problems

A Problem does not need a new Revision whenever somebody finds a better answer.

Suppose a Campaign contains:

Maintain the commercialization dossier for Technology X.

If the task definition and verification criteria remain unchanged, any number of people or agents can start new Attempts against the same Problem Revision:

Attempt A → dossier A
Attempt B → dossier B
Attempt C → dossier C
Attempt D → dossier D

They may begin because:

• important news appeared;
• another analysis became available;
• somebody knows the domain and notices a missed opportunity;
• somebody simply believes the current result can be improved.

No Campaign-owner signal is required.

Artifacts remain immutable. A better dossier is a new Artifact and Submission, not an edit to old bytes.

A new Problem Revision is required only when the task specification itself changes: a new required field, different verification semantics, a different SkillVersion requirement, or another substantive change.

Future capabilities these examples test

Several recurring gaps are candidates for Stage 8.

ProblemProposal

A verified result may suggest entirely new work.

For example:

"Reproduce Paper X"
    ↓
reproduction plan
    ↓
proposes:
  "make repository runnable"
  "reproduce Figure 3"
  "map compute requirements"
  "run robustness analysis"

ProblemProposal is already roadmapped for Stage 8.

A proposal may also say:

There is now a good reason to revisit this existing standing Problem.

That should not prevent anyone from starting the work directly; it is a coordination and triage mechanism.

Result lineage

A new result should eventually be able to record what it builds on.

Conceptually:

dossier v7
├── based on dossier v6
├── uses market analysis A
├── uses buyer analysis B
└── cites technical assessment C

The exact representation is not frozen here.

Campaign-wide analytics

Campaign owners should be able to analyze their verified structured outputs without downloading and reparsing every Artifact on every query.

The likely implementation is:

verified structured Artifact
        ↓
asynchronous projection
        ↓
analytical storage / index
        ↓
query / aggregate / export

That analytical layer is infrastructure, not necessarily a CampaignDataset user-facing object.

Standing discovery

A DISCOVERY Problem may remain open indefinitely:

Find new papers worth reproducing.

Find previously unmapped technologies.

Find developments that make an old dossier worth revisiting.

Repeated Attempts continually surface candidates.

The examples

Stage 8 should use these examples to decide what abstractions are actually necessary.

A useful rule:

Do not add a core object because one Campaign wants a noun. Add one only when several unrelated Campaigns hit the same structural wall.