🐸 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

What is FROG? • FROG whitepaper • What makes FROG different? • From GO HW to FROG • What this repository defines • What FROG is not • Published repository state • Campaign priority • Positioning • Breaking the syntax-first bottleneck • Why FROG exists now • FROG in the AI era • Post-AI accountability • Dataflow programming • From prototyping to critical systems • Core concept • Runtime and compiler complementarity • Open FIR bridges and deployment modularity • Repository structure • Runtime and native execution direction • Internal documentation map • Recommended reading path • Specification architecture • Program representation • Execution architecture • Execution observability, debugging, and inspection • Execution targets • Open industrial hardware standard • Security & optimization • Interoperability • Language separation • Governance, official branding, and ecosystem • Project status • License

FROG Whitepaper

A dedicated strategic and technical whitepaper is available for readers who want a broader explanation of FROG’s purpose, technological ambition, relationship with SOTA GO and GO HW, AI-era relevance, runtime/compiler modularity, open FIR posture, and long-term ecosystem strategy.

This whitepaper explains why FROG should be understood not merely as a graphical tool, but as an open graphical dataflow language foundation designed for inspectable, hardware-agnostic, compiler-agnostic, AI-ready industrial software.

The whitepaper is non-normative. The authoritative specification remains this FROG repository. The whitepaper provides strategic framing, industrial positioning, and a higher-level explanation of why FROG matters in the continuity of Graiphic’s GO program.

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,
explicit observability surfaces such as probes, watches, and inspection-aware source objects.

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 makes FROG different?

FROG is not differentiated by one isolated feature. Graphical programming, multi-target deployment, model-based execution, runtime systems, compilers, and open specifications already exist in different forms across the software landscape.

FROG’s differentiation is the combination of those concerns into one open graphical language architecture where source, meaning, execution-facing representation, lowering, runtime consumption, compiler consumption, and hardware adaptation remain explicitly separated.

The strategic claim is therefore precise: FROG aims to open the language layer of graphical industrial programming itself. It does this by making the canonical source open, the validated meaning explicit, the FIR inspectable, and the downstream runtime/compiler bridge boundaries modular.

Property	What it means in FROG	Why it matters
Inspectable	Source, graph structure, FIR, lowering, backend contracts, acceptance artifacts, and runtime behavior are intended to remain traceable.	Generated or transformed systems can be reviewed as structured artifacts rather than trusted as opaque output.
Hardware-agnostic	The language is not owned by one CPU, OS, runtime, compiler, board family, or hardware vendor.	The same upstream program model can be bridged toward heterogeneous execution targets.
FIR-open	FIR is treated as a public execution-facing bridge surface, not as a backend-private internal object.	Runtime families, compiler families, and hardware bridges can attach downstream without redefining the language.
Hyper-modular	IDE, source, semantics, FIR, lowering, backend contracts, runtime families, compiler families, and profiles remain distinct.	The ecosystem can grow without collapsing into one monolithic product stack.
AI-compatible	The canonical source is structured, the program graph is reviewable, and execution-facing artifacts are inspectable.	AI-assisted generation and transformation can be paired with human review and validation instead of opaque automation.
Accountability-oriented	Generated or human-authored logic can be carried through explicit source, validation, FIR, lowering, backend contracts, acceptance, runtime/compiler consumption, and optional `ide.provenance` evidence.	Industrial users can reason about responsibility, review, control, provenance, and evolution instead of receiving a large opaque block of generated code.
Security-oriented	FROG does not claim that graphical form automatically guarantees safety; it reduces opacity through explicit structure and inspectable artifacts.	Security and assurance conversations can be grounded in auditability, traceability, and controlled downstream handoff.

A useful analogy is the historical role of C as a portable systems-language layer above many hardware targets. FROG does not claim to be C, and it does not yet claim universal target coverage. The analogy is architectural: FROG aims to provide an open upstream graphical language layer whose FIR can be bridged toward many downstream runtime, compiler, and hardware families.

open graphical source
        |
        v
validated language meaning
        |
        v
open execution-facing FIR
        |
        +--------------------------+--------------------------+
        |                          |                          |
        v                          v                          v
runtime-family bridges      compiler-family bridges     hardware/vendor bridges
        |                          |                          |
        v                          v                          v
live execution services     native / optimized paths    operational target stacks

This is the core disruption hypothesis of FROG: industrial graphical programming should no longer require the language, the editor, the runtime, the compiler, and the hardware ecosystem to be owned by one inseparable stack.

From GO HW to FROG

FROG is not an isolated idea. It is a deeper architectural step in Graiphic’s trajectory.

GO HW made visible how powerful graphical orchestration can become when AI, logic, and hardware are treated as one executable system. That work demonstrated the value of a graphical cockpit able to design, deploy, and monitor complex graph-based execution paths. It also revealed a structural limit: as long as the language boundary, the saved format, and the execution-facing representation remain too tightly coupled to one stack, long-term openness, modularity, inspectability, and sovereignty remain constrained.

FROG is the answer to that limit. It takes the ambition one layer deeper. Instead of stopping at graphical orchestration as a tooling achievement, FROG opens the language foundation itself:

open canonical source,
open validated semantic layering,
open execution-facing FIR,
explicit lowering and backend handoff boundaries,
runtime-family modularity,
compiler-family modularity,
and an ecosystem where language truth is not owned by one product stack.

This is a more difficult path. It is also the more ambitious one. It aims at full architectural mastery from source to execution, while preserving openness and long-term industrial sovereignty.

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, 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.

What FROG is not

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 not a security guarantee just because a program is graphical.
FROG is an open language specification with distinct source, semantic, FIR, library, profile, IDE-facing, conformance, and version-governance layers.

That distinction matters. Multiple independent implementations should be possible around the standard. At the same time, the official FROG product identity and official branding can remain steward-controlled. Graiphic may build the flagship official IDE carrying the FROG name, while the language itself remains open and implementable by others.

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-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-runtime-to-native 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 FIR artifact,
a published backend contract artifact,
published downstream reference runtime consumers,
shared runtime-family acceptance material,
and a first LLVM-oriented native proof corridor.

The current published runtime and native surface already includes:

a repository-visible runtime directory under Implementations/Reference/Runtime/,
a shared runtime-family acceptance surface under Implementations/Reference/Runtime/acceptance/,
a Python runtime-family consumer under Implementations/Reference/Runtime/python/,
a Rust runtime-family consumer under Implementations/Reference/Runtime/rust/,
a C/C++ runtime-family consumer under Implementations/Reference/Runtime/cpp/,
and a first LLVM-oriented downstream dossier under Implementations/Reference/LLVM/.

At the same time, the repository does not claim full generalized symmetry across all future examples, all runtime families, or full rendered-native front-panel closure. The correct current statement is narrower: the repository now materially exposes a repository-visible bounded symmetry for the canonical Example 05 corridor across FIR, lowering, backend contract emission, shared acceptance material, Python, Rust, C/C++, and a first LLVM-oriented native proof path.

That distinction matters. The published direction already supports language/runtime/compiler separation, and the repository-visible executable closure is now materially stronger than before, while still remaining example-scoped and intentionally non-generalized.

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 shared runtime-family acceptance posture,
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.

The canonical repository anchor for that campaign is currently:

Examples/05_bounded_ui_accumulator/

That slice should be read as the first repository-visible proof that the same named example can be carried through:

source,
front-panel package,
FIR,
lowering,
backend contract emission,
runtime-family acceptance,
runtime-family consumption,
and a first native compiler-family corridor.

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, modular downstream execution, and system-grade deployment 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 now

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.

It also exists because the AI era changes the stakes. Generated software, AI-assisted transformation, multi-target deployment, industrial security, and technological sovereignty all increase the value of open source formats, open execution-facing IRs, and modular downstream bridge boundaries.

Generative AI changes the economics of software creation. It can produce code, tests, documentation, and system logic far faster than traditional human review processes were designed to absorb. That acceleration does not remove the need for responsibility. It makes responsibility, understanding, inspection, integration, and controlled evolution more important.

In industrial environments, software cannot merely be produced. It must be understood, validated, attributed, maintained, audited, and controlled. FROG exists in that context: not as a rejection of AI-assisted software generation, but as a language architecture intended to make fast-generated or human-authored logic structurally inspectable and governable before it reaches real execution.

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, widget interaction paths, probes, watch surfaces, and other source-meaningful execution objects directly as program objects.

Inspectable execution-facing FIR

FROG does not stop at an open source file. The execution-facing FIR 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.

That open FIR is also strategically important because it preserves the possibility of attaching multiple downstream runtime families and compiler families without making any one of them the hidden truth of the language.

This is why FROG is AI-compatible by architecture rather than by slogan. AI-assisted generation can target structured source. Human reviewers can inspect graph-level meaning. Toolchains can validate semantics and derive FIR. Downstream consumers can receive explicit contracts rather than opaque intent.

The strategic point is not that AI should be rejected. The strategic point is that AI-assisted system creation needs better control surfaces. When generation becomes cheap and fast, understanding becomes the scarce resource. FROG is shaped for that scarcity: it provides structured source, graphical meaning, semantic validation, open FIR, explicit downstream handoff, and observable runtime/compiler consumption.

Post-AI accountability: inspection and control

Generative AI is changing the bottleneck of software engineering. The bottleneck is no longer only the ability to produce code. Increasingly, the bottleneck is the ability to understand, inspect, validate, attribute, integrate, maintain, and evolve what has been produced.

That shift matters especially in industry. When software drives machines, instruments, robots, production lines, embedded systems, energy systems, medical systems, or safety-relevant workflows, a generated artifact is not enough. A serious organization must be able to answer:

what logic is being executed,
which source artifact owns that logic,
which semantic rules validated it,
which execution-facing representation was derived,
which lowering and backend contract were consumed,
which runtime or compiler family executed it,
which behavior was expected,
which behavior was observed,
and who is responsible for accepting that chain.

FROG is designed to support that responsibility chain. It does not claim that graphical representation automatically makes software correct. It claims that structured graphical source, explicit dataflow, validated meaning, open FIR, lowering, backend contracts, acceptance artifacts, and runtime/compiler separation make the system easier to inspect and govern than opaque generated code alone.

AI-generated or human-authored intent
        |
        v
structured .frog source
        |
        v
graphical review and source-level inspection
        |
        v
semantic validation
        |
        v
open execution-facing FIR
        |
        v
lowering and backend contract
        |
        v
runtime-family or compiler-family consumption
        |
        v
observable execution and accountable evolution

In that sense, FROG is not anti-AI. FROG is a control architecture for a world where AI can generate more software than humans can comfortably inspect through linear text alone. It gives humans and organizations a structured interface for understanding, reviewing, controlling, and evolving fast-produced software.

This is also why FROG matters for future engineering roles. As code generation becomes more automated, the most valuable engineers will increasingly be those who can specify, inspect, validate, integrate, and govern complex generated systems. FROG aims to provide a language and representation stack suited to that shift.

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, Public Interface

A FROG program combines multiple related but distinct source-level concepts. The repository deliberately separates them so that execution meaning, public API, UI-facing authoring, and observability posture 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,
probe and watch attachment points when declared by the source or IDE model,
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.

Observability model

FROG also treats execution observability as a first-class architectural concern rather than as an afterthought. The long-term IDE-facing posture should support at least:

probes — local inspection objects attached to wires, ports, nodes, structure boundaries, or other graph-meaningful surfaces in order to expose live or sampled values,
watches — persistent observation surfaces that follow selected program objects, values, references, or execution-local states across editing, execution, and debugging workflows,
projection back to source-meaningful objects rather than debugger-only opaque runtime internals.

Probes and watches do not redefine the program’s executable meaning. They belong to the observability, debugging, and IDE-facing architecture. They matter because graphical dataflow systems are especially strong when live execution can be inspected directly on the graph and on its public interaction surfaces.

Runtime and compiler complementarity

FROG explicitly rejects the idea that runtime and compiler must be treated as competing ideologies. They are complementary downstream strategies that can both begin from the same canonical source and the same open FIR.

A compiler path prepares deployable artifacts specialized for a target family. A runtime path provides live execution services such as state management, observability, communication, hosting, front-panel interaction, monitoring, or controlled operational adaptation.

Different targets require different balances:

some deployments are compiler-heavy,
some are runtime-heavy,
some are hybrid,
and some need bridge paths toward existing operational hardware runtimes already present in the field.

FROG is designed so that the language does not have to choose one of those paths as its permanent identity. The language stays upstream. The deployment strategy stays modular.

Open FIR bridges and deployment modularity

The openness of FIR is one of the most strategically important properties of FROG. An open FIR is not only an inspectable intermediate representation. It is the public architectural bridge surface that makes downstream combinability possible.

Because FIR remains open:

bridges can be built from FIR toward compiler families,
bridges can be built from FIR toward runtime families,
bridges can be built toward existing operational hardware stacks,
and the same upstream program can support multiple deployment combinations without redefining the language itself.

This is especially important for heterogeneous hardware ecosystems. Some vendors expose their value primarily through runtime stacks. Others expose it through compiler flows. Others use a hybrid posture. FROG’s goal is to remain upstream from those differences rather than being captured by one of them.

canonical .frog source
        |
        v
validated meaning
        |
        v
open FIR
   +----+-----------------------------+-----------------------------+
   |                                  |                             |
   v                                  v                             v
runtime bridge family         compiler bridge family       hybrid bridge family
   |                                  |                             |
   v                                  v                             v
Python / Rust / C++            LLVM / native paths          target-specific mixes
reference runtimes             vendor compiler chains       runtime + compiled flows
   |                                  |                             |
   +--------------------------+-------+-----------------------------+
                              |
                              v
                heterogeneous deployment targets

That modularity does not mean all downstream bridges already exist. It means the architecture is deliberately shaped so they can exist without changing the language truth.

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-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
      |
      +------------------------------- shared acceptance surface -------------------------------+
      |
      \------------------------------- optional LLVM-oriented native path ----------------------->

For the canonical Example 05 slice, the repository now materially exposes this direction in bounded form:

a Python runtime-family consumer,
a Rust runtime-family consumer,
a C/C++ runtime-family consumer,
a shared runtime-family acceptance posture,
and a first LLVM-oriented native proof path.

This does not imply that all of these paths are already closed for all published examples. It defines the explicit repository direction and, for Example 05, a first repository-visible bounded closure.

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
│
├── IDE/
│   ├── Readme.md
│   │   -> IDE architecture entry point
│   ├── Observability.md
│   │   -> probes, watches, execution projection, and inspection-facing posture
│   ├── Debugging.md
│   │   -> debugging control, stop semantics at the IDE layer, and runtime-to-source projection consumption
│   ├── Probes.md
│   │   -> local live inspection tools
│   └── Watch.md
│       -> persistent centralized inspection tools
│
├── Implementations/Reference/Runtime/
│   ├── Readme.md
│   │   -> runtime-family entry point and shared consumer posture
│   ├── acceptance/Readme.md
│   │   -> shared acceptance material for runtime-family consumers
│   ├── 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/

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.

The architectural posture below deliberately combines three requirements:

a clear source-to-execution derivation corridor,
a clear downstream split between runtime-family and compiler-family consumers,
and a clear observability/debugging branch that preserves probes and watches as first-class IDE-facing concepts without turning them into program semantics.

                                   FROG IDE
                 +--------------------------------------------------+
                 | Diagram + Front Panel UI + Probes + Watches      |
                 +--------------------------+-----------------------+
                                            |
                                            v
                                 FROG Program Model
                           (editable in-memory source 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 IR
                        (canonical execution-facing document, derived, inspectable,
                           source-attributed, execution-facing, not backend-private)
                                                                     |
                                                                     v
                                                     Identity / Mapping preservation
                                                                     |
                                                                     v
                                                    Lowering / backend-facing handoff
                                                                     |
                                  +----------------------------------+----------------------------------+
                                  |                                                                     |
                                  v                                                                     v
                         Runtime-family consumers                                             Compiler-family consumers
                                  |                                                                     |
                                  v                                                                     v
                        Target execution instance                                          Target artifact / executable
                                  |                                                                     |
                          +-------+------------------------------------------+--------------------------+
                          |                                                  |
                          v                                                  v
        Source-aligned execution observability                  Runtime activity on the active target
        (mapped back to meaningful FROG objects)
                          |
                          v
       Debugging / inspection / pause / resume / break / step
                          |
                +---------+----------+
                |                    |
                v                    v
             Probes                Watches

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.

Likewise, probes and watches belong to the execution-observability and IDE-facing posture layered on top of execution projection. They do not redefine the validated executable meaning of the program.

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, UI-related execution objects, probes, watch surfaces, and public-interface participation rather than on a fictional sequential instruction list.

A useful long-term observability posture includes:

probes for localized value inspection on wires, ports, nodes, structures, and other graph-facing surfaces,
watches for persistent observation of selected values, references, state cells, widget objects, or public-interface objects,
source projection so that runtime observations remain attributable to source-meaningful objects rather than to opaque backend-private internals,
host-independent semantics so that observability remains an architectural capability of the ecosystem rather than a private trick of one runtime.

This matters especially for graphical dataflow programming because live inspection is not an optional luxury. It is part of the practical readability and engineering power of the model.

In this architecture:

probes are best understood as local, execution-projected inspection points placed near graph-meaningful surfaces,
watches are best understood as persistent observation surfaces that remain useful across longer debugging and analysis workflows,
break / pause / resume / step belong to debugging control posture,
runtime telemetry alone is not sufficient unless it can be mapped back to meaningful FROG objects.

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.

That ambition includes a future where hardware vendors can expose runtime bridges, compiler bridges, backend contracts, and operational integration layers against the same open upstream language basis rather than forcing users into isolated graphical silos.

Security and optimization by design

FROG integrates validation, inspectability, 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.

Security claims must remain disciplined. FROG does not claim that graphical form automatically guarantees safety or security. Its narrower and stronger claim is that open source, explicit graph structure, open FIR, readable governance, and explicit downstream handoff reduce structural opacity and improve inspectability.

This means FROG is security-relevant through architecture: it favors auditability, traceability, reviewable transformation, explicit validation, bounded acceptance surfaces, and controlled runtime/compiler boundaries. Those properties do not replace security engineering, but they make security engineering less opaque.

The same point applies to responsibility. In an AI-assisted development context, the critical question is not only whether code can be produced. The critical question is whether the produced logic can be inspected, explained, accepted, and evolved by accountable humans and organizations. FROG is designed to make that responsibility chain more explicit.

Interoperability

FROG is designed for interoperability at several levels:

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

Representative integration targets may include:

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

In the long-term architectural model, interoperability also means that one open FIR may be bridged toward multiple runtime or compiler families without forcing one operational stack to become the language definition.

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,
program execution meaning from probes and watches,
specification corpus governance from .frog spec_version,
.frog spec_version from metadata.program_version.

Governance, official branding, 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.

Version governance, transition rules, and current repository status belong to the dedicated repository governance surfaces under Versioning/. Individual architectural documents should remain modular and should not become standalone version-governance documents.

The ecosystem direction is intentionally open: multiple independent IDEs, runtimes, compiler bridges, validators, and tooling layers may eventually coexist around the same open standard. At the same time, official branding and the official flagship product identity may remain controlled. Graiphic intends to build the flagship proprietary IDE on top of the FROG standard, and that official IDE may be the one carrying the formal FROG product name.

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, governance surfaces, strategic framing, roadmap posture, examples, conformance material, and a non-normative reference implementation workspace.

At the current published state, the repository has now reached a stronger closure milestone than before: it materially exposes a repository-visible bounded Example 05 corridor across source, front-panel package, FIR, lowering, backend contract emission, shared runtime-family acceptance, Python runtime, Rust runtime, C/C++ runtime, and a first LLVM-oriented native path.

At the same time, the repository has not yet reached:

full generalized multi-runtime symmetry across all serious examples,
full native rendered front-panel closure,
or final depth across all observability, debugging, and IDE-facing surfaces.

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, observability, and governance layers.

In the generative AI era, that ambition also carries a responsibility dimension: FROG aims to help keep fast-produced software understandable, attributable, controllable, and evolvable by humans and organizations that remain responsible for real execution.

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,447 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

FROG Whitepaper

What is FROG?

What makes FROG different?

From GO HW to FROG

What this repository defines

What FROG is not

Published repository state

Campaign priority

Positioning

Breaking the syntax-first bottleneck

Why FROG exists now

FROG in the AI era

Canonical JSON source

Graphically reviewable program structure

Inspectable execution-facing FIR

Post-AI accountability: inspection and control

Dataflow programming

From prototyping to critical systems

Core concept: Diagram, Front Panel, Public Interface

Diagram — the authoritative executable graph

Public interface — the reusable program boundary

Front Panel — the interaction layer

Widget interaction model

Observability model

Runtime and compiler complementarity

Open FIR bridges and deployment modularity

Repository structure

Runtime and native execution direction

Internal documentation map

Recommended reading path

Specification architecture

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, official branding, 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