The Fountain Manifest

1. The Problem With the Monofile

Fountain is not the problem. Its value comes from being simple, portable, human-readable plain text. The practical limitation appears when an entire feature screenplay must be maintained as one very large text file.

Writers think in scenes, sequences, acts, and revisions. A filesystem, Git repository, search tool, or analysis tool normally sees one large document. Local edits occur inside that document; version-control diffs are less focused; parallel project work is more likely to collide; and analysis repeatedly processes pages irrelevant to the task at hand. Individual scenes have no natural filesystem identity, so attaching notes or project metadata to them becomes awkward.

A traditional single Fountain file remains useful and valid. The Fountain Manifest is an optional working representation for projects that benefit from more explicit structure.

2. Scene-Level Fountain

The screenplay is divided into ordinary .fountain files, usually one per scene:

screenplay/
|-- manifest.json
|-- scenes/
|   |-- 001.fountain
|   |-- 002.fountain
|   |-- 003.fountain
|   `-- ...
`-- build/
    `-- screenplay.fountain

Every scene file remains readable Fountain text. This is not a replacement screenplay syntax. Scene files are the convenient working source; a conventional monolithic screenplay is generated whenever it is needed for screenplay applications, interchange, pagination, PDF generation, or distribution.

3. The Manifest

Once scenes live in separate files, their ordering is no longer implicit in one document. The manifest supplies that ordering. A deliberately minimal version might look like this:

{
  "title": "Example Screenplay",
  "format": "fountain-manifest",
  "version": 1,
  "scenes": [
    "scenes/001.fountain",
    "scenes/002.fountain",
    "scenes/003.fountain"
  ]
}

A richer implementation may associate stable identifiers and useful metadata with scenes. That is an extension, not a requirement of the basic idea.

4. Workflow

1. Write and revise individual scene files.
2. Use the manifest to determine screenplay order.
3. Reorder scenes structurally instead of cutting and pasting large sections.
4. Maintain metadata alongside stable scene identities where useful.
5. Run a small build process.
6. Produce a standard monolithic .fountain screenplay.

       SCENE FILES
            |
            | described and ordered by
            v
         MANIFEST
            |
            | build
            v
   SCREENPLAY.FOUNTAIN

The generated screenplay remains compatible with the ordinary Fountain ecosystem.

5. Benefits and Utility

The main benefit is easier management without changing how the screenplay is written. A project can address the scene or sequence relevant to a task instead of treating a feature screenplay as one indivisible textual object.

This fits source control particularly well. In Git, a scene revision appears as a change to one small file rather than an edit somewhere inside a hundred-page document. Additions, deletions, and revisions produce clearer history, and parallel work is less likely to create unnecessary conflicts.

Explicit scene structure also provides a basis for project-wide search, character and location reports, continuity analysis, revision comparisons, sequence organization, alternate cuts, production reports, screenplay statistics, and links between research or notes and specific scenes. These tools can operate around the screenplay without moving its content into a proprietary database.

Most importantly, the writer is not locked into custom software. The complete screenplay can always be rebuilt as a conventional single .fountain file.

Keep the screenplay human-readable, make its structure explicit, and let software handle the repetitive work of assembling, indexing, searching, and analyzing it.

6. Automation and Agentic Assistance

The screenplay remains authored by the writer. Automation and agentic tools are useful here for project management, retrieval, organization, metadata, navigation, analysis, and mechanical operations around the work. A structured repository gives software a reliable model of the project.

A tool could find scenes involving a character or location; collect a sequence; locate references to an object; compare metadata across revisions; produce character reports; trace where a plot element is introduced and later referenced; summarize structural changes between commits; associate research with scenes; check for incomplete metadata; assemble the screenplay; or retrieve relevant material when the writer asks a project question.

The manifest makes this deterministic instead of requiring software to rediscover the screenplay’s organization on every pass. Selective retrieval can also make assisted analysis more practical by locating relevant scenes rather than loading the entire screenplay indiscriminately.

Scenes do not exist independently, of course. Setup, payoff, continuity, character development, and information from elsewhere still matter. Project structure and search allow that context to be found deliberately.

7. Metadata Without Polluting the Screenplay

A stable scene identity gives tooling somewhere to associate sequence or act, characters present, location, timeline information, production notes, revision state, research references, and organizational tags. None of this requires a large mandatory schema.

The architectural point is separation of concerns: screenplay text remains screenplay text; project metadata can live around it. Metadata may become richer over time without making the Fountain source increasingly complicated.

8. Design Principles

The goal is not to make screenwriting behave like programming. It is to borrow the parts of software development that are unusually good at managing large, changing bodies of plain text.

9. What This Enables

Applications built around this structure might include scene indexes, character appearance reports, location reports, continuity tools, semantic search, revision summaries, sequence views, alternate cuts, metadata browsers, research linking, and production-oriented reports. These are examples, not required parts of a Fountain Manifest specification.

The center of the architecture stays deliberately boring and durable: folders, text files, Fountain, and a small manifest. More sophisticated software can be layered around those materials without becoming necessary to read or preserve the screenplay.