Model Weave: Markdown-based ER / Class / DFD modeling in Obsidian

[nejimakibird]

Plugin/Theme Disclaimer

Is this project open source? Yes
Is this project completely free? Yes
Is this project vibe-coded beyond the author’s ability to comprehend how it works? No
Community Directory: Model Weave - Obsidian Plugin

---

GitHub:

GitHub - nejimakibird/model-weave: Text-first modeling plugin for Obsidian using...

Disclaimer:
I am the author of this plugin.

Model Weave — text-first modeling for software design in Obsidian

Hi everyone,

I would like to share my Obsidian plugin, Model Weave.

Model Weave is a text-first modeling plugin for Obsidian.
Markdown model files are the source of truth, and diagrams, previews, diagnostics, and PNG exports are generated from those Markdown files.

The plugin is currently focused on software and design modeling workflows, including:

• Class models
• ER models
• DFD / flow-oriented models
• Data objects
• Experimental formats such as screens, app processes, rules, mappings, code sets, and messages

The main idea is to keep design information in Markdown, while using generated views for review, navigation, and visualization.

Why I built it

I wanted a lightweight way to manage software design models inside Obsidian without making diagrams the source of truth.

Instead of editing a diagram directly, the Markdown file remains the canonical design asset.
The plugin then generates visual views from that text.

This makes it easier to:

• keep design documents in a vault
• manage them with Git
• review relationships visually
• export diagrams as PNG
• use Obsidian links and Markdown-based workflows
• combine human-written notes with AI-assisted drafts

Recent dogfooding experiment

Recently, I have been using Model Weave to model Model Weave itself.

This helped me explore a workflow where AI generates or updates structured Markdown design models from source code and documentation, while a human reviews the result.

One important lesson was that AI-generated design models need clear structure and validation rules.
For example, Markdown table headers must remain compatible with the expected model format, and model elements are much more useful when they can link back to the source code they describe.

In recent versions, I have also been improving workflows around Source Links and code jumping, so a model can act not only as a diagram, but also as a map back to the implementation.

Feedback welcome

I would be happy to hear feedback from people who use Obsidian for:

• software design notes
• architecture documentation
• Markdown-based modeling
• AI-assisted knowledge work
• reverse engineering or source-code documentation

I will keep future updates about this plugin in this thread.

[nejimakibird]

Model Weave 0.1.4 has been released.

This update focuses on startup performance and documentation improvements.

Changes:

• Improved startup performance with lightweight indexing and lazy parsing.

• Reduced false unresolved-member warnings when models are still shallow-loaded.

• Updated README / README_JP with Source Links, localSourceRoot, and performance notes.

Model Weave is now available from Obsidian Community Plugins, and you can update from Obsidian’s plugin settings.

[nejimakibird]

Model Weave 0.1.5 / 0.1.6 update

Hi everyone,

I released Model Weave 0.1.6.

I missed posting the previous 0.1.5 update here, so this is a combined update for both 0.1.5 and 0.1.6.

0.1.5 highlights

Version 0.1.5 focused mainly on improving the connection between Markdown design models and the implementation files they describe.

The main addition was the Source Links workflow.

Model files can include a ## Source Links section to point to related source files, tests, configuration files, SQL files, sample data, or other local references.

When localSourceRoot is configured, relative Source Links can be resolved outside the Obsidian vault, and the preview can show the original path, resolved path, status, notes, and actions such as copying or opening the path.

This is especially useful when using Model Weave as a lightweight map from design models back to source code.

0.1.6 highlights

Version 0.1.6 continues improving the modeling and preview experience.

Main changes include:

• Added / improved app process business flow support
• Added related documentation and samples for app process business flow modeling
• Improved Mermaid chart readability in dark mode
• Improved fit behavior for wrapped class cards in previews

The app process business flow work is part of a longer direction for Model Weave: representing not only static structures such as Class / ER / DFD models, but also business processes, screens, rules, mappings, and data flow relationships in Markdown.

Dogfooding model

I have also been dogfooding Model Weave by modeling Model Weave itself.

The dogfooding model is useful as an example of how Model Weave can be used to map relationships between:

• plugin features
• Markdown model formats
• documentation
• source files
• future design ideas
• AI-assisted documentation workflows

Dogfooding repository:

GitHub - nejimakibird/model-weave-dogfood: This is a sample vault that expresses the...

Why this matters

Model Weave is intended to keep Markdown as the source of truth, while diagrams, previews, diagnostics, and PNG exports are generated views.

The recent Source Links and app process improvements are steps toward making the model useful not only as a diagram, but also as a reviewable map between:

• design notes
• structured Markdown models
• business flow / process definitions
• implementation files
• AI-assisted documentation workflows

Feedback is welcome, especially from people using Obsidian for software design notes, architecture documentation, business process modeling, or source-code documentation.

[nejimakibird]

Model Weave 0.1.8 released

Model Weave 0.1.8 has been released.

Model Weave is an Obsidian plugin for managing text-first software design models in Markdown, with generated previews, diagrams, diagnostics, relationships, and source links.

This release includes the changes from 0.1.7 and 0.1.8 since the previous public release.

What is new

Relationship View

Model Weave can now show relationships around the current model more clearly.

The Relationship View helps you check:

• models referenced by the current file
• models that reference the current file
• unresolved references
• related Source Links

This makes it easier to navigate a growing set of design documents and review the impact of changes.

CodeSet / State Usage

CodeSet values and state-like values can now be tracked more effectively.

This helps answer questions such as:

• where a status value is used
• which screen or process depends on a state
• which flow branch uses a specific value
• whether a value appears to be unused or inconsistent

This is useful for business statuses, UI states, process conditions, and internal workflow states.

Improved documentation

The documentation has been updated and reorganized.

This includes:

• clearer onboarding documentation
• command reference improvements
• expanded format specifications
• English and Japanese documentation for major formats

The goal is to make Model Weave easier to understand and easier to try without needing to learn every format first.

Summary

This release improves Model Weave as a tool for navigating relationships, checking impact, and keeping Markdown-based design documents useful as a structured source of truth.

If you are using Model Weave for existing design notes, source-linked documentation, or AI-assisted modeling, 0.1.8 should make the model relationships and format guidance easier to work with.

[nejimakibird]

Model Weave 0.1.9 has been released.

Model Weave is an Obsidian plugin for reading Markdown-based design information as diagrams, previews, diagnostics, and source links.

This release focuses on improving Mermaid rendering and the app_process / Business Flow experience.

Main changes

Added Mermaid Detail views

Class / ER related models now have a more detailed Mermaid Detail view in addition to the existing lightweight Mermaid view.

Supported targets:

• Class
• Class Diagram
• Entity
• ER Diagram

The existing Mermaid view remains useful for overview diagrams, while Mermaid Detail view shows more information such as attributes, types, PK/FK markers, and relationships.

The Custom renderer is still available for detailed review, diagnostics, and navigation.

Added Mermaid Source panel

Mermaid-based renderers now include a collapsible Mermaid Source panel.

You can copy the generated Mermaid code block and paste it into normal Obsidian Markdown notes or documentation. This makes it easier to reuse diagrams outside the Model Weave preview.

Improved app_process / Business Flow

The app_process Business Flow preview has been improved.

You can now write the main process order in Steps, and use Flows only for explicit connections such as branches, merges, loops, exceptions, and condition labels.

Main improvements:

• Node shapes based on Steps.kind
• Implicit flow generation from Steps row order
• Explicit branches, merges, loops, and exception paths using Flows
• Clearer display priority between Flows.label and Flows.condition
• Improved display of conditions that contain Wikilinks

This makes it easier to start with a simple sequential flow and then add branches or conditions only where needed.

Cleaned up render mode behavior

The initial render mode behavior has been clarified.

• frontmatter render_mode is prioritized
• if omitted, the format-specific default render mode setting is used
• renderer switching in the toolbar is treated as a temporary change for the current view
• unsupported render_mode values show a warning and fall back safely

Future work

Mermaid color grouping by kind / area / layer, Mermaid click navigation, Sequence Diagram, and State Transition Diagram are planned for future versions.

GitHub Release:

Release Model Weave 0.1.9 · nejimakibird/model-weave

[nejimakibird]

Model Weave 0.1.10 released

Model Weave 0.1.10 is now available.

Fixed

• Fixed lower pane section render order.

Documentation and samples

• Aligned DFD diagram format documentation with the current parser schema.
• Aligned Mapping format documentation with the current parser schema.
• Added a minimal schema-driven relations sample using schema: model_relations_v1.
• Updated sample documentation.

Release assets

• Release assets are now built and uploaded by GitHub Actions.
• Added artifact attestations for release assets.

This release is mainly a maintenance and documentation quality release, but it also improves the reliability of future releases and keeps the public format documentation closer to the actual implementation.

The documentation updates were found through source-driven dogfood validation, where Model Weave was used to check its own model and format examples.

[nejimakibird]

Model Weave 0.1.11 has been released.

This is a maintenance release focused on compatibility, diagnostics, and preview display quality.

Changes

• Fixed app_process Mermaid label handling so escaped display characters and visible punctuation are preserved more safely.
• Added shared display text decoding for app_process labels.
• Fixed data_object parsing so ## Source Links is treated as a section boundary after ## Fields.
• Removed active display: contents usage for better Obsidian compatibility.
• Improved Japanese localization coverage for user-facing diagnostics and warning messages.
• Removed repetitive supported-type preview description text.
• Fixed compact Screen target cards so link text is no longer clipped.

Next

I also checked the Obsidian community plugin review warnings for this release. The next maintenance focus will be introducing local Obsidian compatibility lint checks and then reducing compatibility warnings step by step.

[nejimakibird]

Model Weave 0.1.12 is now available.

This is a feature-rich update focused on Domain modeling and visual readability.

New in 0.1.12

• Reusable domains files
• Integrated domain_diagram view
• Reusable color_scheme files
• DFD Domain grouping with local ## Domains and Objects.domain
• Color Scheme support for Domains, Domain Diagram, DFD, and Business Flow
• Applied Color Scheme display in the preview
• PNG export support for Domains and Domain Diagram

One of the biggest improvements in this release is the new Color Scheme support.
It helps diagrams communicate structure more clearly and makes the modeling views much easier to scan.

The screenshot below shows the current view together with the applied Color Scheme, so you can immediately understand both the diagram and the active kind-color mapping.

GitHub release:

Releases · nejimakibird/model-weave

Feedback and use cases are always welcome.

[nejimakibird]

Model Weave 0.1.13: Domain Sources and improved model readability

Model Weave 0.1.13 has been released.

This update focuses on making models easier to organize, reuse, and read across different diagram types.

The main addition is Domain Sources.

With Domain Sources, shared Domain definitions can be written once and reused from multiple models, such as:

• domain_diagram

• dfd_diagram

• app_process

This makes it easier to describe a system not only as individual diagrams, but as a connected model.

Domain Sources

domain_diagram, dfd_diagram, and app_process can now refer to shared Domain definitions.

For example, you can define areas such as “Application”, “Data”, “External System”, “Preview Pipeline”, or “Renderer” in a domains file, then reuse them from different views.

This helps keep diagrams consistent when the same functional areas appear in multiple models.

Domain-based DFD grouping

DFD objects can now use Objects.domain.

When Domain hierarchy is defined, the DFD can be rendered with domain-based grouping.

This makes larger data-flow diagrams easier to read because objects are visually organized by functional area.

Domain-based app_process flow

app_process steps now support Steps.domain.

This replaces the older lane-style usage for new models, while keeping lane as a legacy fallback.

The result is a business-flow style view that can share the same Domain definitions used by DFDs and Domain Diagrams.

Color Scheme improvements

Domain groups can also use Color Scheme settings.

This means the same kind of Domain, DFD object, or app_process step can have consistent visual styling across views.

UI and documentation improvements

This release also includes several refinements:

• render mode cleanup for domains / domain_diagram

• improved setting labels and language switching behavior

• many i18n fixes where English UI still showed Japanese text

• better preview summary labels

• Screen preview height fixes

• updated templates and format documentation

Why this matters

Model Weave is moving toward a model-first way of reading and maintaining systems.

Instead of treating each diagram as a separate document, Domain Sources make it easier to connect multiple views around the same conceptual structure.

This is especially useful for:

• source-code reverse engineering

• maintenance documentation

• understanding existing systems

• keeping Markdown-based models consistent over time

The next step is dogfooding: using these features in the Model Weave dogfood vault to show how Domains, app_process, DFD, and Source Links can work together as a practical code-reading map.

[nejimakibird]

Model Weave 0.1.15 is now available.

This is a patch release following 0.1.14, with a small compatibility fix for Obsidian plugin linting.

If you skipped 0.1.14, the biggest visible change in this release series is the new Weave Map in the Impact / Relationship View.

New in 0.1.14 / 0.1.15

• Weave Map in the Impact / Relationship View

• Compact / Full display modes for Weave Map

• Deduplication of repeated Source Links, unresolved references, and repeated edges

• PNG and PNG​ export buttons for graph toolbars

• Default layer colors for Weave Map

• COLOR-SCHEME support for target=weave_map

• Improved ER Diagram readability in dark mode

• Obsidian lint compatibility fix for Weave Map layout styles

Weave Map shows related models, Source Links, and unresolved references around the current model.

It is intended to make it easier to review model connections, especially when using Model Weave for existing system analysis, reverse engineering, or AI-assisted documentation.

Compact mode keeps the map easier to scan, while Full mode keeps denser relationships visible when you want to inspect reference complexity.

The screenshot below shows the Impact / Relationship View with Weave Map enabled.

Feedback and use cases are always welcome.

[nejimakibird]

Model Weave 0.1.16 is now available.

This release focuses on improving the Viewer / Preview experience, especially when using diagrams as navigation maps for Markdown-based model documents.

The biggest visible change is that resolved nodes and boxes in supported views can now show hover previews and can be clicked to open the source Markdown file.

New in 0.1.16

Hover previews for resolved nodes and boxes in supported views

Click navigation from diagram nodes / boxes to source Markdown files

Class / ER Mermaid and Mermaid Detail node interactions

Improved ER Mermaid Detail navigation

Hover previews for Screen, Class, ER, and Object Context custom views

Mermaid node interactions for Weave Map, DFD, App Process, and Domain views

Render mode switching scoped to each preview pane

Viewer / Preview documentation updates

Minimum supported Obsidian version updated to 1.8.7

Model Weave keeps Markdown as the source of truth, but the diagrams are becoming more than static rendered outputs.

With 0.1.16, diagrams can be used more directly as navigation maps into the underlying model documents. This should make it easier to review relationships, follow model references, and inspect existing systems when using Model Weave for software design, reverse engineering, or AI-assisted documentation.

Hover previews rely on Obsidian’s hover-link / Page Preview behavior. Because of that, they may not appear near the top edge of the Obsidian window or while using Model Weave Focus mode.

For resolved nodes and boxes, click navigation is available as the reliable fallback.

The screenshot below shows the improved Viewer / Preview interaction.

Side View

Focus Mode

Main Pane & Right Pane ,

The screenshot below shows side-by-side Model Weave views in Obsidian, with hover preview enabled on a resolved diagram node.

This makes it easier to compare diagrams and inspect the linked Markdown model without leaving the current view.

Feedback and use cases are always welcome.

[nejimakibird]

Model Weave 0.1.17: Major App Process Business Flow improvements

Model Weave 0.1.17 has been released.

This release focuses on major improvements to App Process Business Flow.

Model Weave is an Obsidian plugin for previewing structured Markdown models such as ER, Class, DFD, Screen, App Process, Rule, and related design documents. In this version, App Process Business Flow became much easier to view, navigate, and edit while keeping Markdown as the source of truth.

What changed

Business Flow direction: LR / TD

App Process Business Flow can now be displayed horizontally or vertically.

You can switch the direction from the preview toolbar, or define it in frontmatter:

flow_direction: TD

This makes larger flows easier to review depending on the shape of the process.

More expressive step kinds

Business Flow now supports more Steps.kind values and renders them with more appropriate shapes.

Newly supported kinds include:

• event

• api

• batch

• message

• data

• store

• wait

• error

• connector

• external

Blank or unknown kinds still fall back to a normal process node.

Ref-aware hover and click

Step nodes in Business Flow now use referenced models as hover preview and click navigation targets when possible.

For example, a step can now preview or open related models from fields such as:

• screen

• invoke

• rule

• input

• output

• Inputs.data

• Outputs.data

This makes the flow diagram more useful as a navigation map for related design documents.

Flow Connect Mode

This is the biggest improvement in this release.

App Process Business Flow now has a Connect Flow Mode.

When enabled, you can click two step nodes in the Business Flow preview to add a from -> to row to the ## Flows table.

1. Click the source step

2. Click the target step

3. Model Weave updates the Markdown ## Flows table

4. The preview refreshes

If the ## Flows section does not exist, Model Weave creates it automatically after ## Steps.

Duplicate from -> to rows are skipped.

This is not drag-and-drop editing. Markdown is still the source of truth. The SVG preview works as an input helper for updating the Markdown model.

Better Connect Flow UX

Connect Flow Mode now has clearer visual feedback:

• Active toolbar state

• Status text while the mode is active

• Selected source step guidance

• View Only mode preservation during Connect Flow operations

Normal hover and click navigation is restored when Connect Flow Mode is turned off.

Why this matters

Before this version, writing larger App Process flows required repeatedly checking step IDs and manually adding rows to the ## Flows table.

With Connect Flow Mode, the diagram itself can now help define the flow.

This makes App Process models smoother to create, especially when building or reverse-engineering business process documentation in Obsidian.

Notes

• This feature is only for type: app_process Business Flow previews.

• DFD flow editing is not included.

• Markdown remains the source of truth.

• Flow Connect Mode only assists with updating the ## Flows table.

Release:

Release Model Weave 0.1.17 · nejimakibird/model-weave

[nejimakibird]

Hi everyone,

I released Model Weave v0.1.18.

Model Weave is an Obsidian plugin for writing lightweight system design models in Markdown and previewing them as structured views and diagrams. It supports formats such as Class, ER, DFD, app_process, Rule, Mapping, Screen, CodeSet, Message, Domains, and Source Links.

This release focuses on making the review experience smoother and making diagnostics more useful when editing Model Weave files by hand.

Highlights

• Stable lower panel tabs for model review information
• Improved Diagnostics tab layout and actions
• Bulk Markdown copy for diagnostics
• Better guidance for common manual editing mistakes
• Small Quick Fix MVP for missing frontmatter id / name
• Fully empty Markdown table rows are now ignored as editing noise
• Hover preview stability improvements near the top edge and in Focus mode

Viewer improvements

The lower review area now uses stable tabs such as:

• Details
• Relationships
• Diagnostics
• Source Links
• Mermaid, where applicable

The tab layout is applied to both graph-based views and non-graph model review views.

This makes the viewer less crowded, especially for files that have relationships, diagnostics, source links, and Mermaid output at the same time.

The tab set also remains stable when switching renderers or changing Business Flow direction.

Diagnostics improvements

Diagnostics are now easier to read, act on, and share.

The Diagnostics tab has improved card layout, clearer action grouping, and bulk Markdown copy actions.

You can now copy:

• all diagnostics
• errors only
• warnings only
• notes only

This is useful when sharing diagnostic results with AI tools, reviewers, or issue discussions.

Diagnostic details also include more practical guidance for common hand-editing mistakes, such as:

• missing frontmatter
• table header mismatch
• malformed table rows
• unsupported render_mode
• unresolved references
• unsafe frontmatter Wikilink usage when detected
• multiple reference separator guidance when safely inferred

Quick Fix MVP

This release adds a small and intentionally limited Quick Fix MVP.

Currently supported:

• insert missing frontmatter id
• insert missing frontmatter name

The missing id is derived from the current file basename when safe.

Existing frontmatter values are not overwritten.

Missing type is not auto-fixed because it cannot always be inferred safely.

The goal is not broad automatic repair, but small safe assistance for common manual editing mistakes.

Empty Markdown table rows

Fully empty Markdown table data rows are now ignored.

A row is considered fully empty when every cell is empty or whitespace after trimming.

These rows are treated as editing noise, because Obsidian table editing can easily create them accidentally.

They do not create model rows and do not trigger required-field diagnostics.

Partially filled rows are still validated. For example, a row with an empty id or ref but non-empty notes or other cells remains invalid.

Install / update

If you already use Model Weave, update it from Obsidian’s Community Plugins screen.

GitHub release:

Thanks!

[nejimakibird]

Model Weave v0.1.19: Flow Diagram MVP, better diagnostics, and improved Color Scheme UX

Model Weave v0.1.19 is now available.

This release adds the first MVP of Flow Diagram, improves Diagnostics guidance, and makes Color Scheme editing and review easier.

Model Weave is an Obsidian plugin for writing lightweight system design models in Markdown and previewing them as structured diagrams and review views.

Highlights

• Added type: flow_diagram for screen communication and data handoff flows.
• Added richer Flow Diagram edge semantics with kind, trigger, data, and condition.
• Added rich hover interactions for Flow Diagram nodes and edge labels.
• Improved Diagnostics expected-header guidance.
• Added unresolved Wikilink diagnostics for Flows.data in DFD and Flow Diagram.
• Added Color Scheme picker assist.
• Made the Applied Color Scheme display more compact.

---

Flow Diagram MVP

Flow Diagram is a new DFD-like format for describing communication and data handoff flows between screens, contexts, processes, stores, and external systems.

It is especially useful when a simple screen-to-screen transition is not enough.

Real UI behavior often includes temporary context, helper screens, return values, and process execution.

For example:

Order Entry Screen
  -> Order Wizard Context
  -> Customer Search Screen
  -> Order Wizard Context
  -> Order Entry Screen

The important part is not only “which screen comes next”, but also:

• what event caused the movement
• what data was passed
• whether the flow updates a context
• whether a process is executed
• whether temporary state is stored

Screenshot: Flow Diagram sample

Flow Diagram uses Markdown tables like this:

Objects

id	label	kind	ref	domain	notes
ORDER_ENTRY	Order Entry Screen	screen	[[SCR-TEST-SCREEN]]	sales	Parent screen
CUSTOMER_SEARCH	Customer Search Screen	screen	[[SCR-WMS-HOME]]	sales	Helper search screen
ORDER_CONTEXT	Order Wizard Context	context		sales	Temporary working context
SESSION_STORE	Session Store	store		platform	Temporary persistence
ORDER_SUBMIT	Order Submit Process	app_process	[[PROC-ORDER-SUBMIT]]	application	Submit process

Flows

id	from	to	kind	trigger	data	condition	notes
F01	ORDER_ENTRY	ORDER_CONTEXT	context_update	click:SearchCustomer	[[DATA-ORDER-DRAFT]]		入力中状態を保持
F02	ORDER_CONTEXT	CUSTOMER_SEARCH	navigate	click:SearchCustomer	[[DATA-CUSTOMER-SEARCH-CONDITION]]		顧客検索画面を開く
F03	CUSTOMER_SEARCH	ORDER_CONTEXT	return	select:Customer	[[DATA-CUSTOMER-SELECTION]]	customer selected	選択結果を戻す
F04	ORDER_CONTEXT	ORDER_ENTRY	context_update	select:Customer	[[DATA-CUSTOMER-SELECTION]]		親画面へ反映
F05	ORDER_ENTRY	ORDER_SUBMIT	submit	click:Submit	[[DATA-ORDER-DRAFT]]	valid	注文登録処理を実行
F05	ORDER_CONTEXT	SESSION_STORE	store	auto:SaveDraft	[[DATA-ORDER-DRAFT]]

In the rendered view:

• Objects.kind controls node shape.
• Objects.domain groups nodes into domain subgraphs.
• Flows.trigger and Flows.data are used for readable edge labels.
• Wikilinks in ref and data can open Obsidian Page Preview when resolved.
• Unresolved data Wikilinks are reported by Diagnostics.

Flow Diagram is currently an MVP. It renders the Internal Detail View first.

Future versions may add Surface View, Communication View, folding/projection, and transition coverage support.

---

Better Diagnostics

v0.1.19 also improves Diagnostics behavior.

Diagnostics now use more schema-driven expected-header guidance. Expected headers are shown only when the table header itself is malformed, instead of appearing in unrelated warnings.

This makes diagnostics less noisy and easier to act on.

Examples of improvements:

• Malformed table headers show the expected header.
• Row-level cascade warnings are suppressed when the table header is broken.
• Flow Diagram local endpoints are distinguished from external model references.
• Source Links and Color Scheme table diagnostics are more consistent.
• DFD and Flow Diagram now validate Wikilinks in Flows.data, while plain text labels remain allowed.

This is still treated as a plain edge label:

Search condition

But this is treated as an intentional reference:

[[DATA-CUSTOMER-SEARCH-CONDITION]]

If that Wikilink cannot be resolved, Model Weave reports a warning.

---

Color Scheme improvements

Color Scheme editing and review also received several improvements.

Color picker assist

Color Scheme preview now includes swatches and native color picker controls for fill, stroke, and text.

This makes it easier to adjust colors without manually typing hex codes.

Compact Applied Color Scheme display

The Applied Color Scheme section is now more compact.

Instead of showing separate raw Fill, Stroke, and Text columns, it now shows:

Target | Kind | Preview | Notes | Source

Raw color values remain available through accessibility metadata, while the visible table focuses on visual confirmation.

This makes Details panels easier to read, especially for DFD, Flow Diagram, Domain, and App Process views.

---

Install / update

You can update Model Weave from Obsidian’s Community Plugins screen.

After updating, try inserting a Flow Diagram template and opening the preview.

The Flow Diagram MVP is still early, but it is already useful for reviewing screen communication, data handoff, temporary context, and process execution in one place.

Feedback is welcome, especially around:

• Flow Diagram notation
• screen transition / communication modeling
• Diagnostics wording
• future projection views such as Surface View and Communication View

[nejimakibird]

Hello everyone,

Model Weave v0.1.20 has been released.

Model Weave is an Obsidian plugin for describing and visualizing software models in Markdown, including ER diagrams, class diagrams, DFDs, screens, application processes, rules, mappings, and Flow Diagrams.

This release focuses on making Flow Diagrams easier to read from different viewpoints.

Screen-focused Flow Diagram view

Flow Diagrams can now be displayed in two modes:

• Detail — shows the complete processing and communication structure
• Screen — folds internal processing nodes into a simplified user-facing flow

The new Flow view selector in the Viewer toolbar lets you switch between Detail and Screen without editing the Markdown source.

Screen view keeps user-facing nodes such as screens, actors, users, external systems, and messages, while projecting paths through internal processing nodes into simpler edges.

This means that one detailed Flow Diagram can now be used both for:

• implementation and processing analysis
• screen-flow and user-interaction review

The selected toolbar mode is temporary and does not rewrite Markdown.

You can also control the initial display:

---
type: flow_diagram
flow_view: screen
---

flow_view defines the initial view for that file. When it is omitted, the new Default Flow Diagram view plugin setting is used.

After the initial display, the Viewer toolbar controls the current mode.

Domain-aware Flow Diagrams

Flow Diagrams now support the same Domain definitions used by other Model Weave diagrams.

Supported features include:

• ## Domain Sources
• local ## Domains
• Domain display names
• parent-child nested Domain groups
• Domain kind-based Color Schemes

For example, objects can continue to refer to a Domain by ID:

## Objects

| id | name | kind | domain |
|---|---|---|---|
| screen_cart | Cart | screen | sales |
| process_checkout | Checkout | app_process | sales |

The Domain definition can then provide its display name, hierarchy, and color category.

Existing Flow Diagrams without Domain definitions remain compatible. Their raw Objects.domain values continue to be used as groups without introducing new warnings.

Target-first Mapping format

New Mapping files now use the following recommended column order:

target_ref | source_ref | transform | rule | required | notes

This makes Mapping tables easier to read when the main question is:

What produces this target field?

The previous source-first format remains fully supported:

source_ref | target_ref | transform | rule | required | notes

No migration is required, and both formats can coexist in the same vault.

Compatibility

• Existing source-first Mapping files continue to work without warnings.
• Existing Flow Diagrams without Domain definitions retain their previous grouping behavior.
• Flow Diagrams default to Detail view unless configured otherwise.
• Changing the Flow view in the toolbar does not modify Markdown.

Update

Model Weave can be installed or updated from Obsidian Community Plugins.

The source code and release files are also available on GitHub.

Feedback and examples of how you use Flow Diagrams are welcome.

[nejimakibird]

Hi everyone,

Model Weave v0.1.21 is now available.

This release focuses on improving model validation and day-to-day viewing workflows in Obsidian.

Model Weave is an Obsidian plugin for describing and visualizing software models using Markdown, including Class, ER, DFD, Data, Screen, Rule, Mapping, App Process, Domain, and Flow Diagram models.

Vault-wide Diagnostics

A new command checks Model Weave diagnostics across the entire vault:

Model Weave: Check all model diagnostics

It rebuilds the model index and opens a summary of errors, warnings, and notes grouped by file.

You can:

• filter by severity or diagnostic code
• open the source Markdown file at the relevant location
• re-run the check after making changes
• copy all diagnostics as Markdown
• use localized diagnostic messages and Markdown output in English or Japanese

This is a static model check. It does not render every Mermaid diagram, so Mermaid rendering errors are outside the scope of this command.

Modeling Preview Focus Mode

The Modeling Preview can now be expanded into a temporary focus overlay.

You can start it from the preview toolbar or run:

Model Weave: Toggle focus mode

Focus Mode:

• expands the current Modeling Preview without closing workspace leaves
• automatically enables the diagram view when available
• can be closed from the toolbar, Command Palette, or with Esc
• preserves the Flow Diagram Detail / Screen selection
• keeps the diagram view enabled after leaving Focus Mode
• does not modify the Markdown file or plugin settings

When the Markdown editor is active, the command resolves the matching Modeling Preview by its vault-relative file path.

Rule Condition member references

Rule Conditions can now be resolved as member references.

Examples:

[[RULE-ORDER-VALIDATION]].COND-AMOUNT
RULE-ORDER-VALIDATION.COND-AMOUNT

[nejimakibird]

Condition members are also available to qualified completion and Impact Analysis.

This resolves false unresolved-reference diagnostics for models that refer to individual conditions inside a Rule.

Localized diagnostics

Vault-wide Diagnostics now uses the same diagnostic localization as the current-file Diagnostics panel.

The displayed message and copied Markdown follow the selected UI language, while canonical values remain unchanged, including:

• diagnostic codes
• file paths
• model IDs
• section and field identifiers
• expected Markdown table headers

Public roadmap

I have also added a public roadmap that separates current work, near-term improvements, later ideas, and exploratory topics.

Mobile support is listed as Exploring. Model Weave is currently desktop-only, and there is no target version or release date yet. The initial direction being considered is a view-focused mobile experience for previews, diagrams, diagnostics, vault navigation, and zoom/pan operations.

Feedback and real-world model examples are always welcome.

[maxmoellenbeck]

I really like the idea of keeping Markdown canonical and treating diagrams as generated views on top of it. The Source Links part is especially interesting because it makes the model more than just documentation. It becomes a way to move between architectural decisions and the actual implementation.

I’d be curious how this holds up once the models get larger though. Do people still keep the Markdown readable by hand, or does it eventually turn into more of a structured DSL that just happens to live inside Markdown?

Either way, really interesting direction. I think this kind of text-first modeling becomes even more useful as AI starts helping maintain architecture and documentation.

[nejimakibird]

Thanks a lot — I really appreciate the thoughtful comment.

Your point about scale is exactly one of the things I’m trying to validate through dogfooding.

My current goal is to keep the Markdown readable enough that a human can still understand and edit it directly, while allowing more structured sections where that structure adds real value. I don’t want Model Weave to become a full DSL that merely happens to use Markdown syntax.

Source Links are important in that balance too. I’m hoping the model can stay close enough to the implementation that architecture documentation does not become a separate, stale artifact.

And I agree that AI makes this direction more interesting. Text-first models are much easier for AI to review, update, compare with source code, and keep synchronized than diagrams that only exist as images.

Thanks again for taking a look and for the feedback.

[nejimakibird]

Model Weave v0.1.22 / v0.1.23 — Primary View, Visual Color Legend, and Improved Diagnostics

Model Weave v0.1.22 is now available, followed by v0.1.23 as a small maintenance update for Obsidian Community review compatibility.

v0.1.22 focuses mainly on improving the model viewing experience, especially when working across multiple related models.

Primary View and Weave Map

The biggest UI change in v0.1.22 is the new Primary View.

When both views are available, you can now switch between:

Model | Weave Map

directly in the main visualization area.

Previously, Weave Map was shown inside the lower Relationships area. Moving it to the Primary View makes it easier to compare the model itself with its surrounding relationships without losing access to the lower detail panels.

The lower area remains independent:

Details
Relationships
Diagnostics
Source Links
Mermaid

So, for example, you can display a Weave Map above while still reviewing relationship details or diagnostics below.

Weave Map is still a derived visualization based on Model Weave’s existing relationship / impact information. It does not introduce a new Markdown model format.

This also means model types without their own graphical Model View, such as Rule, Data Object, or Mapping, can still use Weave Map as a visual overview when relationship information is available.

Visual Applied Color Scheme legend

The Applied Color Scheme section has been redesigned from a compact text/table-style display into a visual legend.

Each entry now shows:

• the model kind
• the applied fill / border / text colors
• whether the color comes from a configured or built-in rule

The legend follows the currently selected Primary View.

For example:

Model
→ colors applied to the current model view

Weave Map
→ weave_map colors

For views that do not currently support color styling, the section remains visible and clearly reports that no colors are applied to the current view.

The Applied Color Scheme section is also consistently placed at the bottom of Details.

Color filtering is not included yet; the visual legend is the foundation for that future work.

Flow Diagram reference diagnostics fix

v0.1.22 also fixes false-positive unresolved-reference warnings in Flow Diagrams.

The intended semantics are now handled consistently:

Objects.id
→ local node ID

Flows.from / Flows.to
→ local Objects.id references

Objects.ref
→ external Model Weave reference

Flows.data as plain text
→ label

Flows.data as Wikilink
→ external reference

Previously, local Objects.id values could be treated as external references during Vault-wide Diagnostics.

This correction improves both diagnostics and impact analysis without changing the Flow Diagram Markdown format.

Obsidian 1.13+ settings support

Model Weave now supports Obsidian’s newer declarative Settings API.

On Obsidian 1.13 and later, Model Weave settings can participate in the Settings search experience.

Compatibility with older supported Obsidian versions is retained, so the existing settings UI continues to work there as well.

The minimum supported Obsidian version remains unchanged.

Mermaid source behavior

The Mermaid lower tab now follows the currently selected Primary View.

For example, a Screen model may not have Mermaid source for its normal Model View, but its Weave Map does.

In that case:

Model
→ Mermaid tab remains in place
→ shows that no Mermaid source is available for the current view

Weave Map
→ the same Mermaid tab shows the Weave Map source

This keeps the lower tab layout stable while switching views.

v0.1.23 maintenance update

v0.1.23 follows v0.1.22 as a maintenance release focused on compatibility with the latest Obsidian Community plugin review checks.

The project updated its Obsidian ESLint ruleset and migrated remaining native DOM creation to Obsidian-compatible helpers.

The latest review rules previously reported 194 prefer-create-el warnings; these have now been reduced to zero.

The migration also preserves Model Weave’s existing behavior for:

• popout windows
• SVG rendering
• Mermaid views
• PNG export

Model Weave can also resolve implementation source files outside the Obsidian vault when a user explicitly configures Local source root or uses an absolute Source Link.

That functionality remains desktop-only and is now more explicitly guarded and documented.

It is used only for resolving Source Links to implementation files; Model Weave does not use it as general-purpose storage outside the vault.

What is next

The next planned Viewer improvement is Color filtering, building on the new visual color legend.

Other ideas such as Communication View, State Machine-oriented views, and mobile support remain future / exploratory work rather than implemented features.

Thanks to everyone trying Model Weave and reporting issues. The recent dogfooding work continues to be useful for finding cases where the model semantics, diagnostics, and Viewer behavior do not quite line up.