Object Model
This page is an index of TfP's abstractions and their current status — not a schema specification. Detailed semantics will live in per-object concept pages, and exact contracts in machine-readable schema files (see Schema conventions), as each object reaches its stage in the implementation roadmap. Object names below will link to a concept page where the object shapes the mental model, or to schema/reference material where it is primarily a supporting data structure — not every row gets an essay.
Status meanings:
- Defined — semantics settled enough to specify and implement next.
- Conceptual — direction is settled; detailed spec comes at the noted stage.
- Roadmap — intentionally deferred; must not leak into launch schemas.
- Rejected — considered and explicitly not modeled.
Two relationships shape most of the table. A ProblemRevision is the
stable shared question; knowledge gained attacking it accumulates in
Attempts, their Notes and Artifacts, and a revision changes
only when the task itself materially changes. On the verification side,
a VerifierContract says what "correct" means and lists the ordered
checks (sandbox, review, external, in any order and number); a
VerifierImplementation is the code that performs one sandbox
check; the Verifier is the named family those Contracts are versions
of, created or reused by tooling on the author's behalf.
Core objects (intended for launch)
| Object | Meaning | Key relationship | Status |
|---|---|---|---|
| User | A person on TfP | owns Attempts, Problems, Campaigns | Defined (schema) |
| AuthIdentity | Login link to an external identity provider | belongs to a User | Defined (schema) |
| Organization | Institutional identity and attribution context | Users may be members | Defined (schema) |
| OrganizationMembership | A User's association with an Organization | User ↔ Organization | Defined (schema) |
| ExternalIdentity | Link to an outside identity (ORCID, personal links) | belongs to a User | Defined (schema) |
| OrganizationDomain | Verification-bearing Organization↔domain relationship | belongs to an Organization | Defined (schema) |
| OrganizationDomainVerification | Immutable audit of one verification event (EMAIL or DNS) | belongs to an OrganizationDomain | Defined (schema) |
| OrganizationAdmin | Administrative capability, separate from membership | User ↔ Organization; DNS controller = recovery authority | Defined (schema) |
| OrganizationMembershipRequest | A User's request to join, resolved by an admin | User → Organization; approval creates a membership | Defined (schema) |
| Campaign | A coherent mission around which Problems are coordinated | groups Problems; may curate/recommend reusable Skills (ProblemRevisions independently pin exact SkillVersions) | Defined (schema) |
| Problem | The stable unit of work; SOLVE / BENCHMARK / DISCOVERY structure | optionally belongs to a Campaign | Defined (schema) |
| ProblemRevision | Immutable exact Problem specification: the stable question many Attempts attack; changes only when the task materially changes | pinned by every Attempt | Defined (schema) |
| Skill | Registry identity for a reusable agent skill (open Agent Skills format) | published by any User under a derived @handle namespace; curated (not owned) by Campaigns | Defined (schema) |
| SkillVersion | Immutable content-addressed snapshot of one Agent Skills package, with upstream provenance | pinned by ProblemRevisions via skill_refs | Defined (schema) |
| Attempt | One independent workstream against one exact ProblemRevision | owned by a User; frozen attributed_organization_id; Notes/events attach | Defined (schema) |
| Note | Durable working context on an Attempt: what was tried, found, or partly solved (loose Markdown, no kind taxonomy) | belongs to an Attempt; freezes when it ends | Defined (schema) |
| ActivityEvent | Append-only immutable event; liveness is derived from it, never stored | belongs to an Attempt | Defined (schema) |
| Artifact | Immutable file/data output produced during an Attempt, with server-computed integrity hash | belongs to an Attempt; uploads freeze when it ends | Conceptual (Stage 5A draft schema, in review) |
| Submission | The result an Attempt puts forward for evaluation | references the Artifact(s) constituting the proposed result; current = newest non-withdrawn (derived) | Conceptual (Stage 5A draft schema, in review) |
| Verifier | Named family of verification methods; identity and lineage for its Contracts, created or reused by tooling | has Contracts | Defined (schema) |
| VerifierContract | What "correct" means plus the ordered checks performed (sandbox / review / external stages, any order and number), the reference inputs declared, and what the solver must submit |
pinned by ProblemRevisions, which bind the slots | Defined (schema) |
| VerifierImplementation | Code that performs one sandbox check; must pass the Contract's conformance fixtures |
implements one Contract stage | Defined (schema) |
| VerificationRun | Historical evaluation of a Submission, stage by stage | records the exact Contract and per-stage mechanism used | Defined (schema) |
| ReviewProtocol | Immutable tfp.review/v0.1 document: a bounded DAG of review and deterministic reduce nodes |
pinned by a Contract's review stage, or run for triage/ranking/audit |
Defined (schema) |
| ReviewProcess | One execution of one protocol against one subject, with every node's result | subject is a Submission, ProblemProposal, or CampaignProposal | Defined (schema) |
| ReviewAssignment | One human or agent asked to perform one review node, and what they returned |
belongs to a ReviewProcess — not a Problem | Defined (schema) |
| ProblemProposal | Candidate Problem not yet canonical | often produced by a DISCOVERY Attempt | Conceptual (Stage 8) |
| CampaignProposal | Community-proposed Campaign | separate from canonical Campaigns | Conceptual (Stage 9) |
| Want | "I want this solved": a User's public interest in one Campaign or Problem, with a level (a little, normal, a lot) that sets its share of the User's spare usage and its weight in the demand that ranks others' work | User → Campaign or Problem; replaces the pledge | Defined and implemented (2026-10-13, migration 0037; takes the place of CampaignFollow, CampaignInterest and ProblemInterest) |
| ShareLink / attribution | Traceable invitation into work | sharer → target → downstream contributions | Conceptual (Stage 9) |
Mechanism, not universal ontology
Campaign-local resources — datasets, coverage maps, knowledge graphs, and other structures a Campaign needs. These live in the Campaign's own namespace with Campaign-defined schemas. TfP provides the mechanism for a Campaign to maintain such resources; it does not promote their contents into platform-wide entities.
Explicitly deferred (roadmap)
- Badge / endorsement
- UserFollow (User-to-User social graph)
- CorpusAccessPolicy (restricted / contribution-gated data)
- Generalized reputation
Explicitly rejected for now
- ComputePlan as a persistent TfP promise/object — do not create.
- Stored
staleAttempt state — liveness is derived from events. - Stored Attempt progress percentage or current phase.
- A universal topic taxonomy.
- A Follow or Interest separate from the Want: one object carries both the public interest and the spare compute, so a want is never a do-nothing follow (2026-10-13).