🐸 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, and scalable across heterogeneous execution targets.

Specification work initiated: 8 March 2026

What is FROG? • What this repository defines • Published repository state • Campaign priority • Positioning • Breaking the syntax-first bottleneck • Why FROG exists • FROG in the AI era • Dataflow programming • From prototyping to critical systems • Core concept • Repository structure • Runtime and native execution direction • Internal documentation map • Recommended reading path • Specification architecture • Specification versioning • Program representation • Execution architecture • Execution observability, debugging, and inspection • Execution targets • Open industrial hardware standard • Security & optimization • Interoperability • Language separation • Governance and ecosystem • Project status • License

What is FROG?

FROG is an open, hardware-agnostic graphical dataflow programming language. It represents computation as explicit executable graphs rather than as syntax-first sequences of textual instructions.

Instead of describing a program primarily through ordered text, FROG describes a program through:

typed nodes,
typed ports,
directed graph connections,
structured control regions,
explicit public interface boundaries,
optional front-panel widgets and interaction layers.

Execution emerges from data availability, dependency structure, explicit control constructs, intrinsic standardized primitive behavior, optional profile-owned capability behavior, and explicit local-memory semantics rather than from manually authored instruction order.

FROG is designed to remain independent from any specific IDE, compiler, runtime, operating system, or hardware vendor. That separation provides a durable basis for multiple independent implementations, long-term industrial interoperability, and auditable portability across toolchains.

FROG is intended to scale from accessible graphical authoring to demanding execution contexts such as industrial automation, embedded systems, heterogeneous compute targets, and future conforming execution ecosystems.

What this repository defines

This repository defines the published FROG specification. It is the repository where the language and its surrounding specification layers are written, clarified, stabilized, versioned, and progressively closed.

Its role is to provide a durable open foundation for future:

IDEs,
validators,
runtimes,
compilers,
execution backends,
profile-supporting toolchains,
ecosystem services and integrations.

The repository also contains repository-level support material that helps make the specification inspectable in practice: named examples, conformance material, a non-normative reference implementation workspace, a strategic framing layer, a non-normative roadmap layer, and a centralized specification-versioning surface. Those areas support the published specification, but they do not replace its ownership boundaries.

This repository does not define one mandatory product implementation. It does not equate the language with one IDE, one runtime, one compiler, one vendor stack, or one deployment model.

FROG is not an IDE.
FROG is not a single runtime.
FROG is not a single compiler.
FROG is not a vendor product.
FROG is an open language specification with distinct source, semantic, FIR, library, profile, IDE-facing, conformance, and version-governance layers.

Published repository state

At the current published state, the repository already contains the six core architectural specification families: Expression/, Language/, IR/, Libraries/, Profiles/, and IDE/. These remain the primary ownership layers of the published language specification.

The repository also contains repository-level support areas and repository-level framing / governance layers:

Examples/ — illustrative named source slices, applicative vertical-slice anchors, and bounded compiler-corridor mirrors,
Conformance/ — public accept / reject / preserve expectations for the published repository state,
Implementations/Reference/ — a non-normative reference implementation workspace used to exercise disciplined execution paths,
Versioning/ — centralized specification-version governance and current-status reporting for the published specification corpus,
Strategy/ — a non-normative strategic framing layer distinct from normative ownership,
Roadmap/ — a non-normative closure-sequencing layer distinct from both strategy and specification.

The published example surface already contains both:

a numbered example-slice progression under Examples/01_* through Examples/05_*,
and a narrower conservative compiler-corridor mirror under Examples/compiler/.

The first repository-visible applicative vertical-slice anchor is:

Examples/05_bounded_ui_accumulator/

That slice is currently the primary named source-to-contract-to-runtime anchor because it visibly combines:

front-panel participation,
widget-value participation,
minimal widget-reference participation,
bounded structured control,
explicit local state,
public output publication,
a published backend contract artifact,
and published downstream reference runtime consumers.

The current published runtime surface already includes:

a repository-visible runtime directory under Implementations/Reference/Runtime/,
a Python execution entry point for the published bounded slice,
and a Rust runtime-side consumer posture under Implementations/Reference/Runtime/rust/.

At the same time, the repository does not yet materially expose full symmetry between:

Python mini runtime,
Rust mini runtime,
C/C++ mini runtime,
and LLVM-oriented native executable closure.

That distinction matters. The published direction already supports language/runtime separation, but the repository-visible executable closure still needs to become more explicit and more symmetrical across runtime families.

Campaign priority

The current campaign priority is explicit: close serious published examples all the way to real execution and make multi-runtime modularity repository-visible.

A serious example is no longer considered finished merely because it is source-readable or architecturally plausible. A serious example should progressively converge toward:

one canonical .frog source,
one explicit front-panel posture,
one explicit peripheral UI object realization file when applicable,
one explicit FIR reading,
one explicit lowering posture,
one backend contract,
one Python mini runtime path,
one Rust mini runtime path,
one C/C++ mini runtime path,
and, where applicable, one LLVM-oriented native executable path.

This campaign does not make one runtime the definition of FROG. It makes the opposite point: the language remains stable while downstream consumers remain modular.

Positioning

FROG is designed to combine the accessibility of graphical programming with the execution depth required for deterministic, industrial, embedded, high-performance, and safety-relevant systems.

Its ambition is to reduce the historical trade-off between:

ease of expression,
clarity of system design,
deterministic execution,
deployment scalability,
hardware integration depth,
human auditability of program structure.

FROG aims to combine graphical accessibility, explicit dataflow, auditability, and system-grade execution in one open language model.

Breaking the syntax-first bottleneck

A major barrier in many traditional programming environments is that useful system design often begins only after a long period of syntax learning, pattern memorization, and language-specific implementation habits.

This creates an inversion: instead of starting from the system that should exist, developers often start from the syntax they already know how to write.

That inversion limits experimentation and slows architectural thinking. It encourages people to ask:

“What can I build with the implementation techniques I already master?”

rather than:

“What system should I build, and how should its behavior be expressed?”

FROG is designed to reduce that bottleneck by moving more of the developer’s effort toward:

data movement,
system structure,
interfaces,
control regions,
state visibility,
execution semantics.

The goal is not to eliminate engineering complexity. The goal is to shift complexity toward the system itself rather than toward syntax-first representation.

Why FROG exists

Graphical dataflow programming has already demonstrated major advantages in many engineering domains:

natural parallelism,
clear orchestration of behavior,
strong correspondence between software structure and system behavior,
high productivity for engineers, scientists, and domain experts,
strong suitability for instrumentation, control, and observable systems.

However, many historical graphical environments have been tightly coupled to proprietary ecosystems where language, tooling, runtime, and hardware support are inseparable.

That model limits portability, slows independent ecosystem growth, prevents multiple actors from implementing the same language cleanly, and often leaves the saved program format and execution-facing layers too opaque for durable multi-vendor reuse.

FROG exists to define an open language specification for graphical dataflow programming that remains separate from:

any single IDE,
any single runtime,
any single compiler,
any single hardware vendor.

This repository therefore defines the language standard and the surrounding specification layers needed to support future conforming implementations. The objective is to make it possible for different actors to build compatible FROG tooling while targeting one shared open language definition.

FROG in the AI era

FROG is not only relevant as an open graphical language. It is also relevant as an AI-era auditability architecture.

A modern programming ecosystem increasingly needs representations that are:

easy for tools to generate and transform,
easy for humans to inspect and review,
explicit enough to preserve structure across validation and derivation stages,
open enough to avoid sovereignty loss through opaque vendor-controlled representations.

FROG addresses that need through three complementary properties:

Canonical JSON source

The canonical .frog source format is structured, machine-friendly, human-readable JSON. That makes it naturally compatible with tooling pipelines, validation workflows, version control, deterministic serialization, and AI-assisted generation or transformation.

Graphically reviewable program structure

FROG keeps the executable structure explicit at the language level. The program is not primarily hidden behind text parsing, coding idioms, or reconstruction tooling. A reviewer can inspect nodes, ports, graph connections, structures, state boundaries, interface boundaries, and widget interaction paths directly as program objects.

Inspectable execution-facing IR

FROG does not stop at an open source file. The execution-facing IR layer also remains open, inspectable, attributable, and recoverable. This reduces the gap between:

what was authored or generated,
what was validated as program meaning,
what was derived for execution-facing preparation,
what is later lowered toward backend consumption.

Dataflow programming

FROG follows a true dataflow execution model.

In instruction-sequenced programming, execution is primarily described as ordered steps. In dataflow programming, operations become executable when their required input data is available.

Traditional execution

A → B → C → D


Dataflow execution

   A
  / \
 B   C
  \ /
   D

Execution order therefore emerges from dependencies rather than from manually authored textual ordering. This model enables:

automatic parallelism where valid,
clear dependency visibility,
deterministic execution models where required,
efficient mapping to heterogeneous hardware.

From prototyping to critical systems

FROG is designed to support both rapid experimentation and demanding deployment.

The same programming model is intended to scale across domains such as:

scientific computing,
measurement and control,
industrial automation,
embedded systems,
real-time control,
microcontroller-oriented execution,
accelerated and edge computing,
high-performance systems.

Usability, execution depth, and auditability are treated as complementary goals rather than mutually exclusive ones.

Core concept: Diagram, Front Panel, and Public Interface

A FROG program combines multiple related but distinct source-level concepts. The repository deliberately separates them so that execution meaning, public API, and UI-facing authoring remain coherent over time.

Diagram — the authoritative executable graph

The diagram defines the executable logic of the program. It is the authoritative source-level execution graph.

It contains:

primitive nodes,
structure nodes,
sub-FROG invocations,
interface boundary nodes,
widget-related graph nodes,
directed graph edges,
source-level annotations and documentation.

Public interface — the reusable program boundary

The public interface defines the typed reusable boundary of a FROG. It is not owned by the front panel. It is defined independently and participates in the diagram through interface_input and interface_output.

Front Panel — the interaction layer

The front panel defines the graphical interaction layer of the program. It contains widget instances, layout information, composition, styling, and optional UI-library references.

A FROG MAY exist without a front panel. When absent, the program remains a valid executable graphical artifact centered on its diagram and public interface.

Widget interaction model

FROG distinguishes two widget interaction paths:

natural value path — widget primary value participation through widget_value,
object-style path — explicit widget access through widget_reference together with frog.ui.property_read, frog.ui.property_write, and frog.ui.method_invoke.

Repository structure

This repository is organized by architectural responsibility plus repository-level support areas. The six core specification families remain the architectural baseline of FROG. The support areas exist to make that baseline more inspectable, testable, executable, and governable without moving normative ownership away from the specification layers.

FROG/
│
├── Conformance/                      Public accept / reject / preserve expectations
├── Examples/                         Illustrative named source slices and executable example dossiers
├── Expression/                       Canonical source specification for .frog programs
├── IDE/                              IDE architecture, authoring, observability, debugging, and inspection
├── IR/                               Canonical open execution-facing representation and downstream handoff boundaries
├── Implementations/
│   └── Reference/                    Non-normative reference implementation workspace and executable prototypes
├── Language/                         Normative execution semantics for validated program meaning
├── Libraries/                        Intrinsic standardized primitive-library specifications
├── Profiles/                         Optional standardized capability-family specifications
├── Roadmap/                          Non-normative closure sequencing and milestone tracking
├── Strategy/                         Non-normative strategic framing layer
├── Versioning/                       Centralized specification-version governance and current-status matrix
│
├── assets/                           Shared repository assets used by README and GitHub Pages
├── CLA.md                            Contributor license agreement requirements
├── CONTRIBUTING.md                   Contribution process and contribution rules
├── GOVERNANCE.md                     Governance, stewardship, and ecosystem model
├── FROG logo.svg                     Official logo asset
├── LICENSE                           Repository license
├── Readme.md                         Repository landing page and architectural overview
└── frog-orville-chart.png            Positioning illustration used by the repository

The six core specification families are:

Expression/
Language/
IR/
Libraries/
Profiles/
IDE/

The current repository-level support and governance areas are:

Examples/ — illustrative named source cases and executable closure dossiers,
Conformance/ — expected outcomes for validation, preservation, and rejection,
Implementations/Reference/ — non-normative prototype workspace used to exercise the current reference path,
Versioning/ — centralized current corpus-version governance and per-surface current-status reporting.

Runtime and native execution direction

The repository direction is now intentionally explicit: the same canonical example corridor should be consumable through multiple runtime implementations and, where applicable, through a native compiler-oriented path.

The preferred long-term reading for a serious executable example is:

canonical .frog source
      |
      v
validated meaning
      |
      v
FIR
      |
      v
lowering
      |
      v
backend contract and/or compiler-facing lowered artifact
      |
      +-------------------------------+-------------------------------+-------------------------------+
      |                               |                               |
      v                               v                               v
Python mini runtime            Rust mini runtime               C/C++ mini runtime
      |
      \------------------------------- optional LLVM-oriented native path ------------------------------->

This does not imply that all of these paths are already closed for all published examples. It defines the explicit repository direction and the closure target.

The reference implementation workspace is therefore expected to remain stage-separated and family-separated: Python, Rust, and C/C++ runtime realizations should be understandable as parallel consumers of the same corridor, while LLVM-oriented native compilation remains a downstream consumer path rather than the definition of FROG itself.

Internal documentation map

The repository contains multiple normative and architectural documents. The map below summarizes the intended role of the major Markdown documents in the current baseline of the repository.

FROG/
├── Readme.md
│   -> repository landing page and global architectural entry point
├── CONTRIBUTING.md
│   -> contribution workflow, expectations, and cross-document coherence rules
├── CLA.md
│   -> contributor license agreement entry point and legal contribution notice
├── GOVERNANCE.md
│   -> repository governance, stewardship model, conformance direction,
│      certification direction, and branding boundary
│
├── Examples/
│   └── Readme.md
│       -> architectural role of named slices, executable example dossiers,
│          closure status expectations, and relation with reference consumers
│
├── Conformance/
│   └── Readme.md
│       -> public conformance posture, staged expected outcomes,
│          preservation obligations, and rejection expectations
│
├── Implementations/
│   └── Reference/
│       └── Readme.md
│           -> non-normative reference workspace, executable-slice purpose,
│              stage-separated architecture, runtime-family posture,
│              and native-path direction
│
├── Expression/
│   ├── Readme.md
│   │   -> architectural entry point for canonical source representation
│   ├── Schema.md
│   │   -> source-schema posture and machine-checkable structural validation boundary
│   ├── Diagram.md
│   │   -> authoritative executable graph as canonical source representation
│   ├── Front panel.md
│   │   -> optional front-panel composition and interaction surface
│   ├── Widget.md
│   │   -> widget instance model, identity, value behavior, properties, methods, and events
│   └── Widget interaction.md
│       -> diagram-side widget interaction paths and execution-facing access model
│
├── Language/
│   ├── Readme.md
│   │   -> architectural entry point for normative execution semantics
│   ├── Control structures.md
│   │   -> normative execution meaning of case, for_loop, and while_loop
│   └── State and cycles.md
│       -> normative meaning of explicit local memory and valid feedback cycles
│
├── IR/
│   ├── Readme.md
│   │   -> architectural entry point for the FIR / IR layer and ownership boundary
│   ├── Execution IR.md
│   │   -> canonical open execution-facing representation
│   ├── Derivation rules.md
│   │   -> correspondence rules from validated meaning to execution-facing representation
│   ├── Lowering.md
│   │   -> lowering boundary toward target-oriented executable forms
│   └── Backend contract.md
│       -> backend-facing contract for downstream consumers
│
├── Implementations/Reference/Runtime/
│   ├── Readme.md
│   │   -> runtime-family entry point and shared consumer posture
│   ├── python/Readme.md
│   │   -> Python mini-runtime posture and example pipe direction
│   ├── rust/Readme.md
│   │   -> Rust mini-runtime posture and example pipe direction
│   └── cpp/Readme.md
│       -> C/C++ mini-runtime posture and example pipe direction
│
└── Implementations/Reference/LLVM/
    └── Readme.md
        -> LLVM-oriented native path posture and ownership boundary

Specification architecture

The repository is intentionally split into distinct architectural layers:

Expression — canonical source representation, source sections, source serialization rules, source-schema posture, and structural validity,
Language — normative execution semantics for validated program meaning,
IR — canonical open execution-facing representations derived from validated program meaning,
Libraries — intrinsic standardized primitive vocabularies and primitive-local behavior,
Profiles — optional standardized capability families and profile-owned capability contracts,
IDE — authoring architecture, editor-facing models, execution observability, debugging semantics, inspection workflows, snippets, and Express authoring.

This separation is deliberate. It prevents the language from being reduced to one editor, one runtime, one compiler, or one vendor implementation.

Expression/   -> canonical source form and structural validity
Language/     -> validated program meaning
IR/           -> canonical open execution-facing representation
Libraries/    -> intrinsic standardized primitive vocabularies
Profiles/     -> optional standardized capability families
IDE/          -> authoring, observability, debugging, inspection

what is saved      -> Expression/
what is true       -> Language/
what is derived    -> IR/
what exists        -> Libraries/ and Profiles/
what is edited     -> IDE/

Beyond those six core families, the published repository also contains support and governance areas that should not be confused with semantic owners:

what is exemplified   -> Examples/
what is expected      -> Conformance/
what is prototyped    -> Implementations/Reference/
what version means    -> Versioning/

Specification versioning

FROG distinguishes three version notions that must remain explicit and must not be collapsed:

specification corpus version — the version of the published FROG specification repository as a whole,
.frog spec_version — the source-format / compatibility target declared by a source artifact,
metadata.program_version — the version of one authored FROG program artifact.

Cross-version governance is centralized in:

Versioning/Readme.md — corpus-version doctrine, current published version, additive-evolution rule, degraded readability posture, and transition policy,
Versioning/Matrix.md — detailed current-status table by repository surface.

Program representation

FROG programs should be understood across five distinct representation levels.

1. FROG Expression

The FROG Expression is the serialized source representation stored in a .frog file. It is the canonical source form of a FROG program.

2. Structural validity

A loadable JSON source file is not automatically a structurally valid canonical FROG source file. Structural validity is an explicit stage owned by Expression/.

3. FROG Program Model

The FROG Program Model is the canonical editable in-memory representation used by IDEs during authoring.

4. Validated program meaning

A source-derived FROG program must first be validated against the relevant language, primitive-library, and profile rules. That validated state is where normative execution meaning becomes a trustworthy basis for later derivation.

5. Canonical open execution-facing representation

A validated FROG is not executed directly from raw source text. A conforming toolchain validates the source-derived program representation and then derives a canonical open execution-facing representation suitable for execution preparation, analysis, normalization, optimization, lowering, or compilation.

.frog source
    |
    v
loadability
    |
    v
structural validity
    |
    v
Program Model / validated source-derived program
    |
    v
validated program meaning
    |
    v
canonical execution-facing representation (FIR posture)
    |
    v
lowering / backend-facing handoff

Execution architecture

A conforming FROG ecosystem should separate authoring, canonical source, structural validity, validated program meaning, canonical open execution-facing representation, and target-specific execution realization.

                              FROG IDE
                   +-------------------------------+
                   | Diagram + Front Panel UI      |
                   +---------------+---------------+
                                   |
                                   v
                        FROG Program Model
                    (editable in-memory model)
                                   |
                     +-------------+-------------+
                     |                           |
                     | save / load               | execute / validate
                     v                           v
        🟩 OPEN SOURCE LAYER                Validation against
        🟩 FROG Expression                 +----------------------+
        (.frog, canonical source)         | Expression/          |
                                          | Language/            |
                                          | Libraries/           |
                                          | Profiles/            |
                                          +----------+-----------+
                                                     |
                                                     v
                                  🟦 OPEN EXECUTION LAYER
                                  🟦 FROG execution-facing representation
                                                     |
                                                     v
                               Identity / Mapping preservation
                                                     |
                                                     v
                              Lowering / backend-facing handoff
                                                     |
                      +------------------------------+------------------------------+
                      |                              |                              |
                      v                              v                              v
             Python runtime family          Rust runtime family              C/C++ runtime family
                      \                              |                              /
                       \                             |                             /
                        \-------------------- LLVM-oriented native path ----------/

A serious downstream compiler path MAY eventually target compiler families such as LLVM. However, those downstream families remain consumers of lowered FROG forms rather than the definition of FROG itself.

Execution observability, debugging, and inspection

Interactive inspection and debugging are not performed directly on raw serialized source. They are performed on a live execution derived from validated program content and projected back onto source-meaningful objects.

In FROG, debugging and inspection are dataflow-first rather than line-oriented. They operate on observable graph activity, structures, sub-FROG scopes, value flow, local memory, and explicit UI-related execution objects rather than on a fictional sequential instruction list.

Execution targets

FROG programs are designed to remain source-level stable across multiple hardware classes. The language is not tied to one processor family, one operating system, one runtime architecture, or one vendor.

Representative target classes include:

General-purpose CPUs — workstation, server, and industrial PC execution,
Real-time targets — deterministic measurement and control systems,
Embedded systems — ARM and edge-oriented devices,
GPUs — accelerated compute targets,
FPGAs — programmable-logic targets,
Microcontrollers — constrained embedded execution,
Industrial edge controllers — integrated vendor-specific control and acquisition platforms.

Open industrial hardware standard

FROG aims to be more than a language that merely supports multiple targets. Its long-term goal is to provide an open industrial graphical programming standard that hardware and software ecosystems can build on without requiring a proprietary language boundary.

Security and optimization by design

FROG integrates validation, inspectability, version governance, and optimization into its architecture.

Optimization occurs primarily in execution preparation, FIR normalization, lowering, compilation, and backend stages. Those downstream stages may vary across implementations while remaining downstream from the same open language corridor.

Interoperability

FROG is designed for interoperability at several levels:

source interoperability,
editing interoperability,
structural interoperability,
semantic interoperability,
IR interoperability,
execution interoperability,
version interoperability,
ecosystem interoperability.

Representative integration targets may include:

C / C++,
Rust,
Python,
.NET,
other ABI-compatible environments.

Language separation

FROG explicitly separates:

the language specification,
the canonical source representation,
source-schema posture and structural validity,
the editable program model,
validated program meaning,
the canonical open execution-facing representation,
intrinsic standardized primitive vocabularies,
optional standardized capability profiles,
compiler implementations,
backend implementations,
runtime implementations,
development environments,
hardware adaptation layers,
deployment and orchestration layers.

At the modeling level, FROG also separates:

language from IDE,
source from structural validation,
structural validity from semantic truth,
semantic truth from derived execution-facing representation,
intrinsic libraries from optional profiles,
runtime families from one another,
runtime families from LLVM-oriented native compilation,
public interface from front panel,
natural widget value flow from object-style widget interaction,
specification corpus version from .frog spec_version,
.frog spec_version from metadata.program_version.

Governance and ecosystem

FROG is governed as an open specification. The repository is intended to remain readable, implementable, and usable by independent parties while preserving long-term architectural coherence.

The current governance model is steward-led. Graiphic is the initial steward of the FROG specification repository and is responsible for maintaining architectural coherence, reviewing proposed changes, and publishing authoritative repository revisions.

Project status

FROG is currently under active design, cleanup, stabilization, and executable-corridor closure. The repository already contains substantial material across canonical source representation, source-schema posture, language semantics, execution-facing IR architecture, intrinsic standardized primitive libraries, optional profile architecture, IDE architecture, specification-version governance, strategic framing, roadmap posture, examples, conformance material, and a non-normative reference implementation workspace.

At the same time, the repository has not yet reached full multi-runtime executable symmetry or full native executable closure for serious examples. The current direction is therefore twofold:

stabilize the open specification layers,
close repository-visible serious examples from source to runtime and, where declared, to native execution.

The long-term ambition is to establish a durable open graphical programming ecosystem that can scale from experimentation to deeply integrated industrial deployment while remaining inspectable across the source, semantic, execution-facing, and version-governance layers.

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.

Name		Name	Last commit message	Last commit date
Latest commit History 1,295 Commits
.github		.github
Conformance		Conformance
Examples		Examples
Expression		Expression
IDE		IDE
IR		IR
Implementations/Reference		Implementations/Reference
Language		Language
Libraries		Libraries
Profiles		Profiles
Roadmap		Roadmap
Strategy		Strategy
Versioning		Versioning
assets		assets
.gitignore		.gitignore
.nojekyll		.nojekyll
404.html		404.html
CLA.md		CLA.md
CONTRIBUTING.md		CONTRIBUTING.md
FROG logo.svg		FROG logo.svg
GOVERNANCE.md		GOVERNANCE.md
LICENSE		LICENSE
Readme.md		Readme.md
_navbar.md		_navbar.md
_sidebar.md		_sidebar.md
frog-orville-chart.png		frog-orville-chart.png
index.html		index.html
nav-tree.json		nav-tree.json

Folders and files

Latest commit

History

Repository files navigation

🐸 FROG — Free Open Graphical Language

What is FROG?

What this repository defines

Published repository state

Campaign priority

Positioning

Breaking the syntax-first bottleneck

Why FROG exists

FROG in the AI era

Canonical JSON source

Graphically reviewable program structure

Inspectable execution-facing IR

Dataflow programming

From prototyping to critical systems

Core concept: Diagram, Front Panel, and Public Interface

Diagram — the authoritative executable graph

Public interface — the reusable program boundary

Front Panel — the interaction layer

Widget interaction model

Repository structure

Runtime and native execution direction

Internal documentation map

Recommended reading path

Specification architecture

Specification versioning

Program representation

1. FROG Expression

2. Structural validity

3. FROG Program Model

4. Validated program meaning

5. Canonical open execution-facing representation

Execution architecture

Execution observability, debugging, and inspection

Execution targets

Open industrial hardware standard

Security and optimization by design

Interoperability

Language separation

Governance and ecosystem

Project status

License

About

Topics

Resources

License

Contributing

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Packages