Governance model for the FROG specification repository
FROG — Free Open Graphical Language
- 1. Overview
- 2. Governance Goals
- 3. Scope of Governance
- 4. Repository Layers and Governance Boundaries
- 5. Repository-Wide Framing and Governance Surfaces
- 6. Stewardship
- 7. Open Specification and Multiple Implementations
- 8. Decision Model
- 9. Proposal and Change Process
- 10. Compatibility, Versioning, and Deprecation
- 11. Repository Contributions and Licensing
- 12. Commercial Implementations and Ecosystem Participation
- 13. Support Claims, Conformance, and Certification
- 14. Trademarks, Branding, and Official Claims
- 15. Commercial vs Non-Commercial Certification Direction
- 16. Future Governance Evolution
- 17. Non-Goals
FROG is an open language specification for graphical dataflow programming. Its purpose is to define a durable, tool-independent, and vendor-independent foundation for executable graphical programs, intrinsic primitive vocabularies, optional standardized capability profiles, and related program representations.
This governance document defines how the specification repository is stewarded, how changes are evaluated, how architectural coherence is preserved, and how an open specification may coexist with multiple independent implementations.
This document governs the specification repository. It does not require any implementation to be open source, and it does not prohibit any party from building commercial tools, runtimes, compilers, integrations, services, or full IDE platforms around the FROG specification.
This document governs the specification repository and its repository-level governance boundaries. It does not, by itself, fully define pricing, trademark procedure, detailed certification contracts, or every future business policy. Those topics MAY be defined in separate policy documents if and when such documents are published.
High-level governance model
open specification
+
steward-led repository governance
+
multiple independent implementations
+
separate conformance / certification / branding authority
The governance of FROG exists to preserve the following goals:
- keep the specification open, readable, and implementable by independent parties,
- preserve long-term architectural coherence across the repository,
- avoid collapse of the language into one IDE, one runtime, one compiler, one profile implementation, or one hardware vendor,
- allow responsible evolution of the specification over time,
- support a healthy ecosystem of open and commercial implementations,
- keep a clean distinction between the core language, optional standardized profiles, and implementation-specific extensions,
- preserve a clear distinction between normative specification, strategic framing, roadmap sequencing, current corpus-version governance, conformance posture, and reference implementation work,
- protect the integrity of official FROG branding, certification, and compatibility claims.
Governance should also preserve a credible long-term position for FROG as:
- an open language specification rather than a product-bound format,
- a reviewable and inspectable programming foundation,
- a language architecture compatible with AI-era program generation and transformation,
- a language ecosystem compatible with industrial security and technological sovereignty concerns.
This document applies to the governance of the FROG specification repository, including:
- the language specification,
- source-level program representation,
- execution-related specification layers when published,
- intrinsic standardized primitive-library specifications,
- optional standardized profile specifications,
- IDE architecture specifications,
- repository-level conformance material,
- repository-level strategic framing documents,
- repository-level roadmap documents,
- repository-level versioning-governance documents,
- related architectural and normative documents contained in this repository.
This document does not, by itself, fully define:
- detailed commercial pricing,
- marketplace terms,
- OEM commercial agreements,
- detailed trademark law,
- detailed certification contracts,
- all future certification program procedures.
Those topics MAY be defined more precisely in separate policy documents if and when such documents are published.
Governance scope This document governs: - repository stewardship - editorial direction - specification evolution - repository-level architectural authority - repository-level governance boundaries This document does not fully govern: - detailed commercial terms - fee schedules - legal trademark procedure - full certification operations manual
The FROG repository contains multiple layers with different roles. Governance must keep those roles distinct.
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 IDE/ -> authoring, observability, debugging, inspection Examples/ -> named example programs Conformance/ -> public accept / reject / preserve expectations Implementations/Reference/ -> non-normative executable workspace Strategy/ -> non-normative strategic framing Roadmap/ -> non-normative closure sequencing Versioning/ -> current corpus-version governance and current-status reporting
These distinctions matter. In particular:
- Strategy explains why FROG matters, but does not define language truth.
- Roadmap explains in what order FROG should be closed, but does not define language truth.
- Versioning defines current published corpus-version posture and cross-version governance, but does not define language semantics or roadmap ordering.
- Conformance exposes public expected outcomes, but does not silently replace semantic ownership.
- Implementations/Reference exercises a bounded executable path, but does not become normative merely by existing.
Governance must therefore preserve not only openness and implementability, but also the internal separation between:
- what is normative,
- what is strategic,
- what is sequencing guidance,
- what is current corpus-version truth,
- what is conformance truth surface,
- what is executable reference proof.
The repository now 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 doctrine governs version evolution, and what is the current detailed per-surface status? | Normative technical ownership, strategic rationale, or milestone sequencing |
This distinction is governance-relevant because it prevents repository-wide confusion between:
- purpose,
- sequencing,
- current version truth.
Governance should preserve this tri-distinction explicitly.
Repository-wide purpose belongs to Strategy/.
Repository-wide closure order belongs to Roadmap/.
Current published corpus-version truth and current detailed status belong to Versioning/.
Graiphic is the initial steward of the FROG specification repository. As steward, Graiphic is responsible for maintaining architectural coherence, reviewing proposed changes, deciding when documents are sufficiently mature for inclusion, and publishing authoritative repository revisions.
Stewardship of the repository does not mean that FROG is a vendor-locked product. The purpose of stewardship is to keep the specification coherent while the language is still being actively defined, cleaned up, and stabilized.
The steward SHOULD make decisions in a way that preserves:
- openness of the specification,
- clarity of normative wording,
- implementability by third parties,
- backward compatibility when reasonably possible,
- separation between the standard and any one implementation,
- clear boundaries between intrinsic libraries, profiles, and implementation-specific extensions,
- clear boundaries between specification, strategy, roadmap, versioning, conformance, and reference implementation work.
Stewardship is not: - implementation monopoly - runtime monopoly - IDE monopoly - ecosystem exclusivity Stewardship is: - repository authority - editorial authority - architectural coherence authority
FROG is an open specification. Any party MAY read, implement, validate, parse, compile, interpret, transform, or otherwise build tooling around the published FROG specification, subject to the repository license and any separately published policies.
The FROG specification is intended to support multiple independent implementations, including but not limited to:
- IDEs,
- validators,
- runtimes,
- compilers,
- bridges and interoperability layers,
- hardware integration libraries,
- profile-supporting execution environments,
- testing and conformance tooling.
No implementation is automatically normative merely because it exists. The repository documents are the normative source of the specification unless a document explicitly states otherwise.
An implementation MAY support:
- core FROG only,
- core FROG plus one or more standardized profiles,
- core FROG plus profiles plus additional proprietary or open extensions.
Support for optional profiles is not automatically required for core language support unless a future policy explicitly defines a stricter conformance target.
Open specification does not mean: one implementation or one business model Open specification means: many parties may implement the same published standard
This openness is also one of the reasons FROG can credibly support:
- reviewable and inspectable software pipelines,
- AI-assisted generation and transformation on open artifacts,
- long-term industrial portability,
- technological sovereignty through independent implementation.
Source provenance follows the same governance model. The open specification may define the shape of ide.provenance attestations, but no single IDE is required to be the only possible issuer. Graiphic may maintain proprietary signing infrastructure, certified issuer programs, or product-specific trust policies while the source format remains open to conforming third-party IDEs and organizational trust policies.
FROG governance currently follows a steward-led model. Discussion is open, contributions are welcome, and architectural feedback is encouraged, but final editorial and architectural decisions for this repository are made by the steward.
In practice:
- contributors MAY propose changes, clarifications, corrections, and new specifications,
- maintainers review proposals for coherence, maturity, and alignment with repository direction,
- the steward decides whether a proposal is accepted, rejected, deferred, split, redirected, or accepted in a narrower form.
The steward SHOULD explain major architectural decisions when such explanation materially helps contributors understand repository direction.
Decision-making SHOULD also respect repository layer boundaries. For example:
- a strategic concern does not automatically justify a semantic change,
- a roadmap desire does not automatically justify normative wording,
- a versioning-governance clarification does not automatically justify semantic change,
- a reference implementation shortcut does not automatically justify a specification change.
Decision flow proposal -> review -> architectural evaluation -> accept / revise / split / defer / redirect / reject
The normal change path for the specification is:
- identify a problem, ambiguity, inconsistency, or missing specification area,
- discuss the topic through repository issues, pull requests, or equivalent review channels,
- propose concrete wording changes or new documents,
- review the proposal against repository architecture and directly related specifications,
- accept, revise, defer, split, redirect, or reject the change.
Specification changes SHOULD be:
- explicit,
- conservative when modifying existing normative behavior,
- clear about whether they are corrective, additive, or breaking,
- cross-checked against directly related documents,
- clear about whether they affect the core language, an intrinsic library, a profile, an IDE-facing concern, a strategic framing layer, a roadmap layer, or the centralized versioning surface.
Editorial cleanup, factual corrections, and cross-reference alignment MAY be accepted with a lighter process than major semantic changes. Major semantic changes SHOULD be reviewed more carefully because they may affect multiple specification layers and future implementations.
Change discipline Small editorial fix -> lighter review Cross-layer semantic change -> deeper review -> stronger architectural scrutiny
The FROG specification SHOULD evolve in a way that preserves continuity whenever reasonably possible. However, early-stage specification work may still require structural correction and architectural refinement.
Changes SHOULD be understood under three categories:
- clarification — wording becomes clearer without changing intended semantics,
- additive change — new capability is introduced without invalidating existing compliant content,
- breaking change — previously valid content, assumptions, or interpretations may no longer remain valid.
Breaking changes SHOULD be introduced deliberately and documented clearly. Where appropriate, the repository SHOULD describe migration direction, replacement constructs, or deprecation rationale.
The repository-wide doctrine for current corpus-version governance, additive evolution, degraded readability posture, and current detailed per-surface status belongs centrally in Versioning/.
This governance document recognizes that surface and protects its role, but does not attempt to duplicate its full policy here.
Change classes clarification -> clearer wording, same intended meaning additive -> more capability, existing compliant content remains valid breaking -> migration may be required
Repository contributions are governed by the repository license, contribution workflow, and contributor license agreement requirements published in the root of the repository. Contributors MUST follow the contribution process in effect for this repository.
Acceptance of a pull request is not automatic. All contributions remain subject to repository review and steward approval.
This governance document does not replace the repository license, contributor license agreement, or contribution policy. If any conflict appears, the applicable legal and contribution documents govern their own scope.
Open specification does not imply implementation uniformity. Open specification also does not prohibit commercial implementations.
Any party MAY build open-source or proprietary implementations around the FROG specification, including IDEs, compilers, runtimes, libraries, profiles, integration layers, deployment systems, and commercial services. Graiphic MAY independently develop proprietary or commercial implementations, enterprise tooling, OEM integrations, plugin ecosystems, marketplaces, hosted services, support offerings, certification programs, and other products around FROG.
Such implementations do not redefine the specification merely by existing. The specification remains governed by the normative repository documents.
The public FROG repository and Graiphic proprietary implementations have distinct roles. The public repository governs the open specification and its bounded public reference material. Graiphic proprietary repositories may contain production-grade IDE, runtime, deployment, integration, certification, and enterprise product code.
The existence of a Graiphic proprietary runtime or IDE does not change the public specification.
Conversely, the presence of a public reference runtime in this repository does not require Graiphic to publish its production runtime implementation.
The public reference runtime is a conformance-oriented proof surface.
It is not the mandatory runtime architecture for all implementations and it is not Graiphic's production runtime.
In this public repository, that reference runtime surface is currently bounded to Examples 01 through 15.
Runtime development for later examples continues in Graiphic's proprietary Graiphic/FROG-Runtime repository unless a later public reference surface is explicitly promoted.
Open spec does not forbid commercial implementation Commercial implementation does not redefine the specification
This coexistence is deliberate. FROG is intended to support an ecosystem in which:
- the language remains open,
- implementation diversity remains possible,
- commercial participation remains possible,
- official certification and branding remain separately governable.
The governance of FROG SHOULD distinguish clearly between support claims, conformance claims, and certification claims. Those are related, but they are not the same thing.
A future conformance policy SHOULD distinguish at least the following categories:
- implements core FROG — the implementation claims support for the core language surface only,
- implements core FROG + named profiles — the implementation claims support for the core language plus one or more explicitly identified standardized profiles,
- conformant implementation — the implementation satisfies the requirements of the claimed conformance target under an applicable conformance policy,
- certified implementation — the implementation has been verified and approved under an applicable certification or branding policy.
A claim of profile support SHOULD identify the supported profile explicitly rather than implying universal support for all optional capability families in the repository.
Support for a profile MUST NOT, by itself, be treated as support for all profiles. Likewise, lack of support for a profile MUST NOT, by itself, be treated as failure of core language support unless the claimed target explicitly includes that profile.
Do not collapse these categories
support claim
!= conformance claim
!= certification claim
Example:
"supports core FROG"
is not the same as
"certified FROG implementation"
These distinctions are especially important because:
- the language must remain open,
- implementation diversity must remain possible,
- public trust in official claims must remain defensible.
The openness of the FROG specification does not automatically grant trademark rights. Names, logos, certification marks, and official compatibility claims are governed by the steward and MAY be subject to separate policies.
An implementation MAY implement the FROG specification without being an official Graiphic product. However, terms such as official, certified, endorsed, FROG-certified, or equivalent claims SHOULD only be used in accordance with applicable trademark, certification, or conformance policies published by the steward.
This distinction exists so that:
- the language specification remains open,
- independent implementations remain possible,
- official branding and certification claims remain governable and trustworthy.
Open specification
does not automatically grant
official branding rights
Implementing FROG
does not automatically mean
official / certified / endorsed
This boundary is also important for sovereignty and public trust. An open language should remain independently implementable without confusing that openness with official steward-controlled marks.
The steward MAY define a certification and branding program for implementations that wish to use official FROG certification, official branding, or equivalent steward-controlled marks.
The intended direction is:
- commercial implementations that seek official certification, official branding, or equivalent steward-controlled compatibility recognition MAY be subject to paid verification, licensing, or program fees,
- non-commercial implementations MAY be verified and certified free of charge or at minimal cost, subject to steward review and applicable policy,
- the specification itself remains open regardless of whether an implementation participates in any certification or branding program.
This distinction exists to preserve openness of the language specification while allowing the steward to govern the FROG name, branding integrity, and certification responsibility over time.
More detailed rules, procedures, fee schedules, eligibility conditions, and branding requirements MAY be defined later in separate policy documents.
Direction of travel
open specification for everyone
+
optional official certification path
+
commercial official certification may be paid
+
non-commercial official certification may be free or low-cost
The current governance model is intentionally simple and steward-led. As the ecosystem matures, governance MAY evolve.
Possible future evolutions MAY include:
- a documented review board,
- formal change proposals,
- a conformance working group,
- shared editorial maintainership,
- an independent foundation or multi-party governance structure.
Any such change SHOULD preserve the core goals of openness, implementability, architectural coherence, branding clarity, and long-term ecosystem durability.
Any future governance evolution SHOULD also preserve the internal repository distinctions between:
- normative ownership,
- strategic framing,
- roadmap sequencing,
- current corpus-version governance,
- conformance truth surface,
- reference implementation proof.
This document does not attempt to:
- freeze the future institutional structure of FROG,
- define detailed trademark law or certification contracts,
- mandate that implementations be open source,
- mandate that implementations be proprietary,
- select a single business model for Graiphic or for the ecosystem,
- force all implementations to support the same optional profiles,
- replace strategy documents with governance,
- replace roadmap sequencing with governance,
- replace versioning governance with governance,
- replace normative specification with governance.
Its purpose is narrower: to state how the specification repository is governed, how openness is preserved, how repository-layer boundaries are protected, how branding and certification authority are separated from the open language itself, and how multiple implementations may coexist without collapsing the language into a single vendor product.
FROG — open specification, durable governance, multiple implementations