Skip to content

Readme.md

Latest commit

 

History

History
762 lines (625 loc) · 30.1 KB

Readme.md

File metadata and controls

762 lines (625 loc) · 30.1 KB

FROG logo

🐸 FROG Strategy

Non-normative strategic framing layer for the long-term purpose, positioning, ecosystem logic, and industrial relevance of FROG
FROG — Free Open Graphical Language

FROG is not only a graphical language initiative. It is a strategic attempt to open the foundational language layer of executable graphical programming.

In the generative AI era, software production becomes abundant, but accountable understanding remains scarce. FROG is shaped for that scarcity: inspectable structure, explicit control, traceable evolution, and responsible downstream execution.

Contents

1. Why this Directory Exists

This directory exists to hold the strategic framing layer of FROG. It explains why the project matters, what category gap it targets, why that gap is important now, and what long-term ecosystem consequences would follow if FROG succeeds.

This layer is intentionally non-normative. It does not define language truth. It does not define source validity. It does not define execution semantics. It does not define IR derivation rules. It does not define current corpus-version truth.

Its purpose is to make the larger logic of the project explicit: why an open graphical language matters, why the repository is structured the way it is, why the project should be understood as more than a local tooling exercise, and why the category itself needs to change.

That category-level change is the central strategic point. FROG is not only trying to make graphical programming more convenient. It is trying to make executable graphical programming more open, more inspectable, more hardware-agnostic, more modular, and more governable than historical vendor-bound graphical ecosystems.

The generative AI wave makes that strategic layer more important. When software can be generated, rewritten, and transformed at a speed that exceeds traditional human review capacity, the key industrial question becomes less “can more software be produced?” and more “can produced software be inspected, understood, attributed, controlled, and evolved responsibly?”

2. What Strategy Owns

The Strategy layer owns repository-visible documents whose role is to explain:

  • the strategic problem FROG addresses,
  • the ecosystem gap FROG targets,
  • the expected impact of success,
  • the relevance of openness, inspectability, portability, modularity, and auditability,
  • the long-term industrial and technological significance of the project,
  • the role of open FIR as a public bridge surface toward runtime families, compiler families, and hardware ecosystems,
  • the post-AI need for accountable understanding, inspection, control, and governed evolution,
  • the framing used for external explanation, funding logic, ecosystem communication, or mission-level positioning.

This is the layer where FROG can explain not only what it is, but also why it matters.

The strongest strategic reading of FROG is not “another graphical editor”. The strongest strategic reading is that FROG tries to open the language and execution-facing bridge layer underneath graphical system programming.

In the AI era, that reading becomes even stronger: FROG is positioned as a way to give humans and organizations a structured control surface over logic that may be authored by humans, generated by AI, transformed by tools, or lowered toward heterogeneous execution targets.

3. What Strategy Does Not Own

The Strategy layer does not own:

  • canonical source representation,
  • source-shape/schema posture,
  • structural validity,
  • validated language meaning,
  • intrinsic primitive behavior,
  • profile-owned capability behavior,
  • canonical execution-facing IR definition,
  • lowering rules,
  • backend contract rules,
  • conformance expectations,
  • reference implementation behavior,
  • roadmap sequencing,
  • current specification corpus version and current detailed repository-surface status.

Those ownership boundaries remain elsewhere in the repository: 

Expression/                 -> canonical source and structural validity
Language/                   -> validated program meaning
Libraries/                  -> intrinsic primitive surface
Profiles/                   -> optional standardized capability families
IR/                         -> canonical open execution-facing representation
Conformance/                -> public accept / reject / preserve expectations
Implementations/Reference/  -> non-normative executable workspace
Roadmap/                    -> sequencing and closure order
Versioning/                 -> corpus-version governance and current-status reporting

Strategy may explain why those layers matter, but it must not silently replace them.

This separation is itself strategic. FROG’s credibility depends on not collapsing vision, roadmap, version status, normative law, and reference implementation into one ambiguous document layer.

4. Why FROG Needs a Strategic Layer

FROG is not merely a technical document set. It is an attempt to open a category that has historically remained fragmented, opaque, and too tightly coupled to proprietary execution ecosystems.

A strategic layer is therefore needed because the project has to explain more than local technical design choices. It has to explain:

  • why open graphical programming matters,
  • why graphical system programming should not remain vendor-bound by default,
  • why inspectable source and inspectable execution-facing artifacts matter,
  • why a public FIR bridge surface matters for hardware portability, runtime modularity, and compiler modularity,
  • why AI-assisted software creation increases the need for inspection and accountable understanding,
  • why the repository is built as a layered language stack rather than as one monolithic product,
  • why the ecosystem significance of FROG is larger than one implementation.

Without this strategic framing, the repository could be misread as:

  • just another graphical editor idea,
  • just a runtime experiment,
  • just an implementation workspace,
  • just a niche format proposal,
  • or just an open-source imitation of historical graphical tools.

That would be an incomplete reading. FROG is trying to establish an open language basis for graphical system programming that can support future validators, IDEs, runtimes, compilers, profiles, conformance growth, and industrial ecosystem participation.

The strategic claim is therefore broader: FROG attacks the structural lock-in of graphical industrial programming by opening the language layer itself: source, semantics, FIR, lowering, backend contracts, runtime-family boundaries, and compiler-family boundaries.

The post-AI claim is also broader: FROG addresses the growing accountability gap between software that can be produced very quickly and software that can be responsibly inspected, explained, validated, controlled, and maintained.

5. What Makes FROG Strategically Different

The strategic novelty of FROG does not come from any single isolated property. Graphical programming exists. Dataflow programming exists. Multi-target execution exists. Intermediate representations exist. AI-assisted tooling exists.

The strategic novelty of FROG is the way these ideas are combined into one open graphical language architecture.

FROG is strategically different because it combines:

  • graphical executable structure — computation is represented as explicit dataflow graphs rather than syntax-first instruction sequences,
  • open canonical source — the saved program is intended to remain structured, inspectable, machine-friendly, and independent from one IDE product,
  • open execution-facing FIR — the intermediate execution-facing representation is not treated as a hidden backend-private artifact,
  • runtime/compiler modularity — runtime families and compiler families are downstream consumers rather than definitions of the language,
  • hardware agnosticism — the language aims to remain upstream from any one processor family, operating system, device class, or vendor stack,
  • AI-era reviewability — the same structured artifacts that help machines generate and transform programs can also help humans inspect and audit them,
  • accountability-oriented architecture — source, validation, FIR, lowering, contracts, and runtime/compiler handoff can form a chain of responsibility rather than a single opaque generated artifact,
  • security through reduced opacity — the project’s credible security angle is traceability and auditability, not a claim that graphical form automatically guarantees safety.

The resulting strategic proposition is:

FROG is an attempt to open the foundational language layer of executable graphical programming, with an inspectable FIR able to serve as a bridge toward multiple runtimes, compilers, and hardware targets.

That is the category-level difference. FROG should not be reduced to an IDE, a runtime, a compiler target, a UI layer, or one reference implementation. Its strategic value is precisely that those downstream layers can remain modular while the upstream language basis stays open and inspectable.

The post-AI strategic difference is equally important: FROG can give organizations a way to turn fast-produced logic into staged, reviewable, attributable, and governable artifacts. That is a control problem, not merely a productivity problem.

6. FROG in the AI Era

FROG matters even more in the AI era than it would have in a purely manual-programming era.

Software artifacts are increasingly:

  • generated,
  • rewritten,
  • transformed,
  • assisted,
  • refactored,
  • explained,
  • reviewed,
  • validated.

through AI-assisted tooling or AI-adjacent pipelines.

That changes the strategic value of representation. A serious language infrastructure now needs to be:

  • structured enough for machine generation and transformation,
  • explicit enough for human review,
  • open enough for independent tooling,
  • layered enough to preserve meaning across validation and derivation stages,
  • stable enough to remain governable across version evolution.

FROG is well aligned with that requirement because:

  • the canonical .frog source is structured JSON,
  • the primary program structure is graphically reviewable,
  • the execution-facing FIR remains open and inspectable,
  • the backend/compiler path remains downstream rather than becoming hidden language truth,
  • the runtime path remains downstream rather than becoming hidden language truth,
  • the repository centralizes corpus-version posture and version doctrine rather than scattering it across unrelated documents.

This does not mean that textual languages cannot be audited. It means that FROG is designed to make structural review more direct by keeping the executable graph explicit across the language stack.

That is a strategic advantage, not just a cosmetic one. It reduces the auditability gap between:

  • what was generated,
  • what was saved,
  • what was validated,
  • what was derived,
  • what is handed downstream,
  • what is executed or compiled,
  • and what current version posture the published repository actually claims.

For AI-assisted development, this is critical. The more software is generated or transformed by tools, the more important it becomes to preserve inspectable structure across every stage of the pipeline. FROG is designed for that world.

The goal is not to reject generative AI. The goal is to make AI-assisted system creation governable. FROG can act as an architectural interface between rapid generation and responsible execution by turning generated or human-authored logic into structured, graphical, inspectable, and validated artifacts.

The source provenance direction makes this strategic claim more concrete: ide.provenance can carry signed or unsigned attestations for direct human authoring, AI assistance, tool generation, import, unknown origin, and human review. The strategic value is not a promise that provenance makes software safe; it is that review state and authoring evidence become visible instead of hidden.

7. Post-AI Accountability: Inspection, Responsibility, and Control

Generative AI changes the economics of software creation. It can produce code, tests, documentation, and system logic at a speed that traditional human review processes were not designed to absorb. This does not remove the need for responsibility. It makes responsibility harder.

In industrial contexts, software cannot only be produced. It must be understood, inspected, validated, attributed, maintained, and controlled. A generated artifact that cannot be explained, traced, or governed is not enough for serious system-grade deployment.

This creates a post-AI accountability gap. The scarce resource is no longer only the ability to produce software. The scarce resource becomes accountable understanding: the ability to know what was produced, what it means, who validated it, how it changed, what it will execute, and who remains responsible for it.

FROG is strategically relevant because it is designed around explicit intermediate artifacts rather than opaque production speed alone. It can provide a structured path through: 

human or AI-assisted intent
        |
        v
structured .frog source
        |
        v
graphical review
        |
        v
semantic validation
        |
        v
open FIR
        |
        v
lowering / backend contract
        |
        v
runtime or compiler family
        |
        v
observable execution path

This path matters because it gives organizations places to inspect, approve, test, attribute, reject, preserve, and evolve logic. It turns the output of fast creation into a sequence of reviewable stages.

In that sense, FROG is not merely a productivity architecture. It is a responsibility architecture. It helps answer industrial questions such as:

  • what logic is actually represented?
  • what version and source artifact does it come from?
  • what was generated, modified, or validated?
  • which semantics were accepted?
  • which FIR was derived?
  • which backend contract was handed downstream?
  • which runtime or compiler consumed it?
  • what behavior was expected?
  • what behavior was observed?
  • who can explain and maintain the result?

This is the strategic reason FROG matters in the generative AI wave. The answer is not to pretend that AI-assisted code generation will stop. The answer is to build language and tooling layers that make the resulting systems understandable, accountable, controllable, and evolvable.

8. Industrial Security and Technological Sovereignty

FROG is also strategically relevant because industrial systems increasingly depend on software that must remain:

  • reviewable,
  • portable,
  • traceable,
  • durable,
  • vendor-independent enough to remain governable over time.

That matters for industrial security. Critical logic should not have to disappear into opaque saved formats, opaque private execution layers, or one vendor-defined tooling stack in order to remain usable.

That also matters for technological sovereignty. A language ecosystem is more sovereign when:

  • the source representation is open,
  • the execution-facing representation remains inspectable,
  • multiple actors can implement compatible tooling,
  • compiler, runtime, IDE, and backend paths are not collapsed into one private authority,
  • version posture and transition doctrine remain publicly readable rather than hidden in one vendor lifecycle.

FROG therefore has strategic significance beyond developer ergonomics. It can support an open, inspectable, portable, and governable programming foundation for industrial and strategic software ecosystems.

The security claim must remain disciplined. FROG should not claim that graphical form automatically guarantees security. Its stronger and more credible claim is that open source artifacts, explicit graph structure, inspectable FIR, explicit backend contracts, and readable governance reduce structural opacity and make review more direct.

The accountability claim follows the same discipline. FROG does not make responsibility automatic. It creates a structure in which responsibility can be assigned, reviewed, tested, and preserved more explicitly than in opaque generation-to-execution flows.

9. Hardware Agnosticism and Open FIR Modularity

FROG’s hardware-agnostic ambition is not only a portability slogan. It is tied to the architectural role of FIR.

The open FIR is the intended bridge surface between the upstream graphical language and downstream execution families. Because that bridge surface is public and inspectable, downstream implementations can target different execution strategies without redefining the language itself. 

canonical .frog source
        |
        v
validated program meaning
        |
        v
open execution-facing FIR
        |
        +-----------------------------+-----------------------------+
        |                             |                             |
        v                             v                             v
runtime-family bridge        compiler-family bridge        hybrid bridge
        |                             |                             |
        v                             v                             v
operational runtimes          native artifacts              target-specific mixes
Python / Rust / C++           LLVM / vendor compilers       runtime + compiled execution
        |                             |                             |
        +-----------------------------+-----------------------------+
                                      |
                                      v
                         heterogeneous hardware targets

This is why FROG can credibly speak about hardware agnosticism and hyper-modularity. The strategic idea is not that one runtime magically runs everywhere. The idea is that one open graphical language stack can preserve an inspectable execution-facing representation from which multiple runtime, compiler, and hardware bridges can be built.

This resembles the role that durable intermediate and system-level representations have played in other ecosystems: not because FROG is the same kind of language as C, but because FROG aims to create a stable upstream layer from which many downstream hardware strategies can be reached.

That distinction is essential. FROG should not overclaim that every target is already supported. It should claim, more precisely, that its architecture is designed so that target-specific support can be added without turning any one target into the definition of the language.

10. Relation with the Rest of the Repository

The Strategy layer should be read together with, but distinctly from, the other repository layers. 

Readme.md                   -> repository-wide architectural entry point
Strategy/                   -> why the project matters
Roadmap/                    -> in what order closure should happen
Versioning/                 -> what the current corpus version is and how version transitions are governed
Expression/                 -> what is saved and structurally valid
Language/                   -> what validated programs mean
IR/                         -> what validated meaning becomes in execution-facing form
Conformance/                -> what should be accepted, rejected, and preserved
Implementations/Reference/  -> how a bounded subset is currently exercised

This separation matters because FROG needs:

  • architecture,
  • strategy,
  • roadmap,
  • versioning,
  • conformance,
  • reference proof

without allowing any one of those layers to silently replace the others.

The Strategy layer can explain why Example 05 matters as a frozen bounded corridor, why the runtime-family acceptance path matters, and why LLVM proof paths are strategically relevant. It must still leave the actual current status of those surfaces to the owning documentation and to Versioning/.

The Strategy layer can also explain why post-AI accountability matters. It must still leave concrete validation, conformance, runtime behavior, and version truth to their owning layers.

11. Relation with Roadmap and Versioning

The repository contains three distinct repository-wide framing and governance surfaces that answer three different questions:

Surface Primary question What it must not replace
Strategy/ Why does FROG matter? Normative technical ownership, closure sequencing, or current corpus-version truth
Roadmap/ In what order should FROG be closed? Normative technical ownership, strategic rationale, or current corpus-version truth
Versioning/ What is the current published specification corpus version, what is the additive-evolution doctrine, and what is the current detailed per-surface status? Normative technical ownership, strategic rationale, or milestone sequencing

This means:

  • Strategy explains the why,
  • Roadmap explains the next,
  • Versioning explains the current published version posture.

The strategic layer may refer to the current published baseline, but it should not become the authoritative source for the current corpus version or for the detailed status of repository surfaces. When that information is needed, the authoritative repository-visible entry points are:

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

12. Current Strategic Entry Point

At the current published repository state, the main strategic framing document is: 

Strategy/Heilmeier/Readme.md

That document explains the technological purpose, gap, expected impact, risks, and long-term program logic of FROG in a structured mission-oriented form.

The role of this directory-level Readme.md is different. It serves as the strategic entry point for the Strategy/ layer as a whole and clarifies how strategic framing should coexist with the normative specification, the roadmap, and the centralized versioning surface.

Together, these strategy documents should make one message unavoidable: FROG is not only a graphical programming proposal. It is an attempt to open the language and bridge infrastructure underneath executable graphical programming.

They should also make another message clear: FROG is not anti-AI. FROG is an attempt to make AI-accelerated software creation inspectable, attributable, controllable, and evolvable in serious industrial settings.

13. Strategic Boundaries to Preserve

The Strategy layer should preserve the following distinctions:

  • strategy vs normative specification,
  • strategy vs roadmap sequencing,
  • strategy vs version-governance truth,
  • strategic motivation vs semantic ownership,
  • AI compatibility vs AI dependence,
  • AI accountability vs a claim that AI-generated logic is automatically trustworthy,
  • auditability improvement vs exaggerated security claims,
  • hardware agnosticism vs claims of already supporting every hardware target,
  • open FIR as a bridge surface vs one backend becoming language truth,
  • open language vs one implementation,
  • technological sovereignty vs branding control.

In particular:

  • FROG should not claim that graphical form automatically guarantees security,
  • FROG should not claim that textual languages cannot be reviewed,
  • FROG should not claim that AI-generated logic becomes safe merely by being expressed in FROG,
  • FROG should not claim that all runtime and compiler targets are already complete,
  • FROG should not claim that strategy prose is a substitute for current repository status reporting,
  • FROG should claim, more narrowly and more credibly, that its architecture reduces opacity by combining structured source, explicit graph reviewability, inspectable execution-facing representation, open downstream bridge boundaries, and centralized readable version posture.

This discipline makes the strategic claim stronger. FROG does not need exaggerated promises to be ambitious. Its real ambition is already large: opening the foundational layer of executable graphical programming and making post-AI software creation more inspectable and governable.

14. Summary

The Strategy/ layer exists to explain why FROG matters as a long-term technological program.

Its role is to make explicit that FROG is not only:

  • an open graphical language,
  • a dataflow architecture,
  • a compiler/runtime preparation effort.

It is also:

  • a response to opaque graphical ecosystems,
  • a response to vendor-bound industrial programming stacks,
  • a response to AI-era auditability needs,
  • a response to the post-AI accountability gap between fast generation and responsible understanding,
  • a response to industrial reviewability requirements,
  • a response to technological sovereignty concerns in strategic software systems,
  • and a proposal for an open graphical language layer whose FIR can become a public bridge surface toward multiple runtimes, compilers, and hardware targets.

That is why the Strategy layer exists, and why it must remain explicit, non-normative, clearly separated from the specification layers, clearly separated from roadmap sequencing, and clearly separated from centralized corpus-version reporting.

The strategic message should remain simple:

FROG is an open attempt to make executable graphical programming inspectable, hardware-agnostic, AI-compatible, and modular across runtime and compiler families by opening the language layer and its FIR bridge surface.

In the generative AI era, FROG also addresses a new industrial scarcity: not the ability to produce more software, but the ability to inspect, understand, control, assign responsibility for, and evolve what has been produced.