Every grant team eventually notices it is writing the same organizational description for the fifth time and reaches for reuse. The reach is correct; the usual implementation is not. Copying prose from the last proposal drags along that funder’s vocabulary, that program year’s numbers, and framing decisions that were right once, for one reader. The core narrative method moves reuse down one level, from finished sentences to verified facts, so every application starts from current truth and makes its own framing decisions. Candid Learning’s grant proposal guide lists the components nearly every funder asks about; the core narrative is the internal system that keeps your answers to those recurring components accurate between applications.
Core grant narrative outlineSeven fact modules with an ownership header for each, a stable-versus-re-decide note per module, seven staleness triggers mapped to the modules they affect, and the usage rule that keeps application drafts from corrupting the source file.
Markdown templateWhat stays stable, what gets re-decided
The whole method is this table. A fact belongs in the core narrative when it is true regardless of who is asking. A decision belongs to the individual application when the right answer depends on the funder.
| Stays stable in the core | Re-decided per application |
|---|---|
| Legal name, EIN, exempt status, service area | Which facts are relevant to this funder |
| Board-approved mission wording | Emphasis, order, and length of every section |
| Program models: activities, staffing, capacity | Scale of this request and outcomes committed |
| Verified results with data years and methods | Which results to feature, framing of limitations |
| Sourced need figures with geography and year | Which figures build this application’s chain |
| Financial profile, funding mix, audit status | Project budget, request amount, match presentation |
| Community framing standards and consent records | Nothing: standards hold even under funder pressure |
The failure mode on each side is different. Treating a stable fact as flexible produces the proposal that “improves” the annual budget or rounds up last year’s outcomes, which is how organizations drift into claims they cannot report against. Treating a per-funder decision as stable produces the copy-paste proposal, which fails for reasons covered below.
Seven modules with clean boundaries
The downloadable outline defines seven modules: identity and legal facts, organizational capacity, need evidence base, program models (one sub-module per program), results and evidence, financial profile, and community voice standards. The boundary rule that makes them work: a module contains facts with the same owner and the same staleness behavior. Financial facts change on the fiscal-year cycle and belong to the finance lead; need figures change when public sources publish a new year and belong to whoever owns research; program models change when delivery changes and belong to program managers.
Each module carries a four-line header: owner, approver, last-reviewed date, and sources. A module without an owner is a rumor with formatting. The needs statement chain, once its figures are approved, lives in module three; the reconciliation-ready numbers behind your budget live in module six.
The flow from core to application runs one direction, with corrections returning through module owners rather than being made inline.
In words: verified sources feed the approved modules, applications are assembled from the modules through each funder’s requirements map, and anything a draft reveals as wrong or better goes back to the module through its owner. The dashed arrow at the bottom is the review loop: staleness triggers reopen a module regardless of whether an application is in flight.
Staleness triggers, not annual cleanups
A core narrative that is only refreshed when a deadline exposes a stale fact is a liability with a nice filename. The alternative is event-driven review: name the events that invalidate facts, and map each event to the modules it touches.
The outline ships seven triggers: fiscal-year close or completed audit (identity, capacity, financial modules), any leadership or key staff change (identity, capacity, programs), a completed program data cycle (programs, results), a new public data year (need evidence), any change to program design or partners (programs), a funder rejection citing a factual issue (whichever module sourced it), and a hard backstop of twelve months since last review for the whole file. When a trigger fires, the module’s owner repulls from sources and the approver re-dates the header. The grant tracking spreadsheet is the natural place to log trigger dates, since it already tracks the deadlines that make stale facts expensive.
If your team uses AI drafting assistance, the core narrative is also the control that makes it safe to the extent it can be: the model transforms approved module text and is never the source of a fact, a number, or a funder preference. NTEN’s AI resources for nonprofits cover the governance side; the module file is the practical enforcement, because a fact that is not in a module does not go in a draft, whoever or whatever wrote the sentence.
Why copy-paste proposals fail screening
The core narrative pays off most visibly at the two speed-sensitive moments in the pipeline: the letter of inquiry, which becomes an hour’s assembly instead of a day’s writing because every paragraph draws on a current module, and the invited full proposal, which starts from the same fact base as the letter and therefore cannot contradict it. Teams that hire outside help get a third benefit: a maintained module file is the single best onboarding document you can hand a contract writer, and scoping that handoff is half the battle in buying grant writing services well.