🐸 FROG — Free Open Graphical Language

Free Open Graphical Dataflow Programming Language
FROG is an open, hardware-agnostic graphical dataflow programming language designed to describe computation as explicit executable graphs while remaining accessible, explicit, inspectable, portable, auditable, modular, and scalable across heterogeneous execution targets.

FROG aims to establish itself as the open-source standard foundation for graphical dataflow language infrastructure.

FROG attacks the structural lock-in of graphical industrial programming by opening the language layer itself:
canonical source, validated meaning, execution-facing FIR, lowering, backend contracts, runtime bridges, and compiler bridges.

In the generative AI era, software production becomes abundant, but accountable understanding becomes scarce.
FROG is designed to make generated or human-authored logic structured, graphical, inspectable, controllable, and governable.

FROG can also carry optional source provenance through ide.provenance, allowing provenance-aware tools to distinguish unknown, human-direct, AI-generated, AI-assisted, imported, reviewed, stale, invalid, and untrusted source-object states without changing executable meaning.

Specification work initiated: 8 March 2026

Start here • Positioning • Execution architecture • Execution pipeline • Public boundary • Repository map • Published state • License

---

Start here

This root README is the public entry point for FROG. It keeps the strategic positioning, execution architecture reference, public/private boundary, repository map, and current published state visible without forcing every reader through the full long-form material.

Read this	For
FROG Strategy and Positioning	Whitepaper links, FROG definition, GO HW continuity, campaign priority, AI-era positioning, and dataflow rationale.
FROG Architecture	Program representation, FIR posture, runtime/compiler complementarity, original ASCII execution architecture, observability, targets, security, interoperability, and language/tooling separation.
FROG Repository Guide	What this repository defines, what it does not define, public specification boundaries, repository structure, documentation map, governance, and contribution/licensing pointers.
FROG Project Status	Published repository state, examples, conformance coverage, library/profile surfaces, and maturity notes.
Examples	The growing example catalogue and validation-oriented example documentation.

---

Positioning

FROG is a public language specification, not a single IDE, runtime, compiler, device target, or vendor product. It defines a graphical dataflow language layer where source, validated meaning, execution-facing FIR, lowering, runtime contracts, compiler contracts, widgets, libraries, profiles, and conformance can be inspected independently.

That distinction matters because graphical industrial programming has often been locked inside product-specific file formats and execution stacks. FROG opens the language layer so multiple tools, runtimes, compilers, and deployment models can share durable public meaning.

The long-form strategic explanation, including the whitepaper links and AI-era accountability framing, is maintained in FROG Strategy and Positioning.

---

Execution architecture

A conforming FROG ecosystem separates authoring, canonical source, structural validity, validated program meaning, canonical open execution-facing representation, lowering, runtime/compiler consumers, target execution, and source-aligned observability.

The original ASCII execution architecture diagram remains the reference view. It is preserved with the detailed explanation in FROG Architecture.

---

End-to-end execution pipeline

A FROG program starts from canonical .frog source. The .frog file owns the program-level source: metadata, public interface, executable diagram, optional front panel, widget instances, and diagram/widget bindings.

When a front panel is present, canonical source may reference widget classes, widget packages, or realization choices. .wfrog packages publish widget-oriented package content such as reusable widget law, compositions, realization metadata, bounded behavior surfaces, host-binding metadata, and visual resources. SVG assets may participate as visual realization resources. None of those artifacts replaces .frog as the canonical program source, and none of them becomes hidden language semantics.

.frog source
  -> loadability
  -> structural validation
  -> semantic validation
  -> validated program meaning
  -> FIR / Execution IR
  -> lowering
  -> backend contract
  -> runtime-family and/or compiler-family consumption

The same corridor can be read as the following ASCII execution diagram:

+----------------------+
| .frog                |
| canonical source     |
+----------+-----------+
           |
           v
+----------------------+
| structural validation|
+----------+-----------+
           |
           v
+----------------------+
| semantic validation  |
+----------+-----------+
           |
           v
+----------------------+
| FIR                  |
| open Execution IR    |
+------+-------+-------+
       |       |
       |       +----------------------------+
       |                                    |
       v                                    v
+----------------------+        +----------------------+
| lowering             |        | widget realization   |
| backend contract     |        | .wfrog + SVG         |
+----------+-----------+        +----------+-----------+
           |                               |
           v                               v
+----------------------+        +----------------------+
| LLVM backend         |        | UI host              |
| native artifact      |        | replaceable host     |
+----------+-----------+        +----------+-----------+
           |                               |
           +---------------+---------------+
                           |
                           v
                 +----------------------+
                 | runtime              |
                 | orchestration        |
                 | bindings             |
                 | scheduling           |
                 | diagnostics          |
                 +----------------------+

For compiler-family paths such as LLVM, the lowered form may be consumed to produce an LLVM-oriented module, native proof, or native loadable artifact. LLVM remains a downstream compiler-family consumer; it does not define FROG semantics and does not replace the runtime boundary.

For runtime-family paths, the runtime consumes explicit contracts and published artifacts. It may instantiate a front panel through a host-specific UI layer, bind widget values or widget references to execution-facing units, load or call compiled artifacts when applicable, execute the dataflow unit, and project results, diagnostics, and observability back to source-meaningful objects.

Artifact or layer	Pipeline role
.frog	Canonical program source.
.wfrog	Widget/package publication or realization metadata.
SVG/assets	Visual realization resources.
FIR / Execution IR	Open execution-facing representation derived from validated meaning.
Lowering	Target, backend, runtime, or deployment specialization.
Backend contract	Explicit downstream handoff.
LLVM	One possible compiler-family consumer and native proof path.
Runtime	Execution and orchestration consumer of explicit contracts and artifacts.
Host UI	Rendering and interaction surface; replaceable across host families.

The standalone ASCII diagram page is available in End-to-End Execution Pipeline Diagram. The practical reference-corridor details are documented in Reference Pipeline. A concrete UI/runtime/LLVM-oriented example is documented in Example 05 — Bounded UI Accumulator.

---

Public Specification and Implementation Boundary

The public FROG repository defines open language and ecosystem-facing material. Graiphic may build proprietary runtimes, IDEs, product integrations, and services around that public specification, but those private implementations do not become required public language law.

Public FROG repository	Private Graiphic implementation work
.frog, FIR posture, conformance, public examples, public libraries, profiles, Default realizations, and specification-facing docs.	Graiphic production runtime families, private runtime orchestration details, IDE implementation, product packaging, and internal project coordination.

The current public reference runtime closure remains bounded to Examples 01 through 15. Later public examples remain specification-facing, widget-facing, conformance-facing, or design-progression material unless a later public runtime surface is explicitly promoted.

See Public Specification and Implementation Boundary for the full boundary statement.

---

Repository map

Path	Purpose
Language/	Canonical source and language-facing rules.
Expression/	FROG expression/source shape.
IR/	Execution-facing intermediate representation posture.
Libraries/	Public libraries, widgets, and Default realizations.
Profiles/	Capability/profile surfaces such as interoperability profiles.
Examples/	Public examples and validation-oriented dossiers.
Conformance/	Positive and negative conformance cases.
Implementations/Reference/	Public reference implementation and tooling material within the current public boundary.
IDE/	Public IDE-facing specification concepts, not the private Graiphic Studio implementation.

The detailed repository structure and reading path are maintained in FROG Repository Guide.

---

Published repository state

The public repository currently publishes the open specification surface, conformance-facing material, public examples through Example 24, Default widget realizations, public library/profile documentation, and the reference implementation material that belongs inside the public boundary.

The examples table will continue to grow in Examples. The root page intentionally keeps only the orientation-level status, while FROG Project Status preserves the detailed published-state and maturity notes that used to live here.

---

Recommended reading path

1. Start with this root README.
2. Read FROG Strategy and Positioning for why the language exists.
3. Read FROG Architecture for source, FIR, lowering, runtime/compiler, and observability posture.
4. Read End-to-end execution pipeline for the short path from source to runtime/compiler consumers.
5. Read FROG Repository Guide for the detailed repository map.
6. Use Examples and Conformance for concrete validation material.
7. Use FROG Project Status for the current published state.

---

License

This project is licensed under the Apache License 2.0. See LICENSE for details.

External contributions are governed through the repository contribution process and Contributor License Agreement requirements. See CONTRIBUTING.md and CLA.md. Repository stewardship, governance direction, and ecosystem positioning are described in GOVERNANCE.md.

---

FROG — Free Open Graphical Language
Open graphical dataflow programming, specified as a language rather than owned as a product.

---