How I Built an Open Format and a Free Web Tool for Live Hierarchy Modelling

Иван Кравченко — Fri, 03 Jul 2026 10:04:24 +0000

I often take part in strategy sessions where a company’s organisational, functional, or product structure has to be built right in the middle of the conversation.

The first diagram appears on screen. Someone says, “No, this function should not be here.” Another person adds a new role. A third asks to temporarily hide half the branch so they can explain the idea to the CEO. Twenty minutes later, the structure no longer looks like the one we started with.

And that is the point where almost any ordinary diagram starts getting in the way.

The people in those sessions are usually not analysts, process architects, or technical specialists. They are commercial, operational, or administrative leaders. They should not have to learn how to draw a box correctly, connect it with an arrow, or choose the right relationship type. They need to discuss the business itself.

Almost like children. And that is not criticism: when adults are solving a difficult problem together, the interface should disappear from their attention too.

That experience gave me a list of requirements for the tool.

What needs to happen during a live session

The tool should run almost anywhere and on almost any device, without installing heavy third-party or licensed software.
The model should look presentable enough for a large screen, an executive, or a decision review, without being overloaded with professional notation.
The structure should be built as a model, not manually drawn from boxes and arrows.
Participants should be able to change it during the discussion: drag blocks, change reporting lines, group them, hide unnecessary parts, adjust formatting, and quickly bring attention back to the relevant branch.
The same model should be readable in different ways: as a classic vertical hierarchy and as a horizontal flow, closer to a responsibility chain, functional flow, or mind map.
The model should have a single numeric dimension: budget, timeline, headcount, effort, workload, or another measure. That value should aggregate across an entire branch instead of living as a separate label on each block.
The result should not be locked inside one application. It should be possible to transfer it as graphics, tables, interactive HTML, and machine-readable code.
The model’s content should be easy to analyse and improve with the user’s own AI tool, rather than requiring it to be sent to a built-in corporate API.
Finally, these models almost always contain sensitive data: names, salary ranges, budgets, commercial assumptions. They should not have to be uploaded to yet another cloud service unless necessary.

I could not find a ready-made tool that brought all of this together, so I decided to make my own.

But I quickly realised that one application was not enough.

I had to build two things

The first is ORGF, an open format for hierarchical models.

The second is ORGFORMAT Studio, a free browser application that can open, display, and edit those models visually.

The idea behind ORGF is simple: a model should not exist only as an image, a screenshot, or a file owned by one vendor. It should be ordinary readable text that can be shared with another person, opened in another tool, validated, used as input for AI, or transformed into another representation.

I chose YAML because it is simple enough to read with your eyes while still being understandable to software and AI.

reference:
  format: "ORGF 1.0.0"
  syntax: "YAML|UTF-8 without BOM"

  sections_fixed:
    orgformat: "string|required"
    reference: "section|optional"
    meta: "section|required"
    model: "section|optional"
    root: "block|required"
    hierarchy: "root.children[*].children[*]..."

  meta:
    title: "string|max250|optional"
    author: "string|max250|optional"
    rights_holder: "string|max250|optional"
    copyright: "string|max500|optional"
    license: "string|max120|optional"
    created: "string|optional|YYYY-MM-DD/ISO 8601"
    updated: "string|optional|YYYY-MM-DD/ISO 8601"
    status: "draft/final/archived|optional"

  model:
    name: "string|max250|optional"
    desc: "string|max1000|optional"
    value_label: "string|max80|optional|one_value_type_per_model"
    value_unit: "string|max40|optional|one_value_unit_per_model"

  block:
    name: "string|max250|optional|empty_allowed"
    desc: "string|max500|optional"
    value: "number|optional|own_value_only"
    pic: "section|optional"
    pic.set: "emoji/lucide/feather/simple-icons/iconify|required_if_pic"
    pic.name: "string|required_if_pic"
    tags: "array[string|max80]|optional|default:[]"
    hidden: "boolean|optional|default:false"
    branch_orientation: "auto/horizontal/vertical|optional|default:auto"
    style:
      fill: "default/#HEX|optional|default:default"
      contour: "default/solid/dashed/dotted/double|optional|default:default"
      contour_width: "default/regular/bold|optional|default:default"
    relation:
      line: "default/solid/dashed/dotted|optional|default:default"
      line_width: "default/regular/bold|optional|default:default"
      color: "default/#HEX|optional|default:default"
    children: "array[block]|optional|default:[]"

  authoring_rules:
    - "one_file=one_model"
    - "hierarchy=children"
    - "no_id_parent_order"
    - "empty_blocks_allowed"
    - "tags=plain_classifiers_not_key_value"
    - "desc=short_human_note_not_data_dump"
    - "style_relation=custom_overrides_only"
    - "tag_colors_not_stored_in_orgf"
    - "value_one_type_per_model"
    - "value_one_unit_per_model"
    - "value_on_block_is_own_value_only"
    - "value_totals_are_computed_not_stored"
    - "reference_if_present=complete_unmodified_canonical_copy_published_for_declared_orgformat_version_at_https://github.com/orgformat/orgf/releases"
    - "hidden=true_on_a_block_requires_hidden=true_on_every_descendant"

  normalization:
    unknown_fields: remark
    invalid_values: default
    over_limit: truncate
    invalid_yaml: reject
    invalid_structure: reject

  normalization_rules:
    - "missing_optional=default"
    - "unknown_fields=remark"
    - "invalid_values=default"
    - "over_limit=truncate"
    - "normalization=view_only_not_source_mutation"
    - "hidden_branch_inconsistency=remark_not_reject"
    - "normalization_propagates_hidden=true_to_all_descendants"

The ORGF format itself, the reference, and the validator are published under the MIT licence. It is not just a file for Studio: it can be used independently from Studio too.

Why this is more than just a diagram

ORGF has three simple mechanisms that, for me, turn a hierarchy from a picture into a working model.

Value: a structure with an economic dimension

Each block can have a numeric value, and the model aggregates it across the entire branch.

That value can represent budget, headcount, effort, timeline, workload, or any other single measure. So when discussing a new structure, you can see not only how reporting lines or functional decomposition change, but also how its numeric scale changes.

ORGF does not claim that it can automatically measure a company’s effectiveness on its own. But it creates a simple bridge between a structural decision and its economic evaluation.

Tags: some systematisation without a heavy database

Blocks can be marked with tags such as sales, critical, remote, contractor, region-eu, planned, or any other custom attribute.

This gives the hierarchy a lightweight systemic layer. You can describe function types, statuses, roles, regions, skills, or other characteristics without building a separate database or burdening the model with a technical schema.

In practice, it becomes a small domain database — but in a form that can still be opened, understood, and discussed during a normal working meeting.

AI-ready: not an embedded agent, but work with your own AI

I deliberately chose not to build an intrusive AI agent into Studio through an API.

First, that usually means extra costs, keys, limits, and dependency on a specific provider. More importantly, users often already have their own AI tool where they have discussed the task, collected source information, and built up context.

It is more logical to send the machine-readable ORGF model to that AI: ask it to add branches, restructure roles, extend tags, recalculate values, or create a new version of the structure based on the inputs already discussed.

The updated file can then be opened in Studio and checked visually. AI does not replace a human decision, but it removes the manual work of transferring content into the model.

Why local-first instead of “just another cloud service”

Studio runs in the browser, but ordinary work with a model remains local: the data is stored in the browser’s local storage.

This is not a religious war against the cloud. Cloud solutions can be useful for collaboration and more complex scenarios. But for the first version, it was important to me not to force someone to upload a sensitive company model to another server just to quickly build or discuss a structure.

Open the browser, build a model, save the file, send it to a client or colleague — without mandatory accounts, subscriptions, or “your data will be processed in accordance with...”.

One model, several ways to read it

I am not trying to build another ARIS, Visio, HRIS, or universal BPM platform.

ORGF is intentionally limited to strict hierarchies without cross-links. This is not “something missing that needs to be fixed urgently.” It is a deliberate boundary based on the hierarchy of objects and direct responsibility for data.

When the main task is to quickly agree on a structure of responsibilities, functions, roles, WBS, classifications, or catalogues, a tree is often more useful than a universal graph. It preserves clarity: every block has its place, its parent, and an understandable responsibility branch.

But the same model does not have to be read only from top to bottom.

I recently added a horizontal flow view to Studio. The data does not change. It is still the same hierarchy, but it becomes easier to read from left to right: as functional decomposition, a responsibility chain, or a sequence of levels.

In both views, card details, search, Highlight, dark mode, Drag-and-Drop, and export to SVG or standalone interactive HTML are available.

Hierarchies are not only org charts

After building the first business model, I quickly realised that the format did not have to stay limited to HR or consulting.

Hierarchies appear in history, education, project management, catalogues, classifications, and even children’s materials. That is why the demos include ruling dynasties, an animal atlas, and other cases.

In one case, value can mean budget. In another, person-hours. In a third, years of a dynasty’s rule. Formally, it is the same mechanism: the model aggregates one indicator across a branch, while the user decides what that indicator represents.

The project took one very intense month. It is not yet an “ideal platform for everyone.” It is a working attempt to make models easier to create, clearer to discuss, and freer to transfer between people and tools.

I would be especially interested in criticism on three questions:

Where would a format or tool like this be most useful outside organisational structures?
What would you want to change — or try to break — first?
Should an open hierarchy format remain narrow and simple, or will it inevitably need to grow towards graphs, processes, and more complex semantics?

DEV Community: Иван Кравченко