Skip to content

[EPIC][Artifact Forest] Build truthful screenplay, transcript, and exhaustive derivative workflows #421

Description

@szmyty

Outcome

Make Renderflow capable of taking one artifact and producing a truthful, bounded derivative forest across high-value formats without recursive conversion loops, duplicate outputs, or silent information loss.

This epic closes a gap exposed by the current format model: formats such as Fountain are represented in the v2 graph/capability registry, but the normal execution path and provider ecosystem do not yet make the screenplay family fully executable.

It also adds the transcript/subtitle side needed by media and comic-production workflows, while preserving the ownership boundary that Aniflow owns temporal media workflows and Flow owns cross-tool orchestration.

Product model

A source artifact should be able to request a policy such as "everything valid for this source" and receive each eligible derivative once.

Example:

screenplay.fountain
        │
        ├──→ screenplay.fdx
        ├──→ screenplay.fadein
        ├──→ screenplay.osf
        ├──→ screenplay.json
        ├──→ screenplay.pdf
        └──→ screenplay-report.json

The source format is not regenerated by default.

A different source may enter through a lossy recovery path:

screenplay.pdf
        ↓
text/layout extraction
        ↓
screenplay recovery assessment
        ↓
screenplay intermediate
        ├──→ fountain
        ├──→ fdx
        ├──→ fadein
        └──→ osf

The recovered screenplay must remain explicitly derived/lossy and may require review. Renderflow must never claim PDF → Fountain round-trip fidelity.

For media:

video/audio
   ├──→ existing embedded subtitle streams
   └──→ speech transcription
            ↓
      timed transcript
       ├──→ srt
       ├──→ webvtt
       ├──→ json
       └──→ text

Core planner rule: derivative forest, not recursive graph traversal

The transformation graph may contain cycles such as Fountain ↔ FDX. Exhaustive execution must therefore be target-oriented rather than edge-recursive.

The planner must:

  • compute eligible target formats/capabilities from source + profile + available providers;
  • produce each requested target identity at most once;
  • exclude source-format identity unless explicitly requested;
  • use simple paths without repeated format nodes;
  • rank competing paths by explicit policy;
  • record information-loss/fidelity transitions;
  • stop at unsupported/unavailable/provider-blocked targets without inventing success;
  • avoid deriving a target from another derivative when a higher-fidelity source path is available;
  • preserve exact lineage and selected-provider evidence.

Initial provider candidates

Evaluate as external command providers; do not vendor or link copyleft implementation into Renderflow core.

  • scripttool — FDX/FadeIn/OSF ↔ Fountain plus Fountain → JSON/reporting surface.
  • afterwriting-labs / afterwriting CLI — Fountain → formatted PDF and screenplay analysis/statistics.
  • Poppler/pdftotext or equivalent — deterministic PDF text extraction candidate.
  • Tesseract — OCR fallback for image-only/scanned script pages, already represented in the tool ecosystem.
  • FFmpeg/ffprobe — embedded subtitle discovery/extraction and subtitle conversion where proven.
  • whisper.cpp or another reviewed local-first provider — speech-to-timed-transcript candidate.

Provider adoption requires current version/license/maintenance/runtime evaluation, bounded direct-argv execution, capability declarations, validation, fixtures, and provenance.

Comic-production relevance

Comics and narrative projects should be able to retain a script artifact alongside visual pages and release products.

Do not pretend screenplay formats preserve comic-specific panel/page semantics losslessly. A later comic-script profile may project canonical comic page/panel/dialogue/caption data into a screenplay-compatible representation, with explicit loss metadata.

The immediate goal is to make Fountain and related script artifacts first-class derivatives so Flow can later request an expansive artifact forest when finalizing a project.

Cross-tool boundary

  • Renderflow: static artifact detection, conversion, extraction, screenplay/subtitle/transcript schemas, provider adapters, validation, derivative planning, provenance.
  • Aniflow: temporal segmentation/reconstruction and advanced media workflow ownership.
  • Flow: orchestrates released Renderflow/Aniflow capabilities into project-level runs, checkpoints, resumability, policy, and final artifact forests.
  • Content repositories: own canonical creative source and approval.

Completion

This epic closes only after its checkpoint issues produce:

  • cycle-safe derivative-forest planning;
  • truthful screenplay format execution;
  • Fountain/FDX/FadeIn/OSF provider-backed conversions;
  • screenplay PDF/report generation;
  • bounded PDF/script recovery;
  • subtitle extraction/conversion;
  • local speech transcription;
  • machine-readable capability truth and fixtures;
  • one integration fixture demonstrating a multi-family artifact forest;
  • roadmap and downstream Flow handoff updates.

No network publication, source mutation, creative approval, or sibling-source import belongs here.

Checkpoint roadmap

Dependency shape

#422 graph policy ─────────────────────────────────────────────┐
                                                              │
#423 screenplay model                                         │
 ├──→ #424 scripttool ───────────────┐                        │
 ├──→ #425 afterwriting ─────────────┤                        │
 └──→ #426 PDF/text recovery ────────┤                        │
                                      │                        │
#427 timed text ──→ #428 transcription│                        │
                                      ├──→ #429 toolchain ─────┤
                                      │                        │
                                      └────────────────────────┴──→ #430
                                                                  Flow handoff

#422 and #423 may begin in parallel. #427 may also proceed independently.
#429 is a consolidation checkpoint, not a reason to block adapter implementation.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions