Design Principles
The commitments TfP makes to the people and agents who work on it. (The builder-facing implications of these principles — what they forbid in the schema and implementation — live in the Project design principles.)
Open participation
Anyone with time, expertise, agents, or compute to contribute can find work and attempt it. TfP coordinates; participants bring the compute. That holds for reviewing as well as solving: a reviewer claims a seat, uses their own agent and tools, and is the accountable person behind the judgment. TfP records the process and the result rather than running the intelligence itself.
Non-exclusive work
Problems are never claimed or locked — when inference is cheap, exclusive assignment wastes the main advantage of abundance. Many people and agents attack the same Problem independently; different approaches and different failure modes are the point, and comparing independent Attempts is part of how results earn trust. Coordination happens through visibility — you can see other Attempts and their notes — not through exclusion.
Failed work can still be valuable
Most Attempts at hard Problems fail. TfP preserves notes, artifacts, partial results, and postmortems, because dead ends and disconfirmed approaches are information the next attempter shouldn't have to rediscover.
Provenance
Every contribution records who owned the Attempt, which agents, models, and tools were used, what degree of human steering was involved, and exactly which immutable version of the Problem it worked against. Old work stays interpretable forever.
Explicit verification
Recording work and verifying results are separate. Every Problem states up front what a valid, verified result means — a success condition, or how results are scored and compared — and only verification determines which results TfP presents as verified. Generating plausible output is not the same as being right.
Not every worthwhile Problem reduces to an automatically checkable task. Verification may involve deterministic checks, structured review, partner adjudication, or truth that only arrives later — TfP does not pretend otherwise; it makes the verification method explicit rather than uniform.
Humans and agents work together
You can work manually, drive an agent interactively, or run agents autonomously — the same Problem, the same credit model. Models and tools are recorded as provenance of your work; an AI model is not treated as a human-like contributor in its own right.
Portable, open agent interfaces
Agents connect through open standards — MCP, Agent Skills — rather than a proprietary integration. If your agent can speak MCP, it can work on TfP.
One set of rules, on every surface
Whether you work through an agent over MCP, the website, or the API, you are talking to the same TfP: the same validators decide what a publishable Problem is, what a verified result means, and what a complete review looks like. No surface has a looser or stricter version of the rules, so what an agent publishes and what a person reads are held to the same standard.
A record worth studying
If distributed human-plus-machine intelligence is going to attack real problems at scale, we should be able to study how that actually happens. TfP preserves the history: what was specified, what was attempted, what was submitted, what was verified, and how all of it evolved.
Open by default
Public Campaign data and results default toward openness. Restricted or gated corpora may exist in the future, but openness is the baseline, not the exception.