Contact the Campaign Desk
One address, and a short description of what the desk can usefully answer. Reading the second list first will save you a reply that only points somewhere else.
How to reach the desk
Write to [email protected]. There is no form on this page, no newsletter, no chat widget and no request for anything beyond the message itself. A subject line naming the note you are writing about gets a faster and more specific answer than one that does not.
What the desk can answer
The notes here cover a defined layer, and questions inside that layer are the ones the desk can actually help with.
- An objective you cannot get into a testable form, and why the rewrite keeps failing.
- A parameter derivation that does not close, where the trade count and the wallet count disagree.
- A pacing curve whose slowest hour will not clear the threshold the objective set.
- A stage gate you cannot phrase as an observation plus an action.
- A report template with a field nobody can fill in without inventing a method.
- A planning question the notes address badly, unclearly, or in only one direction.
What is answered elsewhere
Four subjects come up regularly and none of them is in scope here. Saying so plainly is more useful than a polite non-answer.
| Question | Why it is not answered here |
|---|---|
| Which tool should I use | A purchasing decision. This desk plans campaigns and does not rank products. |
| What does this button do | A property of a specific interface, which changes without notice and is not a planning question. |
| How should I handle keys and funding | An operational security subject with its own literature. Guessing at it here would be worse than silence. |
| Should I build my own | An engineering and cost argument that is independent of what any individual run is for. |
The desk also will not review a specific token, pair or campaign, or estimate what a run will achieve. Both requests ask for a prediction, and every note on this site is built on the position that predictions are not available and plans are.
Reporting an error
Corrections are welcome and are the most useful mail the desk receives. The most valuable kind points at a trade-off stated in only one direction: a parameter where the note explains what breaks when the value is too low and never says what breaks when it is too high. That is the specific failure the format exists to prevent, and it is easier to spot from outside.
Include the page and the passage. If the correction rests on something external, a link to the primary source helps, because the desk would rather link to documentation than assert a fact on its own authority. Corrections are made on the page itself rather than by quietly deleting the passage.
What to expect
Replies are written by the same desk that writes the notes, so they carry the same limits: no promised outcomes, no benchmarks the desk has not measured, and no parameter value handed over without the failure it causes at both ends. A question about what a run will achieve gets an answer about how to make the run markable, which is a different answer and the only one available.
If a question turns out to be a gap in the notes rather than a one-off, it usually becomes a section on the relevant page. That is the main reason the address exists. Reading the about page first will tell you whether your question sits inside the layer this desk works in.