Priority intelligence requirement
The highest-level question tied to a customer decision.
Tasking, contracts, and cut-outs
A mission marker is not
an intelligence requirement.
Tasking defines who needs the information, what decision it supports, what may be collected, what must be protected, when the answer is due, and how the result must be delivered.
Intelligence requirement
The operation starts
with a decision to support.
Good tasking is specific enough to guide collection and open enough to permit competing explanations.
The authority identifies the customer, decision, priority, deadline, geography, subjects, information gaps, reporting format, confidence threshold, and restrictions. The cell can then choose roles and disciplines instead of treating every problem as a field infiltration.
Tasking layers
One requirement becomes
a coordinated collection plan.
Information requirements
Specific gaps that must be answered to support the judgment.
Collection tasks
Role- and discipline-specific work assigned to sources, sensors, teams, and partners.
Reporting instructions
Format, channel, urgency, classification boundary, provenance, and handling requirements.
Validation plan
Corroboration, alternate hypotheses, deception checks, and thresholds before action.
Debrief and retasking
What changed, which gaps remain, and what the next cycle should collect.
Operational relationships
Not every participant
sees the whole assignment.
Compartmentation turns one operation into different contracts. A source may know only the requested observation. A courier may know only the handoff. A liaison may know the partner requirement. The case officer and analyst reconnect the fragments.
Collect within actual access
Source motivation, reliability, protection, and reporting history travel with the report.
Separate parties and knowledge
Move messages or material while limiting exposure of customer, source, and method.
Preserve chain of custody
Transport a server-tracked package or record between authorized handoff points.
Translate partner requirements
Control releasability, attribution, source protection, and shared operational context.
Perform bounded specialist work
Accept a defined task, authorities, limits, reporting method, and settlement rule.
Own continuity and consequence
Ensure the fragments answer the requirement without exposing the entire network.
VERIFIED TASKING
Server-owned conditions.
The authority or issuer locks the reward, the task conditions are machine-readable, and completion is settled by deterministic game state. The player pays fees or accepts tighter constraints in exchange for certainty.
- Requirement and acceptance logged.
- Reward cannot disappear after completion.
- Changes create a visible amendment or cancellation consequence.
- Evidence and delivery state remain auditable.
UNVERIFIED TASKING
Relationship-owned conditions.
Off-book work relies on reputation, source history, personal trust, and negotiated terms. The system labels the risk clearly rather than pretending the contract is guaranteed.
- No invisible promise of state enforcement.
- Issuer and source history remain visible when available.
- Betrayal risk is explicit before acceptance.
- Operational consequences persist in reputation and future access.
Deep research links
Tasking, trust, and courier-system research.
The archived work includes broader economy and contract analysis. The live page extracts the portions relevant to intelligence requirements, trusted settlement, cut-outs, and evidence continuity.
FULL REPORT
Trust, Deception, and Virtual Economies
Verified and unverified work, reputation signals, and explicit betrayal boundaries.
→
FULL REPORT
Trustless Escrow and Courier Contracts
Deterministic contract states, chain of custody, and accessible handoff design.
→
FULL REPORT
Courier Contract Mechanics
Operational logistics, settlement, anti-scam controls, and physicalized package design.
→
