mathfin-writing-style

Writing Style (mathfin-writing-style)

When to trigger

• The proofs are correct but the paper is hard to read
• The introduction states results without financial modelling intuition
• Definitions, assumptions, theorem numbering, or appendix references are inconsistent

Style principles

• Define before use. Probability space, filtration, admissible strategies, integrability, market model, and payoff objects must be explicit.
• Number assumptions and results. Reuse labels consistently.
• State theorem scope precisely. Hypotheses and conclusions should be visible without searching prose.
• Separate intuition from proof. Give financial meaning before technical proof, then keep the proof self-contained.
• Use appendices deliberately. Put long derivations there while keeping the main text focused on result, intuition, and modelling payoff.

Theorem paragraph pattern

Under Assumptions (A1)-(A3), Theorem 2.1 establishes [formal result]. In financial
terms, this means [pricing/hedging/risk/portfolio interpretation]. The proof
combines [main tools] and is given in [location].

Proof hygiene

• Check local martingale versus true martingale claims.
• State integrability and measurability conditions.
• Do not cite a theorem without verifying its hypotheses.
• Avoid "straightforward" for load-bearing steps.
• Keep notation stable across the main text and appendix.

Symbol conventions the readership expects

Object	Conventional usage	Drift to avoid
Filtration	(F_t) with the usual conditions stated once	switching between F_t and F(t)
Physical / pricing measure	P / Q (or Q^*)	reusing Q for a generic measure mid-paper
Brownian motion	W under P; W^Q after Girsanov	the same W under both measures without comment
Admissible strategies	A or A(x), x the initial wealth	"admissible" used before A is defined
Wealth / value process	X^pi or V	V doubling as value function and value process
Value function	v(t,x), lowercase	v and V swapped between sections
Stopping times	tau, ranging over a defined family T_{t,T}	tau ranging over an unspecified set
Generator	L (or L^a in control problems)	applying L to functions outside its stated domain

Proof-sketch scaffold

Before each long proof, give a three-to-five sentence sketch:

The proof proceeds in three steps. Step 1 establishes [a priori estimate] under (A2), which
yields the uniform integrability needed later. Step 2 constructs the candidate [object] via
[tool: Snell envelope / dual problem / fixed point]; this is where the new idea, [one phrase],
enters. Step 3 verifies optimality and uniqueness by [verification argument]. Steps 1 and 3
are standard given Step 2 and are deferred to Appendix B.

The sketch tells a referee where the novelty lives and which parts may be verified quickly — exactly the separation of new idea from routine verification that this journal's culture prizes.

Sentence-level habits for stochastic-analysis prose

• Quantify every "small", "sufficiently regular", or "for t large" with a displayed condition.
• Write "P-a.s." or "for Lebesgue-a.e. t" — never leave the null-set sense ambiguous.
• Prefer "By Theorem 2.3 of [X], whose hypotheses hold by (A1) and Lemma 3.2," to a bare citation.
• Keep proofs in one tense (present), and let displayed equations carry the algebra, not prose.

Notation ledger

Before polishing prose, create a notation ledger with columns for symbol, object, first definition, assumptions, theorem use, and appendix use. Use it to find:

• one symbol used for multiple objects;
• objects introduced only inside proofs but needed in theorem statements;
• filtrations, measures, admissible sets, or payoff spaces that change silently;
• assumptions cited in prose but absent from the theorem statement;
• appendix notation that no longer matches the main text after revision.

Mathematical Finance readers will forgive technical density more readily than notation drift. A clean ledger also shortens referee response time because every objection can be tied to a labelled object.

Output format

[Section] intro / model / theorem / proof / numerics / appendix
[Main clarity issue] ...
[Formal precision fix] ...
[Financial intuition fix] ...
[Next step] mathfin-submission