1 Abstract

This exemplar asks whether a reviewable pipeline can hydrate a complete IMRAD manuscript from configuration-owned lexical data while preserving an audit trail that remains readable before and after rendering. The project deliberately keeps playful Mad Lib mechanics inside a serious reproducibility contract: the manuscript shell names large placeholders, the config declares allowable language, and the source code decides what text is emitted.

The committed seed is 431 and the current schema expands 22 slot rule(s) into 40 token choice(s) across 10 lexicon categories. The configured narrative moves are state the manuscript-generation problem, name the deterministic intervention, and summarize the audit surface. The central hypothesis is: Deterministic lexical injection can generate a complete conditional IMRAD manuscript while preserving token provenance, section intent, and audit-ready method evidence.

The result is not a claim that lexical substitution creates scholarship. It is a worked template for conditional manuscript assembly: section enablement, token provenance, figure registration, and unresolved-placeholder checks all become inspectable artifacts before the shared renderer produces PDF, HTML, and slides.

2 Introduction: Lexicon as Data and Manuscript as Build Artifact

Mad Lib style generation is usually treated as a toy because it foregrounds the visible blank rather than the source of the replacement. In a research pipeline, the blank is not the hard part. The hard part is making every replacement reviewable, deterministic, and honest about what it can support. template_madlib turns that constraint into the subject of the exemplar.

The project treats nouns such as pipeline, protocol, section, lexicon and verbs such as hydrate, condition, bind, bind as versioned data. Changing a lexicon entry is therefore closer to changing an input table than editing prose in place. That distinction matters because the generated manuscript can be rerendered, diffed, and validated without asking the reader to trust an invisible drafting session.

The introduction is configured to separate playful Mad Lib syntax from research claims, identify drift between prose and source data, frame configuration as an inspectable dataset, and position conditional prose as a reproducibility problem. Those moves keep the manuscript from pretending to be an open-ended language model. It is a bounded template: authors declare categories, slots, section switches, method steps, and claim boundaries; source code transforms those declarations into manuscript bodies and evidence tables.

This exemplar is useful for protocols, educational scaffolds, review forms, templated reports, and other documents where conditional text is unavoidable but should never become untraceable. The same pattern can be extended with domain-specific validators while leaving the shared rendering infrastructure untouched.

2.1 Contribution Ledger

3 Methods: Source-Owned Token Injection and Conditional IMRAD Assembly

The method is conditional section hydration. Each slot combines the seed, slot name, category, ordinal, and full category list into a SHA-256 digest; the digest indexes the configured category. Including the full category list in the digest input means that a lexicon edit can change the plan in a deterministic and reviewable way instead of silently preserving stale output.

The deterministic digest recipe is deliberately narrow. It does not sample from ambient prose, project history, or renderer state; it uses only the committed seed, the slot declaration, the category name, the ordinal for repeated slots, and the ordered category inventory. A fork can therefore explain a changed token choice as a changed seed, slot, or lexicon row rather than as an opaque generation event.

The first review scenario is declared before generation. The project names its scope as a local exemplar, records enabled sections, keeps DOI and publication claims blank, and treats the copy stage as a review handoff. That ordering matters because a reader should know the allowed claim boundary before inspecting fluent generated text.

The governing constraint is publication claims stay local until release. The source manuscript is intentionally sparse: it contains section titles and large-grain placeholders, not generated claims. The project script first validates the madlib: block, expands slots into a TokenPlan, builds section bodies, writes artifact JSON, emits a figure registry, and only then writes hydrated Markdown under output/manuscript/.

The configured method moves are validate config before composition, declare review scenario and method invariants, separate explicit YAML fields from loader defaults, govern lexicon categories as reviewable data, expand slots through seeded digest selection, allocate slot choices to enabled manuscript sections, compose conditional section bodies, assemble method evidence tables and visual audit figures, align generated claims with the claim ledger, emit evidence artifacts before rendering, verify that no unresolved placeholders remain, assemble a reviewer packet from regenerated artifacts, and preserve human review before publication claims. The protocol sequence is Ingest declared manuscript schema produces MadlibConfig; Declare review scenario produces review scenario; Track field origin produces explicit/default path inventory; Govern lexicon categories produces validated lexicon; Construct digest selection material produces digest input records; Record selection invariants produces selection invariant set; Expand slot declarations produces TokenPlan; Apply section conditions produces enabled section set; Compose conditional IMRAD bodies produces section variables; Assemble evidence tables produces Markdown evidence tables; Align claims with evidence ledger produces claim-aligned evidence surface; Generate visual audit surface produces registered figure set; Emit machine-readable artifacts produces output/data, output/reports, and output/figures; Hydrate manuscript shell produces output/manuscript; Render and validate deliverables produces validated project output; Assemble reviewer packet produces review packet; Copy review surface produces copied publication-review bundle; Document fork migration produces fork migration notes. These steps make the method auditable from three directions: tests inspect the Python behavior, generated artifacts expose the token plan, and manuscript validation confirms that no unresolved placeholder survives into rendered outputs.

The config-origin inventory currently separates 125 explicit YAML path(s) from 11 loader-defaulted path(s). Treating origin as method evidence prevents a rendered field from looking equally authored when it was actually inherited from the loader. The same inventory drives configured-field tables and figures, so reviewers can inspect which schema blocks were intentionally set before judging the generated prose.

Method invariants are reviewed as their own artifact. Token choices are allowed to change when the seed, slot name, category, ordinal, or ordered category inventory changes; they are not allowed to change because PDF rendering, HTML rendering, file-copy order, or hand-edited output changed. This separates generation logic from presentation logic.

Lexicon governance is handled as data governance. Required categories must be nonempty, optional categories remain project-owned when declared, and the selected 40 token choice(s) stay bound to 10 configured category list(s). The slot-to-section allocation is abstract: 3, authoring_contract: 2, configuration: 1, discussion: 3, evaluation: 5, introduction: 8, limitations: 3, methods: 6, reproducibility: 2, results: 5, scope: 2, which lets the Methods, Results, and provenance tables state where each lexical decision enters the manuscript.

Conditional section generation is handled before prose assembly. A disabled section does not vanish and does not borrow claims from an enabled section; it resolves to an explicit statement that names the controlling madlib.section_conditions key. That behavior keeps negative or excluded material visible to reviewers.

Evidence tables and visual audit figures are generated from the same config and TokenPlan. Enabled visualizations are configured_field_matrix, section_configuration_heatmap, field_origin_summary, token_injection_flow, section_token_allocation, provenance_trace_map, quality_gate_matrix; they summarize field origin, token density, injection flow, section allocation, provenance, and quality gates without adding independent claims. Figure registration is therefore a method step: every manuscript image has to be written, registered, and validated as part of the reproducible render path.

Claim-ledger alignment is part of composition. The contribution table can make local method claims, but publication, empirical, reader-quality, and domain-specific claims must either point to evidence or remain explicit non-claims. This is why the claim ledger, audit rules, limitations, and authoring contract are generated beside the Methods rather than written after the fact.

Evaluation is part of the method rather than an afterthought. The config declares quality probes (Method row completeness, Field-origin visibility, Placeholder survival, Provenance completeness, Section-switch observability, Figure registry coverage, Method-figure alignment, Evidence cleanliness, Fork readiness, Copied-output parity, Digest invariant review, Claim-ledger alignment, Review packet completeness, Fork migration sufficiency) and failure modes (Unresolved placeholder, Overclaimed generated prose, Config-source drift, Figure provenance gap, Domain misuse, Method row drift, Field-origin opacity, Visual-method mismatch, Fork without validators, Digest invariant drift, Claim ledger omission, Review packet incompleteness, Fork migration ambiguity); the source turns them into tables and validation checks the rendered surface. That means methods, results, evaluation, and limitations all share one source-owned schema instead of drifting as independent prose.

The method is organized around design principles: Configuration owns prose choices, Method surface is config-owned, Token choice is deterministic, Field origin is evidence, Sections are conditional but visible, Visual audit follows data, Generated output is disposable, Claim boundaries travel with prose, Forks must add validators, Invariants precede rendering, Diffs are review objects, Review packet is a method artifact, Fork migration is part of the method. These principles prevent the Mad Lib surface from becoming a hidden authoring channel. They require the visible manuscript to stay downstream of declared inputs, the generated outputs to remain disposable, and the audit surface to be broad enough for a reviewer to reconstruct how a sentence reached the PDF.

The operational phases are Schema intake maps manuscript/config.yaml to MadlibConfig; Scenario declaration maps MadlibConfig to review scenario; Field-origin inventory maps MadlibConfig and raw YAML keys to configured_field_inventory.json; Lexicon validation maps madlib.lexicon and madlib.slots to validated slot inventory; Digest token planning maps MadlibConfig to TokenPlan; Invariant review maps TokenPlan and method protocol to selection invariant set; Slot-to-section allocation maps TokenPlan to section token counts; Section composition maps TokenPlan and narrative moves to manuscript variable map; Evidence table assembly maps MadlibConfig and TokenPlan to manuscript_variables.json; Claim-ledger alignment maps MadlibConfig, generated prose, and data/claim_ledger.yaml to claim-aligned evidence surface; Visualization emission maps MadlibConfig, TokenPlan, and configured-field inventory to output/figures and figure_registry.json; Artifact emission maps MadlibConfig and TokenPlan to output/data, output/reports, and output/figures; Manuscript hydration maps source manuscript shells and manuscript_variables.json to hydrated Markdown manuscript; Render maps output/manuscript to output/pdf, output/web, and output/slides; Validate and copy maps project output directories to output/templates/template_madlib; Review packet assembly maps validated project output and copy statistics to review packet; Fork contract documentation maps source docs, authoring contract, and claim ledger to fork migration notes. Each phase has an explicit input, transformation, output, and guard. This makes the pipeline explainable at manuscript scale: a reader can follow the path from YAML declarations to token choices, from token choices to section bodies, from section bodies to rendered artifacts, and from rendered artifacts to validation reports.

The reviewer packet is also a method artifact. The handoff surface is hydrated Markdown, combined PDF, web output, slides, figures, data JSON, reports, validation results, and copy statistics; a PDF alone is insufficient because it cannot show the token inventory, field-origin inventory, figure registry, validation report, or copied-output statistics. The declared authoring obligations are Review generated claims, Review config diffs, Extend claim evidence, Add domain validators, Rerun the full project path, Review method invariants, Assemble reviewer packet, Write fork migration notes, which convert that packet into review work a human can actually perform.

The claim-boundary contract is also generated. The audit-rule list contains 12 rule(s), and the contribution table binds each local claim to a non-publication boundary. The final copy stage is a human-review handoff, not proof that the Mad Lib surface is empirically valid or ready for a standalone release.

Fork migration closes the method. A downstream project should update config rows, source-owned composition, validators, claim-ledger entries, and documentation before replacing exemplar vocabulary with domain claims. Without that migration work, the fork has only changed words, not the evidential status of the generated manuscript.

3.1 Design Principles

3.2 Operational Phases

3.3 Protocol Steps

3.4 Section Plan

3.5 Audit Rules

4 Results: Provenance, Density, and Resolved Manuscript Surface

The generated plan enables 11 of 11 manuscript sections and fills 40 token choice(s). Category density is adjectives: 2, artifacts: 8, audiences: 4, constraints: 3, failures: 3, measures: 6, methods: 1, nouns: 5, qualities: 3, verbs: 5. The result figures are generated from the same token plan that writes the inventory table, so visual and tabular claims share one source.

The configured results moves are report token density, show resolved section coverage, bind every manuscript token to provenance, and connect the figure and inventory to the same plan. The important result is therefore not a surprising word choice; it is the survival of traceability through a complete render path. Each token row records the variable, category, selected value, section, and config pointer that produced it.

The resolved manuscript also demonstrates the intended failure boundary. If a manuscript placeholder is added without a corresponding variable, the project test suite detects it. If a figure is referenced without registry support, the output validator reports it. If a generated number lacks evidence support, the evidence registry gate reports it before the copied output stage packages deliverables.

Visualization is enabled for configured_field_matrix, section_configuration_heatmap, field_origin_summary, token_injection_flow, section_token_allocation, provenance_trace_map, quality_gate_matrix. The configured-field figures are generated from the same explicit/default path inventory written to JSON; the pipeline, allocation, provenance, and gate figures are generated from the same token plan and QA schema.

4.1 Token Inventory

4.2 Provenance Matrix

5 Discussion: Accountability Boundaries for Generated Prose

The reviewable result is intentionally modest. The exemplar does not claim that random lexical replacement creates scholarship, discovers facts, or substitutes for authorship. It shows that a conditional text generator can be made accountable to configuration, tests, and render-time validation.

The configured discussion moves are bound the scholarly claim, describe useful adaptation cases, name misuse modes, and preserve human authorship responsibility. Useful adaptations include templated empirical reports, structured review memos, classroom exercises, and manuscript sections that need to toggle across protocols. Risky adaptations include hiding weak claims behind fluent generated phrasing or allowing a token category to imply evidence that the project never produced.

The pattern scales only when authors preserve the same ownership boundary. Lexicons should be small enough to review, categories should be named for their manuscript function, and section switches should state what has been removed. When richer language is needed, the next layer should add domain-specific validators rather than relaxing provenance.

6 Configuration: Schema-Controlled Lexicon, Slots, and Narrative Moves

The active composition depth is deep. The lexicon exposes 10 category list(s), and the slot declaration expands to 40 concrete token choice(s). Section switches are evaluated before composition so disabled sections cannot silently borrow enabled-section claims.

Configuration owns more than vocabulary. It also owns section titles, narrative moves, method protocol rows, contribution claims, and audit rules. That makes the manuscript shape visible in one YAML file while preserving the rule that source code, not hand-edited output, performs the composition.

The tables in this section expose the declared surface that controls rendering. They are useful during review because a title change, slot expansion, or disabled section appears as a small config diff and a regenerated artifact diff rather than as scattered prose edits.

The configured-field inventory separates 125 explicit YAML path(s) from 11 loader-defaulted path(s). That distinction matters for forks: a field that appears in the rendered manuscript may be intentionally authored in config.yaml, or it may be a documented default inherited from the template.

6.1 Declared Section Titles

6.2 Configuration Counts

• Seed: 431
• Composition depth: deep
• Lexicon categories: 10
• Slot rules: 22
• Token choices: 40
• Enabled sections: 11
• Method steps: 18
• Design principles: 13
• Pipeline phases: 17
• Quality probes: 14
• Authoring obligations: 8
• Explicit configured paths: 125
• Defaulted configured paths: 11
• Enabled visualization flags: 7
• Section-level configured paths: 33
• Lexicon-level configured paths: 10
• Slot-level configured paths: 66
• Narrative moves: 52
• Audit rules: 12
• Contribution claims: 9

6.3 Configured Field Summary

6.4 Configured Field Inventory

7 Evaluation: Gate Criteria, QA Probes, and Failure Discovery

The evaluation section is configured to name readiness criteria, connect criteria to artifacts, separate local checks from publication readiness, and make failure probes visible. The local readiness surface is not a human preference score; it is a set of deterministic checks that connect generated manuscript claims to source files and pipeline gates.

The active criteria use analysis, copy, pytest, validation as gate labels and inspect artifacts such as token-injection flow, quality-gate matrix, configured-field figures. A passing run means the exemplar is locally render-ready: placeholders resolve, token provenance is present, figure references are registered, evidence scanning has not found unsupported numbers, and project design overlays remain internally consistent.

That readiness is deliberately narrower than publication readiness. A local pass does not imply a standalone DOI, external release, reader preference result, or empirical validation. It means the tracked project tree can regenerate the committed artifact surface through its declared pipeline.

The QA probes are Method row completeness, Field-origin visibility, Placeholder survival, Provenance completeness, Section-switch observability, Figure registry coverage, Method-figure alignment, Evidence cleanliness, Fork readiness, Copied-output parity, Digest invariant review, Claim-ledger alignment, Review packet completeness, Fork migration sufficiency. They are phrased as questions so they can be reused by reviewers and by forks of the exemplar: did the placeholder disappear, did the provenance survive, did the figure registry cover every reference, and did copied outputs preserve the same evidence surface that validation inspected?

7.1 Evaluation Criteria

7.2 Quality Probes

8 Reproducibility: Seeded Regeneration and Artifact Trace

Re-running generation with seed 431 and the same lexicon produces the same token plan. The artifact set records token_inventory.json, section_plan.json, injection_trace.json, manuscript_variables.json, figure_registry.json, and the cover/results/configuration/evaluation figure set so the manuscript can be audited without reading the PDF.

The protocol emits MadlibConfig, review scenario, explicit/default path inventory, validated lexicon, digest input records, selection invariant set, TokenPlan, enabled section set, section variables, Markdown evidence tables, claim-aligned evidence surface, registered figure set, output/data, output/reports, and output/figures, output/manuscript, validated project output, review packet, copied publication-review bundle, fork migration notes. Project tests cover deterministic token choice, seed sensitivity, category-input sensitivity, malformed config rejection, section disablement, artifact writing, and unresolved manuscript-token detection. The shared output validator then checks rendered PDFs, Markdown, figure registry, evidence registry, and design overlays.

The copied root output is therefore a consequence of local source and config. Generated files remain disposable; the durable contract is the ability to regenerate them from the tracked project tree and to observe the same validation gates passing.

• Config hash: 3c4268ae54c35130
• Generated: 2026-06-26T14:00:22Z
• Python: 3.12.13
• Platform: Darwin arm64

9 Limitations: Non-Claims, Misuse Modes, and Human Review

The limitations section is configured to state non-claims, identify misuse modes, preserve human review, and require domain validators for domain claims. The central limitation is that deterministic token injection can make manuscript assembly auditable, but it cannot make a weak claim true or a missing source appear.

The declared failure modes are Unresolved placeholder, Overclaimed generated prose, Config-source drift, Figure provenance gap, Domain misuse, Method row drift, Field-origin opacity, Visual-method mismatch, Fork without validators, Digest invariant drift, Claim ledger omission, Review packet incompleteness, Fork migration ambiguity. They are included in the manuscript because this template is meant to teach the boundary, not hide it. A useful fork should extend this table when it adds domain-specific claims, validators, or publication targets.

The author remains responsible for theory, citations, reader expectations, and domain evidence. The generator can enforce structure and provenance; it cannot supply judgment. That division is the main safety property of the exemplar.

9.1 Failure Modes

10 Scope: Related Generators and Responsible Forking

The exemplar is a pipeline testbed, not a natural-language quality benchmark. It covers deterministic token selection, conditional section bodies, section-title injection, provenance tables, and generated evidence artifacts. It does not evaluate semantic originality, factual truth beyond the local configuration, or reader preference.

The configured scope moves are distinguish generation from truth, limit publication claims, point to local evidence, and explain responsible forking. The closest related systems are not general-purpose chatbots but source-owned report generators, literate-programming documents, static-site data templates, and reproducible manuscript pipelines. template_madlib contributes a deliberately small version of that idea for research manuscripts.

Publication metadata remains conservative. The local CITATION.cff, .zenodo.json, and codemeta.json describe this exemplar inside the shared template repository; they do not claim a live standalone DOI, external release, or empirical validation outside the generated local artifacts.

11 Authoring Contract: Human Review and Forking Obligations

The authoring contract is configured to state human responsibilities, name fork obligations, connect review to generated evidence, require domain validators before domain claims, and document fork migration notes. It addresses pipeline maintainers directly because the generator can preserve structure, provenance, and reviewability, but it cannot decide what a field should claim. Human authors remain responsible for theory, interpretation, citations, and the choice to publish.

The declared obligations are Review generated claims, Review config diffs, Extend claim evidence, Add domain validators, Rerun the full project path, Review method invariants, Assemble reviewer packet, Write fork migration notes. They convert responsible use into a checklist: review generated claims in the hydrated manuscript, inspect the generated evidence tables, extend the claim ledger when new claims appear, and add domain-specific validators before the template is used for a real empirical or theoretical manuscript.

The quality standard is claim humility. A fork that only changes words has not preserved the exemplar. A responsible fork changes the config, adjusts source-owned composition where necessary, regenerates artifacts, and reruns the same tests and validation gates before treating the output as reader-ready.

11.1 Authoring Obligations

12 References