This is a field report from a contributor in their first month on Post Fiat Task Node: eight tasks completed, five over-rewarded at 2x to 2.5x, three paid exactly the listed amount, zero under-rewarded. The pattern that separates the two columbs is the substance of this guide.

Most guides like this start with theory. This one starts with the table.

1. The Actual Data

The table below summarizes the full dataset.

Five of eight earned the over-reward bonus. Three did not. The Score and Tier columns are identical across all eight rows. Whatever drives the bonus, it is not the score.

2. The Core Insight: Score and Reward Are Decoupled

Compare Task 6 (scoring system spec) and Task 7 (onboarding specification). Both received the highest evaluator tier with a perfect score. Both built on the same chain of prior work. Both had similar listed amounts (3,200 and 3,600 PFT). Both received evaluator feedback praising depth, completeness, and execution quality.

Task 6 paid 2.5x the listed amount. Task 7 paid exactly listed.

Same tier. Same score. Different reward outcome by a factor of 2.5x.

This isn't an outlier. It's the most important observation in the data: quality gets you to the listed amount with no penalty. The bonus is something else entirely.

The question, then, is what triggers the bonus.

3. What Earned the Bonus

The five over-rewarded tasks share a specific structural property: each one defined rules, constraints, or decision logic that other downstream work would have to operate within.

• The scoring system spec defined formulas, edge cases, gaming risks, and named test scenarios — a constraint system that any future development would have to honor.
• The UI architecture spec defined reusable components and visual hierarchy that all subsequent screen work would inherit from.
• The two weekly decision frameworks (one for training, one for execution review) defined the rubric — explicit rules for when to progress, hold, or reduce — that future weekly reviews would apply.
• The user flow map defined the structural transitions that all subsequent UI work would have to respect.

In each case, the deliverable wasn't documentation of decisions already made. It was the generation of new constraint structure — rules that future work has to work around.

4. What Didn't Earn the Bonus

The three exactly-listed tasks were not failures. They scored equally well by every visible metric. They were thorough, well-executed, and squarely within the contributor's domain. What they share is also specific: each one documented an existing process or design rather than generating new constraint structure.

• The product specification organized features and scope into a clean readable format. Useful, but the underlying decisions were already made.
• The process SOP turned an existing weekly review workflow into a reusable checklist. The process existed; this was its formalization.
• The onboarding specification defined the user-facing flow for a feature whose underlying logic was already specified in earlier tasks. Documentation, not new architecture.

This is not a value judgment. Documentation tasks are necessary, often critical to the broader work, and they reliably pay the listed amount. They simply do not stack the bonus.

5. The Pattern, Stated as a Rule

The Post Fiat Task Node rewards exceptional execution at the listed amount. The over-reward bonus is reserved for work that creates load-bearing constraint structure — rules, frameworks, and decision logic that future work must operate within.

This reframes how to choose tasks. The strategic question isn't "is this task within my domain?" That gets you to the listed amount. The strategic question is "does this task generate new structure that future tasks will have to honor?" That's what triggers the bonus.

6. Choosing Tasks That Trigger the Bonus

Three filters, in order:

Filter 1 — Domain depth. Request tasks only in domains where you already have weeks or months of accumulated thinking. Without prior depth, output collapses into AI-generated generalities that an evaluator recognizes immediately. Every one of the eight tasks above came from two domains the contributor was already deep in: personal product development and a personal physical training protocol.

Filter 2 — Constraint generation. Among tasks within your domain, prefer ones that ask you to define rules, frameworks, scoring logic, decision rubrics, architectural choices, or other structural primitives. Tasks that ask only for documentation, summaries, or descriptions of work already completed will pay listed and not more.

Filter 3 — Chain coherence. Tasks that build on previous submissions carry compounding credibility. A scoring spec that references a product spec and a user flow from earlier tasks demonstrates a coherent body of work. The system recognizes continuity.

If a task fails Filter 1, decline it. If it passes Filter 1 but fails Filter 2, accept it for the listed reward but don't expect the bonus. If it passes all three, it's a high-leverage task — execute carefully.

7. Verification: Be Surgical

Verification is the post-submission step where the system asks a specific question about the deliverable. Across eight tasks, the pattern that consistently worked was simple: answer exactly what was asked, pull the answer directly from the document, and stop.

Not "here's the answer plus some context." Not "here's how my approach handles this question." Just the literal piece of the document the verification asked about.

If the verification asks "paste the rule for when to reduce load," paste only that rule. The progress and hold rules are not relevant to that question.

If you find yourself struggling to answer a verification question, that's a signal that the document is missing something the task required — not that the question is tricky. Go fix the document.

8. Common Mistakes

Mistake 1 — Treating page count as a quality signal. A one-page deliverable that fully satisfies the requirements outperforms a five-page deliverable that pads to look impressive. Substance per page matters; total pages do not.

Mistake 2 — Adding unrequested content. If the task asks for three tracked variables, providing seven dilutes the signal. Stick to what's specified. Excess content does not increase rewards and may obscure the core deliverable.

Mistake 3 — Submitting first drafts. Every over-rewarded task in the data above went through at least one review pass before submission. The differences caught in review were small — a formatting issue, a formula that didn't add up, a phrase that hedged when it should have been direct — but the correlation with bonuses was consistent.

Mistake 4 — Cold-prompting AI tools. Using AI to generate content from a blank slate produces output an evaluator reads as AI-generated. The workflow that produced the over-rewarded results was inverted: the substantive thinking was done first, by the contributor, with AI used to organize and format already-formed conclusions into clean deliverables.

Mistake 5 — Ignoring the verification text. Re-read the verification section word by word before submitting. If it says "must include at least three named examples," count the examples. Don't assume coverage; verify against the literal text.

9. Pre-Submission Checklist

Run this every time, in order:

Requirements

• Re-read the task description. Is every specific requirement addressed?
• Re-read the verification section word by word. Can each requirement be visually located in the deliverable?
• Count any minimum quantities (sections, examples, scenarios) and verify the count.

Bonus eligibility

• Does this task generate new constraint structure (rules, frameworks, decision logic)? If no, expect to be paid the listed amount.
• Does the deliverable build on or extend previous submissions? If yes, make those connections explicit.

Quality

• Could a developer or downstream user act on this immediately without follow-up questions?
• Has anything not explicitly asked for been removed if it dilutes the core deliverable?
• Is every claim specific (numbers, names, explicit rules) rather than vague?
• Has the document been reviewed at least once after the first complete draft?

Verification prep

• Can the answer to any likely verification question be located in the document quickly?
• Are key elements (rules, formulas, frameworks) stated cleanly enough to extract verbatim?

10. Closing

Eight tasks is a small sample. The patterns above might shift as the network evolves, as evaluator weights change, or as a contributor's profile within the system matures. But the core decoupling — score determines whether you get paid, structure determines whether you get the bonus — is supported by data clean enough that someone running their next eight tasks against these filters should be able to test it for themselves.

The most useful thing this guide can offer is not advice. It's a hypothesis backed by a reward table, and an invitation to other contributors to verify it against their own data.

If you want to test this yourself, you can try the Post Fiat Task Node. Just make sure you come in with a real project, the system rewards actual work.

If you want a deeper understanding of how the system works, you can read the Whitepaper.

Based on eight tasks completed on Post Fiat Task Node, April 2026.