Skip to content

Readme.md

Latest commit

 

History

History
544 lines (433 loc) · 21.5 KB

Readme.md

File metadata and controls

544 lines (433 loc) · 21.5 KB

FROG logo

FROG Roadmap

Non-normative planning layer for the progressive closure of FROG as a language, conformance surface, reference path, compiler corridor, runtime path, deployment path, and future IDE ecosystem
FROG — Free Open Graphical Language

Roadmap start date: 8 March 2026

Contents

1. Project map at a glance

FROG closure sequence

canonical .frog source
        |
        v
loadability
        |
        v
structural validation
        |
        v
validated language meaning
        |
        v
standardized FROG execution IR
        |
        v
backend-specific lowering
        |
        v
backend contract / consumable handoff
        |
        v
runtime or compiler/backend realization
        |
        v
deployable artifact


in parallel

authoring
   -> Program Model
   -> graphical IDE
   -> validation feedback
   -> observability / debugging
   -> reusable industrial workflow


project logic

semantic closure
   -> schema / validation closure
   -> conformance closure
   -> reference execution proof
   -> backend credibility
   -> IDE credibility
   -> ecosystem credibility

This roadmap explains the intended closure order. It does not replace Expression/, Language/, IR/, Libraries/, Profiles/, IDE/, or any other normative ownership layer.

2. Purpose of this roadmap

This roadmap exists to track the planned closure path of FROG as a full long-term ecosystem effort. It is a planning layer inside the repository, not the source of normative language truth.

Its practical purpose is to answer one project question:

What sequence of concrete closures must be completed to move from the currently published FROG baseline to a serious open graphical programming ecosystem with a credible compiler/runtime path, credible deployment depth, a serious future IDE, and a credible open industrial language position?

That distinction matters:

  • the specification layers define what FROG is,
  • the roadmap layer defines in what order the project should be closed.

The roadmap also exists to keep the project disciplined. It helps ensure that strategic ambition does not outrun technical closure, and that new fronts are not opened faster than the current architectural corridor is stabilized.

3. What this roadmap is and is not

What it is

  • a sequencing layer,
  • a closure plan,
  • a milestone map,
  • a prioritization surface for technical and ecosystem work,
  • a public statement of closure order for the repository-visible corridor.

What it is not

  • not the normative language definition,
  • not the source of semantic truth,
  • not a substitute for Expression/, Language/, IR/, or Profiles/,
  • not a place where implementation convenience becomes language law,
  • not a place where strategy prose silently replaces technical closure,
  • not a place where current corpus-version truth is declared,
  • not Graiphic's proprietary product implementation plan,
  • not a claim that all future phases are already stabilized.

References to runtime, deployment, IDE, or ecosystem maturity in this roadmap describe public specification, conformance, and bounded reference-corridor sequencing. They do not require Graiphic production runtime or FROG Studio implementation work to be developed inside this public repository. The public reference runtime material in this repository currently stops at Example 15; runtime development for later examples continues in Graiphic's proprietary Graiphic/FROG-Runtime repository unless explicitly promoted later.

Graiphic internal task planning, runtime implementation sequencing, IDE product planning, validation recipes, and agent coordination are maintained outside this public repository. Public roadmap entries should therefore be read as specification and ecosystem closure guidance, not as Graiphic's internal execution board.

4. Relationship with Versioning

The roadmap and the versioning surface answer different questions and must remain distinct.

Surface Main question What it must not replace
Roadmap/ In what order should FROG be closed? Current corpus-version truth or per-surface current-status reporting
Versioning/Readme.md What is the current published specification corpus version, and what is the cross-version doctrine? Closure sequencing
Versioning/Matrix.md What is the current detailed status of each major repository surface? Milestone ordering or long-term planning logic

This means:

  • the roadmap states what should be closed next,
  • the versioning surface states what is currently published and how version truth is governed.

When a reader wants to know the current published corpus version or the current detailed repository-wide status table, the authoritative repository-visible entry points are:

  • Versioning/Readme.md,
  • Versioning/Matrix.md.

This roadmap may refer to those files, but it must not duplicate their role.

5. Status legend

  • [x] completed or already established in the published baseline
  • [~] partially established, active, or not yet fully closed
  • [ ] planned future work

6. Guiding principles

  • Keep the architectural boundaries explicit.
  • Prefer small coherent closures over large speculative rewrites.
  • Do not let reference implementation convenience become hidden language law.
  • Do not collapse open FROG IR into one backend-specific or runtime-private form.
  • Do not confuse backend family, target profile, deployment mode, and runtime-private realization.
  • Keep full runtime hosting and deployment-specialized launcher/executable packaging as distinct valid deployment postures.
  • Do not confuse roadmap planning with normative ownership.
  • Do not confuse roadmap planning with current corpus-version reporting.
  • Keep the path from canonical .frog source to deployable execution explicit and inspectable.
  • Use conformance as a public truth surface, not as commentary only.
  • Keep source-shape/schema closure distinct from later semantic validation.
  • Only widen the ecosystem after enough closure exists to support that widening cleanly.
  • Keep strategic claims aligned with repository-visible proof.
  • Keep AI-era auditability claims tied to real architectural closure rather than slogans.
  • Keep versioning governance centralized in Versioning/ rather than scattering it into planning documents.

What the project must preserve: 

saved source           -> Expression
validated meaning      -> Language
derived execution form -> IR
backend specialization -> Lowering
consumable handoff     -> Backend contract
private realization    -> Runtime / backend
authoring + debugging  -> IDE
closure sequencing     -> Roadmap
current version truth  -> Versioning
strategic purpose      -> Strategy

7. Current published baseline

The project is no longer only conceptual. A meaningful public foundation already exists.

Already established

  • FROG is explicitly structured as an open graphical dataflow language rather than a product-bound environment.
  • The six core specification families exist: Expression, Language, IR, Libraries, Profiles, IDE.
  • The repository contains support areas: Examples/, Conformance/, and Implementations/Reference/.
  • A centralized version-governance surface exists through Versioning/Readme.md and Versioning/Matrix.md.
  • The first published executable slices already exist: 01_pure_addition, 02_ui_value_roundtrip, 03_ui_property_write, 04_stateful_feedback_delay.
  • The reference implementation posture is explicitly non-normative.
  • The distinction between public interface, front panel, and diagram is already explicit.
  • The distinction between widget_value and widget_reference is already explicit.
  • The strategic framing layer already exists through Strategy/Heilmeier/.

Already visible but still under closure pressure

  • [~] Canonical source and source-schema posture are substantially visible but still need continued tightening.
  • [~] Language-semantics closure is already meaningful but still being consolidated.
  • [~] IR, lowering, and backend-contract posture are already repository-visible but still part of an active closure front.
  • [~] Bounded execution-start and reference-path proof are real, but still intentionally narrow.
  • [~] Widget-object closure is already serious, but still a growth front.
  • [~] The current corpus version is centrally described, but broader stabilization of the full published subset is still progressing.

This roadmap should therefore be read as the sequencing layer for a repository that already has real published structure, not as a plan for a repository that is still empty or purely hypothetical.

8. Priority order

The current closure order should remain biased toward corridor coherence before broad ecosystem expansion.

  1. keep the repository-level entry surfaces aligned with the real published state,
  2. keep source, semantic, IR, and conformance boundaries mutually coherent,
  3. keep the bounded execution-start and reference path credible,
  4. keep widget-object closure coherent across source, libraries, profiles, and execution-facing reasoning,
  5. keep version-governance centralized and current,
  6. only then widen backend families, runtime families, deployment surfaces, or broader ecosystem claims.

9. High-level roadmap

Phase 0  -> foundation already established
Phase 1  -> source and semantics closure
Phase 2  -> IR and compiler-corridor closure
Phase 3  -> bounded execution-start and reference-path closure
Phase 4  -> widget-object and UI corridor closure
Phase 5  -> conformance growth and profile broadening
Phase 6  -> ecosystem and industrial-standard position

These phases are not independent silos. They overlap, but they should still be closed in a disciplined order.

10. Phase 0 — Foundation already established

  • repository landing surface and global architecture framing
  • six core specification families
  • examples, conformance, and reference-path support surfaces
  • strategic framing layer
  • roadmap layer
  • centralized version-governance layer

Phase 0 is no longer the active frontier. It is the already-established repository foundation that later work now builds on.

11. Phase 1 — Source and semantics closure

  • [~] continue tightening the canonical .frog source shape
  • [~] continue tightening source-schema posture and structural validation boundaries
  • [~] continue tightening the distinction between structural validity and semantic acceptance
  • [~] continue tightening public-interface, front-panel, connector, and diagram ownership boundaries
  • [~] continue tightening control-structure and state semantics
  • [~] continue tightening library-owned versus profile-owned behavior boundaries

Phase 1 is successful when the repository exposes a clean source-to-meaning boundary for the bounded published subset without relying on implementation folklore.

12. Phase 2 — IR and compiler-corridor closure

  • [~] keep the canonical execution-facing IR explicit and open
  • [~] keep derivation rules, construction rules, and identity mapping coherent
  • [~] keep canonical JSON IR validation posture explicit where published
  • [~] keep lowering architecturally downstream from the open IR
  • [~] keep backend-facing contracts explicit and distinct from runtime-private realization
  • [~] keep backend-family reasoning bounded and credible

Phase 2 is successful when the repository-visible compiler corridor is explicit enough that the open IR remains clearly upstream from private backend machinery and clearly distinct from one runtime’s internal graph.

13. Phase 3 — Bounded execution-start and reference-path closure

  • [~] keep a first bounded profile-level execution-start contract coherent
  • [~] keep named example slices aligned with the actual bounded corridor
  • [~] keep conformance material aligned with the bounded executable truth surface
  • [~] keep the reference workspace serious but non-normative
  • [~] keep executable reference slices inspectable from source to bounded observable execution

Phase 3 is successful when the repository can show a real bounded vertical slice from canonical source through derivation and backend-facing preparation to an observable execution path without pretending that all later runtime families are already standardized.

14. Phase 4 — Widget-object and UI corridor closure

  • [~] keep front-panel declaration distinct from diagram interaction
  • [~] keep widget_value and widget_reference distinct
  • [~] keep widget instance and widget class distinct
  • [~] keep property read, property write, method invocation, and event exposure distinct
  • [~] keep source-level declaration and IDE-synthesized node surfaces distinct
  • [~] keep standardized widget-class contracts distinct from runtime-private or toolkit-private reflection mechanisms

Phase 4 is successful when the published repository exposes a coherent UI-object corridor serious enough to support long-term conforming IDE behavior, validator behavior, and runtime-host reasoning without turning one UI host into hidden normative law.

15. Phase 5 — Conformance growth and profile broadening

  • expand conformance families once the currently published corridor is stable enough
  • broaden capability-family coverage only when ownership boundaries remain clear
  • refine broader backend-family, runtime-family, or deployment-family distinctions where justified
  • widen interop and profile surfaces without collapsing them into the intrinsic core
  • grow preservability and degraded readability expectations where cross-version safety can be made explicit

Phase 5 must not start by scattering unfinished claims. It should widen only from a sufficiently stable bounded core.

16. Phase 6 — Ecosystem and industrial-standard position

  • credible multi-implementation ecosystem posture
  • broader profile ecosystem credibility
  • serious deployment and runtime-family maturity
  • stronger industrial-standard posture
  • clearer conformance, certification, and branding ecosystem separation

Phase 6 is not a marketing phase. It is the point where enough repository-visible closure exists to sustain a credible long-term open industrial language ecosystem.

17. Cross-cutting workstreams

Source provenance and human-review attestations are a cross-cutting workstream across Expression/, IDE/, Conformance/, Versioning/, and later optional deployment policy profiles. The immediate objective is not to block execution by default, but to make authoring origin, AI participation, import status, review acceptance, stale evidence, and untrusted issuers visible without corrupting source semantics.

Some workstreams cut across several phases and must remain continuously aligned:

  • repository-entry alignment,
  • example / conformance / reference triangulation,
  • identity and mapping continuity,
  • execution observability and debugging posture,
  • widget-object ownership clarity,
  • versioning centralization and freshness,
  • strategy-to-proof coherence,
  • anti-regression documentation discipline.

18. Milestone navigation

Compact milestone tracking is maintained in: 

Roadmap/Milestones.md

Milestones should remain a compact navigation aid for closure progress. They should not become a duplicate version-status matrix. Detailed current repository-surface status belongs centrally in:

  • Versioning/Readme.md,
  • Versioning/Matrix.md.

19. Definition of success

This roadmap is successful when it helps the repository close in a disciplined order without blurring the distinction between:

  • what FROG is,
  • what is already published,
  • what version state the repository is currently in,
  • what should be closed next,
  • what remains longer-term ecosystem work.

The roadmap should therefore remain:

  • non-normative,
  • sequencing-oriented,
  • architecturally disciplined,
  • explicitly distinct from the version-governance surface,
  • explicitly distinct from strategy,
  • explicitly distinct from technical ownership layers.

FROG succeeds as a project when the repository can sustain a durable path from canonical source to validated meaning, open execution-facing IR, backend handoff, bounded observable execution, rich widget-object closure, conformance growth, and eventually a credible multi-implementation open industrial ecosystem.