DEV Community: Roman

Building an Ecosystem of Software Projects: From AI Infrastructure to Geospatial Technology, Music, and Professional Development

Roman — Fri, 25 Sep 2026 13:42:22 +0000

How a collection of independent software projects evolved into a connected ecosystem exploring artificial intelligence, developer infrastructure, geospatial technology, digital publishing, and knowledge discovery.

Over the past several years, I’ve been building software across several different domains.

Some projects started as solutions to problems I encountered while working as a land surveyor. Others emerged from experiments with artificial intelligence, music production, developer tooling, and digital publishing.

At first glance, these projects might appear unrelated.

What does a professional experience-tracking application have in common with an AI execution framework?

How does a geographic music atlas relate to file management software?

And why would someone working in land surveying also build tools for monetization, blogging, and AI-assisted music?

The answer is that many of these projects emerged from a common interest:

Building software that gives people more control over their work, knowledge, creativity, and digital infrastructure.

This article introduces the ecosystem I’ve been developing, the problems each project addresses, and the architectural direction connecting them.

⸻

OpenVerb — Building an Execution Layer for AI Actions

🌐 https://openverb.org

One of the most significant developments in artificial intelligence is the transition from systems that generate information to systems that execute actions.

Modern AI models can interpret instructions, generate code, and interact with external tools.

But connecting intelligence to execution introduces additional architectural challenges.

How does an agent discover available actions?

How are inputs validated?

How are permissions enforced?

How do we determine whether an operation succeeded?

And how do we establish a verifiable record of what happened?

These questions led me to develop OpenVerb.

OpenVerb is an open execution layer for AI actions built around structured verbs, schemas, policies, execution, and receipts.

The underlying concept is that an action should be treated as more than an arbitrary function call.

An action has a purpose, a contract, execution requirements, potential side effects, and a result.

OpenVerb explores how these elements can be organized into reusable infrastructure.

The OpenVerb architecture

The ecosystem includes packages addressing different parts of the execution lifecycle:

Runtime
Policy
SDK
CLI
Core
Standard library
Developer integrations

It also includes specialized packages exploring applications in areas such as GIS, formatting, and geographic storytelling.

The broader objective is to establish infrastructure that can support AI-driven operations across different software environments.

Intelligence determines what should be done. Action infrastructure governs how it gets done.

This distinction becomes increasingly important as AI agents interact with business applications, enterprise systems, development environments, and real-world operations.

OpenVerb is my exploration of that architectural direction.

⸻

PaywallOS — Monetization as Software Infrastructure

🌐 https://paywallos.openverb.org

Software monetization is often treated as something developers add after building their applications.

A payment provider is integrated.

A subscription table is created.

Some premium features are hidden behind a conditional statement.

But monetization becomes much more complicated as applications grow.

Different subscription tiers need different permissions.

Some users receive access to specific features.

Others receive usage allowances.

Certain actions might require payment, while others remain freely available.

And eventually, the application needs to understand not simply whether someone paid, but what that payment authorizes them to do.

This is the problem space behind PaywallOS.

The project explores a portable monetization layer organized around a structured execution model:

Tier
↓
Policy
↓
Verb
↓
Execution
↓
Receipt

The objective is to connect monetization decisions to application behavior.

Rather than treating payment infrastructure and application execution as entirely separate concerns, PaywallOS explores how they can operate together.

It also connects naturally to OpenVerb’s broader approach to governed actions.

A premium feature is ultimately an action that someone is authorized to perform under particular conditions.

The challenge is making that relationship explicit, reusable, and manageable.

⸻

FolderCopilot — Making Existing File Systems More Useful

🌐 https://foldercopilot.com

One of the recurring challenges I’ve encountered in professional environments is managing large collections of project files.

Engineering and surveying projects often contain years of accumulated information.

CAD drawings.

Survey computations.

GIS datasets.

PDF plans.

Project correspondence.

Field records.

Supporting documents.

The problem isn’t necessarily that these files are poorly organized.

Sometimes, the underlying directory structure is perfectly reasonable.

The difficulty is understanding what’s already there.

A project folder might contain hundreds of files distributed across multiple directories, and determining the current state of the project requires navigating the entire structure.

This was part of the motivation behind FolderCopilot.

FolderCopilot explores ways to make existing file systems easier to navigate, understand, and work with.

The underlying philosophy is straightforward:

You shouldn’t have to reorganize your entire digital workspace before software can help you understand it.

The project is particularly relevant to professionals working with large, structured collections of project information.

It also reflects a broader theme across my ecosystem: helping people make better use of information they’ve already created.

⸻

Survey Manager Pro — Software Built Around Surveying Workflows

🌐 https://surveymanagerapp.com

My professional background is in geography, geospatial technology, and land surveying.

I’ve worked with boundary analysis, CAD drafting, GIS data, project preparation, and other surveying workflows.

One thing I’ve observed is that surveyors often depend on multiple applications to complete a single project.

GIS software handles one part of the workflow.

CAD software handles another.

Project documents exist in file directories.

Computations, field information, and other supporting materials may be distributed across different systems.

The challenge is not necessarily replacing those applications.

It’s improving how the workflow comes together.

Survey Manager Pro is my exploration of software designed around the practical needs of surveying professionals.

The project includes desktop, web, and QGIS-oriented development, connecting my professional experience with my software engineering interests.

I’m particularly interested in the relationship between project organization, geographic information, and the actual work surveyors perform.

The broader objective is to develop tools that understand professional workflows rather than requiring professionals to adapt everything they do to generic software.

⸻

Elevatr — Turning Professional Experience Into a Documented Asset

🌐 https://elevatr.dev

Another project emerged directly from my experience pursuing professional land surveying licensure.

In many regulated professions, completing the work is only one part of professional development.

You also need to demonstrate what you’ve done.

That may involve documenting experience, projects, responsibilities, supervision, and hours.

And reconstructing several years of professional experience after the fact can be difficult.

I began thinking about a different approach.

What if professionals maintained a structured record of their experience as it happened?

Instead of trying to remember every project years later, they could build a professional history throughout their careers.

That thinking led to Elevatr.

Elevatr helps professionals document their work experience, track projects, record hours, and maintain a history of their professional development.

The platform includes web, desktop, and mobile development.

The Android application has also been published on Google Play.

Beyond professional licensure

Although land surveying provided the original context, the underlying problem exists across many professions.

Engineers, architects, technicians, and other professionals accumulate valuable experience throughout their careers.

But professional experience is often represented by little more than job titles and employment dates.

I believe there’s an opportunity to document it more meaningfully.

A résumé tells people where you worked. A professional experience record can help explain what you actually did.

Elevatr is my attempt to make that documentation more accessible and useful.

⸻

Expanding Beyond Traditional Productivity Software

Not every project in my ecosystem began with a conventional workplace problem.

Some emerged from exploring what artificial intelligence makes possible in education, creativity, and digital knowledge systems.

Two of those projects have become particularly significant.

⸻

Topics Archive — AI-Assisted Music as a Knowledge Interface

🌐 https://topicsarchive.openverb.org

Music is traditionally organized around artists, albums, and genres.

But music can also be organized around knowledge.

History.

Geography.

Biographies.

Scientific discoveries.

Religious narratives.

Cultural events.

This is the thinking behind Topics Archive.

Topics Archive explores how AI-assisted music production can be used to create educational and thematic musical collections.

The project includes archives covering historical figures, biblical narratives, inventions, geography, and FIFA World Cup history.

The idea is not simply to generate songs about random subjects.

It’s to organize musical works into meaningful collections that people can explore.

A biography becomes a musical storytelling opportunity.

A historical event becomes part of a thematic archive.

A geographic location becomes a musical discovery experience.

From individual songs to structured collections

One of the most interesting aspects of this project is the relationship between content generation and software architecture.

Generating a song is one operation.

Organizing hundreds of songs into a coherent archive is another.

Building discovery mechanisms around those archives introduces an entirely different technical challenge.

And allowing people to create and curate their own collections creates additional opportunities.

Topics Archive is increasingly becoming an exploration of what happens when AI-assisted creative production is connected to structured digital publishing and curation.

⸻

World Music Atlas — Geography as a Music Discovery Interface

🌐 https://openmusicatlas.org

The World Music Atlas emerged from the geographic music experiments within Topics Archive.

I wanted to explore a simple concept:

Could a geographic atlas become an interface for discovering music?

Instead of beginning with an artist or a genre, someone could begin with a place.

A country.

A territory.

Eventually, perhaps a city, river, region, or ocean.

The geographic location becomes the entry point into a musical experience.

This led to the creation of the World Music Atlas — 2026 Founding Edition.

The founding collection includes musical works inspired by 203 places around the world, including 195 countries and eight additional territories.

The technical architecture

The platform uses Next.js and Vercel, with the atlas accessing the underlying Topics Archive data through a read-only database connection.

I also published an initial TypeScript SDK:

npm install @openverb/music-atlas

The package provides a foundation for integrating atlas functionality into other software projects.

The broader vision includes developer integrations, geographic storytelling, additional musical editions, and new ways of exploring cultural and geographic information.

The World Music Atlas is not intended to replace traditional geographic research or serve as an authoritative collection of indigenous musical traditions.

It’s a born-digital creative atlas exploring the intersection of geography, AI-assisted music, and digital curation.

The music is the medium. Geography provides the structure. Discovery is the experience.

⸻

OpenBlog — Giving Ideas Room to Develop

🌐 https://openblog.openverb.org

Another problem I’ve encountered is the limitation of short-form publishing.

Platforms such as LinkedIn and X are useful for discovering ideas and starting conversations.

But some ideas need more space.

A technical explanation might require architecture diagrams, implementation details, and examples.

A professional experience might require several thousand words.

A research observation might develop into an entire article.

When everything has to fit within a social media character limit, important context can disappear.

This is part of the motivation behind OpenBlog.

OpenBlog explores AI-assisted digital publishing, including the ability to develop articles from prompts and expand shorter social media posts into more complete written content.

The concept is particularly relevant to my broader ecosystem.

A technical observation about OpenVerb could begin as a LinkedIn post and eventually become a detailed development article.

A project announcement could become a longer explanation of the problem, architecture, and implementation.

A short reflection could develop into a more substantial piece of writing.

Social media can introduce an idea. Long-form publishing gives that idea room to develop.

⸻

The Bigger Picture: Building Systems That Connect

Looking at these projects together, I see several recurring architectural themes.

They may address different audiences, but many of the underlying problems are related.

Structured information

Elevatr structures professional experience.

Topics Archive structures educational music collections.

The World Music Atlas organizes music geographically.

FolderCopilot explores ways to understand existing file structures.

Execution and governance

OpenVerb explores structured AI actions.

PaywallOS explores policies governing access to monetized functionality.

Domain-specific workflows

Survey Manager Pro focuses on surveying and geospatial professionals.

Elevatr addresses professional experience documentation.

The World Music Atlas explores geographic discovery.

Publishing and distribution

OpenBlog provides a publishing environment.

Topics Archive organizes and publishes musical collections.

The World Music Atlas creates another interface for discovering those collections.

These projects are not all components of one monolithic application.

Each addresses a particular problem and can have its own identity, users, and development direction.

But there are opportunities for shared infrastructure, integrations, and architectural reuse.

That’s what makes the ecosystem interesting to me.

⸻

Why I’m Building Across Multiple Domains

There’s a common assumption that developers should focus exclusively on one industry or problem.

Specialization has obvious advantages.

But working across different domains can also reveal recurring patterns that are less obvious when viewed from within a single industry.

My experience in land surveying informs the way I think about structured data, professional workflows, documentation, and geographic information.

My work with AI infrastructure influences how I approach execution, automation, policies, and developer tooling.

My experiments with music and digital publishing have introduced different challenges involving content organization, discovery, curation, and distribution.

These experiences continuously inform one another.

Sometimes an architectural concept developed for one project becomes relevant to another.

Sometimes a workflow problem encountered professionally becomes the foundation of an entirely new application.

And sometimes an experimental project reveals an opportunity that wasn’t part of the original plan.

The connection isn’t necessarily the industry. It’s the way I approach building software.

⸻

What I’ve Learned From Building an Ecosystem

Developing multiple projects has taught me several things.

First, the problem behind a project matters more than the number of features it contains.

Second, software becomes more interesting when it reflects a genuine understanding of the environment in which people will use it.

Third, reusable infrastructure creates opportunities that isolated implementations may not.

And finally, not every project needs to begin with a fully developed business model or a prediction about its eventual market size.

Some projects begin as experiments.

Others begin as tools developed to solve an immediate problem.

Over time, the architecture, audience, and opportunities become clearer.

Of course, building multiple projects also introduces challenges.

Maintaining software requires time.

Documentation matters.

Testing matters.

User experience matters.

And deciding what to prioritize becomes increasingly important as the ecosystem grows.

But I see these challenges as part of the process of developing a sustainable body of work.

⸻

What’s Next?

My focus is on continuing to develop these projects while improving the infrastructure, usability, documentation, and integrations surrounding them.

For OpenVerb, that means continuing to explore the architecture of AI action execution.

For Elevatr and Survey Manager Pro, it means developing tools grounded in real professional workflows.

For FolderCopilot, it means improving how people interact with existing digital information.

For Topics Archive and the World Music Atlas, it means expanding the possibilities of AI-assisted music, digital curation, and knowledge discovery.

For PaywallOS and OpenBlog, it means exploring better systems for monetization and publishing.

I also want to continue documenting the development process.

Not just announcements about new features, but the architectural decisions, challenges, experiments, and lessons behind the software.

That’s one reason I’m sharing this work on DEV.

I’m interested in connecting with other developers who are building infrastructure, experimenting with AI, working in geospatial technology, or exploring unconventional intersections between software and other disciplines.

⸻

Final Thoughts

When I look at these projects together, I don’t simply see a collection of applications.

I see a growing body of work shaped by different professional experiences, technical interests, and experiments.

Some projects address problems I’ve encountered directly.

Others explore possibilities that emerging technologies have made accessible.

And others are attempts to build infrastructure that can support entirely new categories of applications.

The objective isn’t to build software for the sake of having more projects.

It’s to create useful systems, learn from the process, and explore how different technologies can work together.

Software development gives us the opportunity to turn observations into tools, tools into platforms, and platforms into infrastructure that other people can build upon.

That’s the opportunity I’m exploring through this ecosystem.

And I’m still building.

⸻

Explore the Ecosystem

Project Focus Website
OpenVerb AI action infrastructure https://openverb.org
PaywallOS Monetization infrastructure https://paywallos.openverb.org
FolderCopilot File management and discovery https://foldercopilot.com
Survey Manager Pro Surveying and geospatial workflows https://surveymanagerapp.com
Elevatr Professional experience documentation https://elevatr.dev
Topics Archive AI-assisted educational music https://topicsarchive.openverb.org
World Music Atlas Geographic music discovery https://openmusicatlas.org
OpenBlog AI-assisted digital publishing https://openblog.openverb.org

⸻

About the Author

I’m Roman Hancel, a geospatial technology professional, software developer, and founder building projects across AI infrastructure, land surveying, professional development, music, and digital publishing.

My work explores how software can connect different disciplines, make professional knowledge more accessible, and create new opportunities for independent developers and creators.

I Built a World Music Atlas: 203 Places, AI-Generated Music, and a New Way to Explore Geography

Roman — Fri, 25 Sep 2026 13:37:24 +0000

What started as an experiment in combining geography and AI-assisted music production became a born-digital musical atlas covering 203 places around the world.

🌍 Explore the project: https://openmusicatlas.org

The Idea

I’ve always been interested in the intersection of geography, technology, and how people understand the world.

As a geospatial developer, I spend a lot of time thinking about how geographic information can be represented, organized, and explored.

Maps are one of the most powerful tools we have for understanding our planet.

But what happens when we introduce music into that experience?

What would it look like to build a musical atlas where someone could select a country and listen to a musical interpretation inspired by that place?

That question eventually led me to build the World Music Atlas.

The project combines geography, AI-assisted music production, digital archives, and web development into an interactive experience.

The initial collection now represents 203 places around the world.

From an Educational Music Archive to a Global Atlas

Before building the World Music Atlas, I had been developing another project called Topics Archive⁠.

Topics Archive explores how AI-assisted music can be used to organize and communicate knowledge.

The platform includes musical collections exploring subjects such as:

Historical biographies
Biblical narratives
Geography and world cultures
Inventions and scientific developments
FIFA World Cup history

The underlying idea is that music can become another interface for learning.

Instead of treating songs exclusively as entertainment, we can also organize them into educational and thematic archives.

The World Music Atlas emerged from that broader experiment.

I wanted to take one of those collections and build a dedicated geographic experience around it.

Not simply a playlist of countries.

An actual musical atlas.

The 2026 Founding Edition

The first major milestone was establishing a collection representing the world.

The resulting 2026 Founding Edition includes 203 places, covering 195 countries and eight additional territories.

Each location has an associated musical work inspired by that place.

The atlas provides a geographic interface for discovering these works and exploring the collection.

The experience connects three elements:

Place → Music → Discovery

A user can begin with a geographic location, discover its associated musical work, and explore additional places through the atlas.

The objective is not to claim that an AI-generated song represents the definitive musical identity of a country.

Instead, the collection offers creative musical interpretations inspired by geography, culture, history, and place.

This distinction is important.

AI-assisted musical interpretation should not be confused with authentic documentation of a community’s traditional music.

The World Music Atlas is a curated digital creation, not an ethnomusicological authority.

Building the Atlas as a Software Platform

One of my goals was to make the project more than a collection of songs.

I wanted to establish a foundation that could support future editions, geographic expansion, and developer integrations.

The website is built using Next.js and deployed through Vercel.

The musical collection originated within Topics Archive, with the atlas accessing its underlying data through a read-only database connection.

This allowed me to establish a dedicated geographic experience without unnecessarily duplicating the existing archive.

The platform includes several important components.

Geographic Exploration

The /explore experience provides an entry point into the collection.

Users can discover musical works through geographic locations rather than relying exclusively on conventional music discovery methods such as artist names, albums, or genres.

This introduces another way of thinking about music interfaces.

A location can become the primary discovery mechanism.

Place Pages

Individual place pages provide dedicated destinations for the musical works associated with particular geographic locations.

For example, the atlas includes locations such as Jamaica, Haiti, France, Japan, Brazil, and Bangladesh.

These pages establish a foundation for future geographic and cultural context.

Curatorial Policy

The project also includes a curatorial policy.

When building an AI-assisted cultural collection, it is important to distinguish creative interpretation from documented cultural representation.

The atlas is intended to support curiosity and discovery while remaining transparent about the nature of its musical works.

Annual Editions

Rather than continuously modifying one collection without preserving its history, I introduced the concept of editions.

The initial collection is identified as the 2026 Founding Edition.

Future editions could explore different musical styles, geographic scales, or curatorial approaches.

This also creates opportunities to preserve earlier versions of the project as distinct digital artifacts.

Building a Developer SDK

Another important part of the project is making the atlas accessible to developers.

I published an initial TypeScript package:

@openverb/music-atlas

The package establishes a foundation for integrating World Music Atlas functionality into other applications.

npm install @openverb/music-atlas

The initial SDK supports modern JavaScript environments and is designed around lightweight integration.

It provides a starting point for building applications that interact with the atlas beyond the primary website.

Some potential applications include:

Interactive geographic experiences
Educational applications
Digital exhibitions
Music discovery interfaces
Geographic storytelling platforms

This is particularly interesting to me because I also work on OpenVerb, an open execution layer for AI actions.

The broader goal across these projects is to build software that can be reused and extended rather than existing exclusively as isolated applications.

Why Geography and Music?

Geography is often taught visually.

Maps, satellite imagery, photographs, charts, and spatial datasets help us understand the world.

But geographic understanding is not limited to visual information.

Places are also associated with language, sound, stories, traditions, and human experiences.

Music offers another way to engage with geographic subjects.

Imagine an educational experience where students can explore countries on a map, listen to musical interpretations, and then investigate the languages, history, and cultural traditions of those places.

The music becomes an entry point.

The geography provides context.

The combination encourages exploration.

This is where I see the broader opportunity for projects like the World Music Atlas.

AI-assisted music can become a component of interactive knowledge systems, not simply another category of generated content.

What’s Next?

The 2026 Founding Edition establishes the initial geographic collection.

But the architectural possibilities extend much further.

Future expansions could include cities, capitals, regions, rivers, lakes, seas, and oceans.

There are also opportunities to explore different musical interpretations of the same places across multiple editions.

On the developer side, I want to continue expanding the SDK and the ways geographic music collections can be integrated into other applications.

The broader vision is a platform where geography, music, storytelling, and software come together to create new forms of digital cultural experiences.

Final Thoughts

Building the World Music Atlas reinforced something I’ve been exploring across several of my software projects:

The most interesting applications of generative AI may not be the generated artifacts themselves, but the systems we build around them.

A generated song is one artifact.

A curated musical collection is another level.

A geographic interface that organizes those works into an explorable atlas introduces an entirely different experience.

And a developer SDK creates opportunities for that experience to extend into other applications.

The World Music Atlas is an experiment in what becomes possible when those layers come together.

The world is not just something we can map.

It’s also something we can explore through sound.

🌍 Explore the World Music Atlas: https://openmusicatlas.org

🎵 Explore Topics Archive: https://topicsarchive.openverb.org

💻 Developer SDK: https://www.npmjs.com/package/@openverb/music-atlas

⸻

I’m Roman Hancel, a geospatial developer and creator of the World Music Atlas, Topics Archive, OpenVerb, and several other software projects exploring the intersection of geography, artificial intelligence, and digital infrastructure.

How I Built Semantic Monetization Into SaaS With OpenVerb + PaywallOS

Roman — Mon, 24 Aug 2026 14:12:42 +0000

Most SaaS paywalls are still implemented as scattered conditional logic.

You start with something simple:

if (user.isPaid) {
enableExport()
}

Then the product grows.

Now you have:

Free users
Pro users
Business users
usage limits
feature-specific restrictions
trials
team permissions
billing state
upgrade prompts
API enforcement
backend authorization

Before long, monetization logic is spread across frontend components, API routes, middleware, database checks, and billing code.

That is the problem I wanted to solve with PaywallOS.

PaywallOS is an AI-powered semantic monetization and paywall platform built on top of OpenVerb, an open execution layer for AI actions.

The core idea is simple:

Instead of monetizing pages, monetize actions.

⸻

The Problem With Traditional Paywalls

Traditional SaaS products often think in terms of routes or features.

For example:

/dashboard → Free
/reports → Pro
/admin → Business

That model works for some products, but it becomes limiting when the same interface contains actions that belong to different pricing tiers.

Imagine a data platform where every user can open the dashboard.

A Free user might be able to:

view_data
search_records
create_project

A Pro user might additionally have access to:

export_data
generate_report
ai_suggestions

And a Business user might unlock:

bulk_export
team_management
advanced_analytics

The page itself is not really what you are selling.

The capabilities are.

That is where semantic monetization becomes useful.

⸻

Treating Product Features as Verbs

OpenVerb is built around the idea that software actions can be represented as semantic verbs.

Instead of thinking about a button as merely a UI component:

Export

I can describe what the button actually does:

export_data

The same approach works for many different capabilities:

generate_report
create_workspace
invite_member
ai_suggestions
download_pdf
run_analysis
publish_project

These become part of the product’s semantic action layer.

PaywallOS can then map those verbs to commercial rules.

For example:

tiers:
free:
actions:
- view_data
- search_records
pro:
actions:
- view_data
- search_records
- export_data
- generate_report
- ai_suggestions
business:
actions:
- "*"

Now the pricing model is expressed in terms of what users are allowed to do.

⸻

Frontend Integration

The frontend can remain relatively simple.

Initialize PaywallOS with the current application and user context:

initPaywallOS(
apiKey,
appId,
userId,
userTier
)

Then actionable components can be tagged with semantic verbs:

Export

Generate Report

AI Suggestions

The important part is that the UI does not need to contain the full pricing policy.

The component simply declares intent.

verb="export_data"

PaywallOS determines whether that action is allowed.

⸻

What Happens When the User Clicks?

Suppose a Free user clicks:

Export

The application can send an authorization request conceptually like:

{
"userId": "user_123",
"tier": "free",
"verb": "export_data"
}

PaywallOS evaluates the request.

The result might be:

{
"allowed": false,
"reason": "tier_required",
"requiredTier": "pro"
}

The frontend can then show the appropriate upgrade experience.

For an authorized user:

{
"allowed": true
}

The application continues with the action.

This creates a clean separation between:

User intent
↓
Monetization policy
↓
Authorization
↓
Execution

⸻

Centralizing Monetization Logic

One of my main goals with PaywallOS was eliminating pricing logic scattered throughout an application.

Without a centralized system, you eventually get code like:

if (
user.plan === "pro" ||
user.plan === "business" ||
user.isAdmin ||
user.hasLegacyAccess
) {
// ...
}

Then another component has slightly different logic.

And another API endpoint checks something else.

Eventually nobody is completely sure which rules are authoritative.

With an action-centric model, the product can have a centralized policy configuration:

actions:
export_data:
minimumTier: pro
generate_report:
minimumTier: pro
monthlyLimit: 50
ai_suggestions:
minimumTier: pro
monthlyLimit: 100
bulk_export:
minimumTier: business
team_management:
minimumTier: business

Now monetization becomes configuration rather than duplicated application logic.

That is a major architectural difference.

⸻

Usage-Based Monetization

Tier access is only one part of the problem.

AI products especially are increasingly usage-based.

A Pro subscription might include:

100 AI generations / month
50 reports / month
10 exports / day

That means authorization needs to understand more than:

Does this user have Pro?

It may also need to ask:

Has this user reached the action limit?

The action model makes this natural.

For example:

ai_suggestions:
minimumTier: pro
limits:
monthly: 100

An authorization result could then return:

{
"allowed": false,
"reason": "usage_limit",
"limit": 100,
"used": 100,
"resetAt": "2026-09-01T00:00:00Z"
}

The product can respond accordingly.

⸻

Stripe Handles Billing. PaywallOS Handles Meaning.

Stripe is excellent at managing the financial side of subscriptions.

It understands things like:

customer
subscription
price
invoice
payment

But your application still needs to understand what those billing states mean inside the product.

For example:

Stripe price_123

does not inherently mean:

allow export_data
allow generate_report
deny bulk_export
limit ai_suggestions to 100/month

That semantic mapping belongs to the application layer.

PaywallOS sits between billing state and product capability.

Conceptually:

Stripe
↓
Subscription state
↓
PaywallOS
↓
Semantic action policy
↓
Application

Stripe remains the billing infrastructure.

PaywallOS interprets that billing state as executable product permissions.

⸻

Why OpenVerb Fits This Model

OpenVerb treats actions as structured verbs.

A verb can define things such as:

name
description
input schema
output schema
policy
execution behavior
receipt

That architecture maps naturally to monetization.

If the system already understands:

export_data

as an action, then commercial policy can become another policy applied to that action.

Conceptually:

Intent
↓
Verb
↓
Authentication
↓
Monetization policy
↓
Usage policy
↓
Execution
↓
Receipt

This is especially interesting for AI systems.

An AI agent may decide that it wants to perform:

generate_report

The runtime should still be able to determine whether that user is commercially authorized to execute the verb.

The AI does not need to understand the entire pricing implementation.

It simply expresses the intended action.

⸻

AI-Native Paywall Configuration

Another area I am exploring with PaywallOS is using AI to generate the initial action library.

A developer could describe an application:

My SaaS product lets users create projects, run AI analysis,
export reports, invite teammates, and perform bulk exports.

An AI-assisted setup process could propose:

create_project
run_ai_analysis
export_report
invite_member
bulk_export

It could then suggest an initial tier structure:

Free:
create_project
Pro:
run_ai_analysis
export_report
Business:
invite_member
bulk_export

The developer still controls the final policy.

But AI can dramatically reduce the amount of configuration required to get started.

⸻

The Backend Still Has to Enforce It

Frontend paywalls should never be treated as security boundaries.

Hiding or disabling a button is useful UX, but users can still call APIs directly.

That means the same semantic authorization needs to happen on the backend.

For example:

app.post("/api/export", async (req, res) => {
const decision = await paywall.authorize({
userId: req.user.id,
verb: "export_data"
})
if (!decision.allowed) {
return res.status(403).json(decision)
}
return exportData(req, res)
})

The frontend improves the experience.

The backend provides the enforcement.

Both systems use the same semantic action.

That prevents the frontend and backend from developing separate interpretations of the pricing model.

⸻

A Better Developer Mental Model

The biggest change is not really technical.

It is conceptual.

Instead of asking:

Which page does this plan unlock?

I want developers to ask:

Which actions can this user perform?

That creates a more flexible monetization model.

The same action can appear:

on multiple pages
in a mobile app
in a desktop application
through an API
inside an AI agent
through an automation workflow

The commercial rule remains attached to the action.

Not the interface.

⸻

Where This Could Go

Action-based monetization opens up some interesting possibilities.

A product could eventually define:

generate_image → $0.10
run_analysis → $1.00
export_dataset → Pro
bulk_processing → Business
premium_model → 5 credits

The same semantic execution layer could support:

subscriptions
credits
usage-based pricing
per-action pricing
API metering
AI agent permissions
enterprise feature controls
marketplace actions

At that point, monetization becomes part of application architecture rather than a layer added after the product is built.

⸻

Final Thoughts

The main idea behind PaywallOS is straightforward:

Product capabilities should be first-class objects in the monetization system.

Instead of spreading pricing logic across dozens of components:

if paid
if pro
if business
if credits > 0

describe the action:

export_data

Then let a centralized policy determine:

Who can execute it?
Which tier includes it?
How often can it run?
Does it consume usage?
Should an upgrade be shown?

OpenVerb provides the semantic action model.

Stripe can provide the billing infrastructure.

PaywallOS connects those pieces into an action-centric monetization layer.

That is the architecture I am experimenting with at:

paywallos.openverb.org

If you are building SaaS, AI tools, agents, or usage-based products, I think action-level monetization is going to become increasingly useful as applications become more dynamic and less page-centric.

opensource #saas #ai #webdev #typescript

PaywallOS: What an OpenVerb Domain Implementation Looks Like

Roman — Thu, 20 Aug 2026 14:56:25 +0000

PaywallOS: What an OpenVerb Domain Implementation Looks Like

This week, I want to show one of the clearest examples of what OpenVerb can look like when it is applied to a real software domain.

That example is PaywallOS.

OpenVerb provides a common way to define actions as verbs, validate inputs, apply policies, execute actions, and return receipts.

PaywallOS takes that model and applies it to:

subscription tiers
entitlements
feature access
usage limits
upgrade decisions

The important part is that PaywallOS is not a separate idea from OpenVerb.

It is an example of what can be built on top of the OpenVerb execution model.

⸻

The Problem

Most SaaS applications start with simple subscription checks.

Something like:

if (user.plan === "pro") {
exportData()
} else {
showUpgradeModal()
}

That works at first.

Then the product grows.

Now you have:

Free, Pro, and Business tiers
usage limits
unlimited features
AI quotas
custom entitlements
different upgrade paths
enterprise exceptions

Soon, feature-access logic starts spreading across the codebase.

function handleExport() {
if (!user.subscription) {
showUpgradeModal()
} else if (user.plan === "free") {
showUpgradeModal()
} else if (
user.plan === "pro" &&
exportsThisMonth >= 50
) {
showLimitModal()
} else {
exportData()
}
}

The application now has to understand pricing logic everywhere.

PaywallOS approaches this differently.

⸻

Step 1: Define Product Capabilities as Verbs

Instead of thinking first about buttons and routes, define the actual action.

{
"verbs": [
{
"name": "dashboard.view",
"description": "Access the analytics dashboard"
},
{
"name": "data.export",
"description": "Export reports and raw data"
},
{
"name": "ai.insights",
"description": "Generate automated AI insights"
},
{
"name": "ai.forecast",
"description": "Generate predictive forecasts"
}
]
}

Now these actions have stable identities.

data.export means one thing regardless of where the button appears.

ai.insights means one thing regardless of which frontend component triggers it.

That is the OpenVerb idea.

⸻

Step 2: Connect Verbs to Tiers

Now define which subscription tiers can execute which verbs.

Free

dashboard.view

Pro

dashboard.view
data.export
ai.insights

Business

dashboard.view
data.export
ai.insights
ai.forecast
team.collaboration
api.custom_keys
support.priority

At this point, the pricing model becomes much easier to inspect.

Instead of asking:

Where in the codebase do we check for Pro?

you can ask:

Which verbs does Pro allow?

That is a much cleaner boundary.

⸻

Step 3: Add Usage Policies

Not every entitlement needs to be unlimited.

For example:

dashboard.view
Free: unlimited
Pro: unlimited
Business: unlimited
data.export
Free: denied
Pro: 50/month
Business: unlimited
ai.insights
Free: denied
Pro: 20/month
Business: unlimited
ai.forecast
Free: denied
Pro: denied
Business: unlimited

Now the system can answer more than a simple yes or no.

It can determine:

whether the action is included
whether a limit applies
how much usage remains
whether the user needs to upgrade
whether the monthly quota has been reached

⸻

Step 4: Let the UI Describe the Action

The frontend can simply declare what action the user wants to perform.

Export

Generate Insights

Forecast

Now the UI does not need to understand the entire pricing system.

It only needs to say:

The user wants to execute data.export.

PaywallOS can evaluate the entitlement.

⸻

Complete Example

Suppose Alex is on the Free plan.

Alex clicks:

Export

The system evaluates:

User: Alex
Tier: Free
Verb: data.export
Decision: DENY
Reason:
data.export requires Pro or Business

The application can show the appropriate upgrade experience.

Now Alex upgrades to Pro.

The exact same button remains:

Export

But the evaluation changes:

User: Alex
Tier: Pro
Verb: data.export
Usage:
17 / 50
Decision:
ALLOW

The export runs.

Usage becomes:

18 / 50

No new conditional.

No change to the button.

No duplicated subscription logic.

⸻

When the Limit Is Reached

Eventually Alex reaches:

50 / 50

The next request can return:

Decision: DENY
Reason:
monthly_limit_reached
Limit:
50

The system can then show a quota message instead of an upgrade message.

Same verb.

Different policy result.

⸻

The Same Pattern Works for AI Features

Consider:

Analyze Dataset

A Free user:

DENY
Upgrade required

A Pro user with 7 of 20 uses consumed:

ALLOW
Usage: 8 / 20

A Pro user at the limit:

DENY
Monthly limit reached

A Business user:

ALLOW
Unlimited

The feature remains:

ai.insights

The policy determines whether it can execute.

⸻

The Architecture

The complete flow looks like this:

UI
verb="ai.insights"

↓

OpenVerb
What action is being requested?

↓

PaywallOS
Who is requesting it?
What tier are they on?
Is the verb included?
Does it have a limit?
How much has been used?

↓

Decision
ALLOW
DENY
UPGRADE
LIMIT_REACHED

↓

Application
Execute the action
or
present the appropriate paywall

This separation is the important part.

⸻

Why This Matters Beyond Paywalls

PaywallOS is interesting because it demonstrates that OpenVerb does not need to directly implement every domain.

OpenVerb provides a common execution language.

The domain system adds its own interpretation.

PaywallOS asks:

Who is allowed to execute this verb?

A GIS system could ask:

Which mapping environment can execute this verb?

An enterprise agent system could ask:

Which agent is authorized to execute this verb?

A workflow engine could ask:

Is this verb allowed at the current workflow stage?

A physical-device runtime could ask:

Which device can execute this action?

Same execution model.

Different domain.

⸻

OpenVerb as the Shared Layer

You can think of the architecture like this:

OpenVerb
↓
PaywallOS

But that same model could also support:

OpenVerb
↓
GIS execution layer

or:

OpenVerb
↓
CRM execution layer

or:

OpenVerb
↓
Browser automation

or:

OpenVerb
↓
AI-native IDE

That is the larger direction.

OpenVerb defines the common language of execution.

Domain systems build on top of it.

⸻

The Bigger Idea

Traditional software often looks like:

User clicks button
↓
Application runs custom logic

An OpenVerb-style system can look more like:

Human or AI requests an action
↓
Action is represented as a verb
↓
Policy determines whether it can execute
↓
The correct runtime executes it
↓
A receipt describes what happened

That gives AI systems a structured boundary between:

deciding what should happen

and

actually making it happen

PaywallOS is one concrete example of that idea.

⸻

Explore It

PaywallOS:

https://paywallos.openverb.org

OpenVerb:

https://openverb.org

Install:

npm install openverb

or:

pip install openverb

If you are building AI agents, SaaS platforms, developer tools, automation systems, or domain-specific execution environments, I would be interested to see what this model could look like in your architecture.

OpenVerb: open execution for AI.

OpenVerb #AI #OpenSource #DevTools #AIAgents #SaaS #TypeScript #Python

Building Topics Archive: What Happens When Generative Media Needs an Archive?

Roman — Wed, 12 Aug 2026 14:48:43 +0000

We’ve spent enormous effort figuring out how to generate AI media.

I’ve been thinking about a different problem:

Where does all of it go?

If AI makes media effectively unlimited, generation eventually stops being the only interesting problem.

Organization becomes infrastructure.

That’s what I’m exploring with Topics Archive.

From Feeds to Topics

Most internet media is organized around feeds.

Creator
↓
Post
↓
Feed
↓
Gone from attention

Topics Archive explores a different structure:

Topic
↓
Identity
↓
Metadata
↓
Generated Artifacts
↓
Relationships
↓
Discovery

Instead of making the post the primary unit, make the subject persistent.

A topic could be:

a person
a country
a city
an animal
a historical event
a Bible story
a soccer match
a scientific concept

Then generated songs, images, videos, biographies, metadata, and other artifacts can accumulate around it.

Testing the Model With Music

I’ve already experimented with the concept through several archives.

One is the Bible Musical Archive, where stories and subjects become musical artifacts.

Another is the World Cup Musical Archive, where matches can become persistent topics with generated music associated with them.

I’ve also built a large biography collection.

The point isn’t simply:

AI can make a song about anything.

We already know generative models can create enormous quantities of media.

The interesting question is:

How do we organize generated culture when creating it becomes nearly free?

The Technical Problem

A topic-based archive starts resembling a graph more than a traditional music library.

For example:

World Cup
↓
Tournament
↓
Match
↙ ↘
Team A Team B
↓
Location
↓
Generated Song

Now the media is connected to structured entities.

That opens possibilities around APIs, geographic interfaces, search, recommendation, automated generation pipelines, and programmatic archives.

Why I Think This Matters

Generative media is going to produce an enormous amount of cultural material.

Feeds are optimized for what’s new.

Archives are optimized for what persists.

I’m interested in building for the second problem.

Maybe the next major challenge in generative media isn’t generating another billion artifacts.

Maybe it’s creating structures that make those artifacts discoverable, contextual, and worth preserving.

Topics Archive:
https://topicsarchive.openverb.org

generativeai #musictech #archives #knowledgegraphs #ai

Building OpenVerb: An Open Execution Layer Between AI and Software

Roman — Wed, 12 Aug 2026 14:47:15 +0000

The more capable LLMs become, the more interested I am in what happens after reasoning.

Suppose an AI understands:

Create a CRM contact for Sarah Chen.

Understanding the request isn’t the difficult part anymore.

Execution is.

That’s the problem behind OpenVerb.

Actions as Verbs

OpenVerb represents application capabilities as structured verbs:

crm.create_contact
email.send
gis.add_layer
file.move

Instead of giving an AI unrestricted control over software, applications expose known capabilities.

Conceptually:

Intent
↓
Verb
↓
Schema
↓
Policy
↓
Executor
↓
Receipt

This creates a boundary between intelligence and execution.

The model determines intent.

The execution infrastructure determines what that intent is allowed to become.

The Ecosystem

OpenVerb started as a protocol and has expanded into a larger developer ecosystem.

I’ve built or experimented with:

Protocol
Framework
Runtime
Policy
SDK
CLI
Core
.ov
Viewer
Studio
CRM
GIS
IDE
Pulse
Stdlib
Markdown
Python Core
Fellowship

These aren’t intended to be unrelated packages.

They’re different pieces of the same execution problem.

Portable Workflows

One extension of this architecture is .ov.

AI can generate workflows today, but they’re frequently trapped inside the application that created them.

.ov explores:

Prompt
↓
Generate workflow
↓
Save .ov
↓
Inspect
↓
Execute
↓
Reuse

The workflow becomes an artifact instead of temporary conversation state.

Policy and Receipts

Execution introduces consequences.

The fact that an agent knows about:

email.send

doesn’t mean it should always execute it.

That’s why policy sits directly in the OpenVerb model.

And afterward, a receipt provides evidence of execution.

I think those concepts become increasingly important as AI moves from:

“Here’s what you should do.”

to:

“I did it.”

The Long-Term Idea

I’m exploring OpenVerb as something approaching a universal runner for AI actions.

Applications provide capabilities.

Models provide intelligence.

OpenVerb provides the execution contract between them.

Models can change.

Agents can change.

Applications can change.

The capability interface can remain understandable.

OpenVerb:
https://openverb.org

NPM:
https://www.npmjs.com/package/openverb

OpenVerb is open infrastructure, so if you’re building agents, copilots, automation systems, or developer tools, I’d be particularly interested in what you’d build on top of it.

ai #agents #opensource #developerexperience #automation

Building PaywallOS: Separating Payments From Entitlements

Roman — Wed, 12 Aug 2026 14:44:33 +0000

A surprisingly common SaaS anti-pattern looks something like:

if (user.plan === "pro") {
showFeature();
}

It works.

Until it doesn’t.

Add multiple tiers.

Usage limits.

Trials.

One-time purchases.

Organizations.

Add-ons.

API access.

AI credits.

Suddenly payment state and authorization logic are spread throughout the application.

That’s the infrastructure problem I’ve been exploring with PaywallOS.

Payments Aren’t Entitlements

A payment provider answers questions about transactions and subscriptions.

Your application has a different question:

What is this user actually allowed to do?

Those concerns are related, but they aren’t identical.

I think about the architecture as:

Payment
↓
Subscription / Purchase
↓
Entitlement
↓
Resource / Capability
↓
Access Decision

That separation creates a cleaner boundary between billing infrastructure and application authorization.

Why This Matters for AI

The problem gets even more interesting with agents.

Traditional SaaS might ask:

Can this user access FEATURE_X?

An agentic application may need to ask:

Can this user execute ai.generate_report?
Does this account have 10 executions remaining?
Can this agent invoke export.create?
Does this plan allow this model?

Now entitlement infrastructure starts intersecting with capability-based execution.

That’s one reason PaywallOS also connects conceptually with some of the work I’ve been doing on OpenVerb.

OpenVerb asks:

Is this action structurally valid and permitted?

PaywallOS asks:

Does this account possess the entitlement required to access it?

Those are different layers, but they can complement each other.

The Bigger Idea

I don’t think every SaaS developer should have to reinvent entitlement logic throughout their application.

The goal behind PaywallOS is to explore a dedicated infrastructure layer for:

Identity
+
Payment State
+
Entitlements
+
Usage
↓
Access Decision

Checkout is only the beginning of a paywall.

The interesting engineering starts after someone pays.

PaywallOS:
https://paywallos.openverb.org

saas #payments #authorization #developerexperience #architecture

Building Elevatr: Treating Professional Experience as Structured Data

Roman — Wed, 12 Aug 2026 14:41:03 +0000

Most career software models employment.

I became interested in modeling something different:

experience itself.

I built Elevatr after dealing with the complexity of documenting professional experience for licensure.

A résumé might say:

Company
Role
2024–2026

But a licensing process may care about what actually happened during those years.

Projects.

Hours.

Responsibilities.

Experience categories.

Supervision.

Verification.

That requires a different data model.

Modeling Experience

Conceptually, Elevatr looks more like:

Professional
↓
Employer
↓
Project
↓
Experience Entry
↓
Category + Hours + Responsibility
↓
Evidence
↓
Verification

Now experience becomes queryable.

How many hours were accumulated in a category?

Which projects demonstrate a particular competency?

Which entries have been verified?

Who supervised them?

Which requirements remain incomplete?

Multiple Platforms

I’ve been building Elevatr across:

Desktop
Web
Mobile

The interfaces serve different purposes.

Mobile → capture
Desktop → dedicated workspace
Web → manage/access

They ultimately revolve around the same professional record.

I’ve also worked on verification workflows, including DocuSign integration.

That’s important because there’s a major difference between:

"I recorded this experience."

and:

"This experience was verified."

Why This Gets Interesting With AI

Once professional experience has structure, AI can potentially help convert natural descriptions into categorized records.

For example:

Prepared an ALTA/NSPS Land Title Survey draft, incorporated legal and surveyor comments, updated Exhibit A and Schedule B, and revised plan notes.

That can potentially be transformed into structured experience rather than disappearing inside a timesheet.

The model becomes:

Natural-language work description
↓
Extraction
↓
Project + Tasks + Categories
↓
Experience Record
↓
Verification

That’s the technical direction I find most interesting.

Elevatr isn’t intended to be another employee timesheet.

A timesheet belongs primarily to the employer.

Your professional experience belongs to your career.

https://elevatr.dev

careerdevelopment #saas #ai #engineering #softwaredevelopment

Building FolderCopilot: What Happens When AI Becomes a Layer Above the Filesystem?

Roman — Wed, 12 Aug 2026 14:39:51 +0000

The filesystem is one of the oldest interfaces we still use every day.

We create folders.

We name files.

We drag them around.

We download something and promise ourselves we’ll organize it later.

AI changes what should be possible here.

That’s the idea behind FolderCopilot, a project I’ve been building around AI-assisted file and workspace organization.

The Problem

Traditional filesystems understand structure:

/projects
/client-a
/documents
/images

But they don’t understand why that structure exists.

A file manager knows that:

proposal-final-v3.pdf

is a PDF.

It doesn’t inherently know that it’s a client proposal belonging to a particular project and should live alongside related contracts and correspondence.

FolderCopilot explores adding that contextual layer.

Conceptually:

File
↓
Metadata / Content
↓
Context
↓
Role
↓
Workspace
↓
Organization

More Than One Interface

I’ve been developing FolderCopilot as an ecosystem rather than a single utility.

That includes:

Desktop application
Web experience
Browser-extension workflows
Role-based organization
Workspace templates
AI-assisted organization

The desktop layer is particularly important because the local filesystem remains where a huge amount of real work happens.

The browser matters because that’s where much of the mess originates.

Downloads, PDFs, screenshots, research documents, and attachments constantly enter the filesystem through it.

Role-Based Organization

One design decision I made was not to assume everyone should organize files the same way.

A developer might think in terms of:

repositories
documentation
assets
builds
configuration

A researcher might care about:

papers
references
datasets
notes
results

So FolderCopilot includes role-oriented experiences for developers, students, researchers, teachers, project managers, and others.

I’ve also built workspace templates around academic work, development, clients, small businesses, research, and job searches.

The bigger goal isn’t automated folder creation.

It’s giving AI enough context to reason about:

Where does this file belong within the way this particular person works?

That’s a much more interesting problem.

Where I’m Taking It

I don’t think AI file management should mean giving a model uncontrolled permission to rearrange your drive.

The interesting architecture is somewhere between AI reasoning and controlled filesystem operations.

That’s the layer I’m continuing to explore.

FolderCopilot isn’t meant to replace the filesystem.

It’s an experiment in what happens when the filesystem finally gets an intelligent organizational layer.

FolderCopilot:
https://foldercopilot.com

If you’re working on local-first AI, file organization, desktop AI, or intelligent workspace tooling, I’d be interested in comparing approaches.

ai #productivity #desktop #filesystem #automation

⚡ OpenVerb Is Becoming an Ecosystem for AI Execution

Roman — Wed, 12 Aug 2026 14:34:21 +0000

OpenVerb started with a relatively simple question:

How should AI actually take actions inside software?

Not generate instructions for an action.

Not tell the user which buttons to click.

Actually execute it.

That question started with the OpenVerb Protocol and has since expanded into an ecosystem of frameworks, developer packages, applications, portable workflow files, policy infrastructure, and execution tooling.

Here’s what I’ve been building.

⸻

The OpenVerb Protocol

At the foundation is the concept of a verb.

Applications expose capabilities using structured names:

email.send
crm.create_contact
gis.add_layer
file.move

Instead of giving an agent unrestricted application access, the AI requests a known capability.

The basic execution model is:

Intent
↓
Verb
↓
Schema
↓
Policy
↓
Executor
↓
Receipt

The AI provides intelligence.

OpenVerb provides the execution contract.

⸻

The OpenVerb Framework

A protocol isn’t particularly useful if developers can’t implement it.

So I built the framework around it.

The developer stack includes components such as:

Runtime
Policy
SDK
CLI
Core

The Runtime handles execution.

The Policy Engine controls whether execution is permitted.

The SDK provides programmatic access.

The CLI provides developer tooling.

And Core provides shared foundations across the ecosystem.

An application can register capabilities while OpenVerb handles the infrastructure surrounding their execution.

⸻

Policy-Controlled Execution

One of the ideas I care about most in OpenVerb is separating:

CAN EXECUTE

from:

SHOULD EXECUTE

An agent might know that email.send exists.

That doesn’t automatically mean it should be allowed to execute it.

Policy can sit directly in the execution path:

Agent
↓
Verb Request
↓
Validation
↓
Policy
↓
Execution

As agents gain more autonomy, I think this distinction becomes increasingly important.

⸻

Receipts

Execution also needs evidence.

If an agent says:

“I updated the CRM.”

I want infrastructure capable of answering:

What changed?

Which verb executed?

What inputs were used?

Did execution succeed?

What happened afterward?

That’s why receipts are part of the OpenVerb architecture.

Request → Execute → Result → Receipt

The goal is to make AI execution more observable and auditable.

⸻

.ov — Portable AI Workflows

Then I started thinking about another problem.

AI can generate workflows, but those workflows are frequently trapped inside the application or conversation that generated them.

So I created the .ov format.

The idea:

Prompt
↓
Generate Workflow
↓
Save .ov
↓
Inspect
↓
Execute
↓
Share
↓
Reuse

Instead of an AI workflow being temporary application state, it can become a portable artifact.

A .ov workflow can describe things such as:

name: client-onboarding
steps:

verb: crm.create_contact
verb: document.generate
verb: email.send

Now the workflow is something that can potentially be versioned, inspected, shared, and executed by compatible environments.

⸻

OpenVerb Viewer

Once .ov became a file format, another question appeared:

What opens the file?

That’s what led to OpenVerb Viewer.

I’ve been building Viewer as a cross-platform application for interacting with .ov files, including:

workflow visualization
graph views
strict validation
inspection
offline verb simulation

One way I think about it:

If .ov is the portable workflow, Viewer is the reader.

⸻

OpenVerb Studio

Viewer handles inspection.

Studio explores creation and execution.

The workflow I’m building toward is:

Describe workflow
↓
AI generates .ov
↓
Inspect
↓
Provide inputs
↓
Execute
↓
Output
↓
Save

That creates an interesting bridge between natural-language AI and deterministic workflow infrastructure.

AI helps create the workflow.

OpenVerb provides the structure around executing it.

⸻

OpenVerb CRM

I’ve also been building applications on top of the execution model.

One example is OpenVerb CRM.

A request such as:

"Create a contact for Sarah Chen at Atlas Engineering."

can become:

{
"verb": "crm.create_contact",
"input": {
"first_name": "Sarah",
"last_name": "Chen",
"company": "Atlas Engineering"
}
}

That request can then move through validation, policy, execution, and receipt generation.

The CRM isn’t just another OpenVerb package.

It’s an example of what software looks like when its capabilities are designed around structured AI execution.

⸻

OpenVerb GIS

My background is in GIS and land surveying, so I also started applying the architecture to geospatial software.

Imagine a GIS environment exposing:

gis.create_project
gis.add_layer
gis.query_features
gis.transform
gis.export

Now an AI doesn’t need arbitrary control over the entire GIS interface.

It requests defined geospatial capabilities.

Natural Language
↓
GIS Verb
↓
Schema
↓
Policy
↓
GIS Executor
↓
Receipt

That’s the idea behind OpenVerb GIS.

⸻

The Broader Developer Ecosystem

OpenVerb has continued expanding into supporting packages and experiments.

The ecosystem now includes work around:

Runtime
Policy
SDK
CLI
Core
IDE
CRM
GIS
Pulse
Stdlib
Markdown
.ov
Viewer
Studio

And OpenVerb isn’t limited to TypeScript.

I’ve also been building the Python side of the ecosystem, including:

OpenVerb Core
Fellowship

The goal isn’t to force developers into one giant framework.

It’s to make the architecture modular.

Use the pieces you need.

Extend the parts relevant to your application.

Build new verbs.

Build new executors.

Build new tooling.

⸻

Toward a Universal Execution Layer

The larger architecture I’m exploring looks something like this:

          AI / AGENT / COPILOT
                   │
                   ▼
              OPENVERB
                   │
      ┌────────────┼────────────┐
      ▼            ▼            ▼
     CRM          GIS         EMAIL
      │            │            │
    VERBS        VERBS        VERBS
      │            │            │
      └────────────┼────────────┘
                   ▼
          POLICY + EXECUTION
                   │
                   ▼
                RECEIPT

Models can change.

Agents can change.

Applications can change.

The execution contract remains understandable.

That’s why I’ve increasingly thought about OpenVerb as a potential universal runner for AI actions.

Applications provide capabilities.

Models provide intelligence.

OpenVerb sits between intelligence and execution.

⸻

The Ecosystem Is Still Growing

What began as the OpenVerb Protocol has expanded into:

Protocol → Framework → Runtime → Policy → SDK → CLI → .ov → Viewer → Studio → CRM → GIS → IDE → Pulse → Stdlib → Python → Fellowship

But all of those projects revolve around the same underlying idea:

AI needs an execution layer.

As AI systems move from generating answers toward performing real work, I think we’ll need infrastructure for defining capabilities, validating requests, enforcing policies, executing actions, and proving what happened.

That’s what I’m building with OpenVerb.

⚡ OpenVerb
https://openverb.dev

📦 NPM
https://www.npmjs.com/package/openverb

If you’re building agents, copilots, automation systems, developer tools, or AI infrastructure, I’d love to hear what you think — and especially what you’d build on top of an open execution layer.

OpenVerb #AI #AIAgents #OpenSource #AIInfrastructure #DeveloperTools #Automation #TypeScript #Python

⚡ OpenVerb Hackathon: Build AI That Actually Takes Action

Roman — Wed, 12 Aug 2026 14:31:32 +0000

AI is getting very good at telling us what to do.

The next challenge is letting AI actually do it — without giving an agent uncontrolled access to everything.

That’s the idea behind the OpenVerb Hackathon.

I’m inviting developers, students, AI engineers, open-source contributors, founders, and anyone interested in agent infrastructure to build something using OpenVerb.

What is OpenVerb?

OpenVerb is an open execution layer for AI actions.

Applications expose capabilities as structured verbs:

email.send
crm.create_contact
calendar.create_event
gis.add_layer
file.organize

Instead of letting an AI generate arbitrary commands, the execution path can be structured:

Intent
↓
Verb
↓
Schema
↓
Policy
↓
Executor
↓
Receipt

The model figures out what it wants to do.

OpenVerb provides infrastructure around how that action is represented, validated, authorized, executed, and recorded.

What Can You Build?

I’m intentionally keeping the hackathon broad.

🤖 Build an Agent

Give an agent explicitly defined capabilities instead of unrestricted access to an application.

For example:

research.search
document.create
email.send
calendar.create_event

Then use OpenVerb policies to control what the agent can actually execute.

🧩 Build an Integration

Connect an existing application or API to OpenVerb.

Create verbs for:

GitHub
Slack
Notion
GIS platforms
CRMs
developer tools
productivity software
hardware
your own API

The interesting question is:

What capabilities should this application expose to AI?

🛠️ Build Developer Tools

The OpenVerb ecosystem itself creates opportunities for tooling.

You could build:

a verb debugger
schema generator
visual policy editor
receipt explorer
verb registry browser
workflow visualizer
testing framework
new executor
development environment

📄 Build With .ov

One of the newer parts of OpenVerb is the .ov workflow format.

The idea is to make AI-generated workflows portable:

Prompt
↓
Generate workflow
↓
Save .ov
↓
Inspect
↓
Execute
↓
Share
↓
Reuse

Instead of an automation disappearing inside a chat session, it becomes an artifact.

That means you could build a .ov generator, editor, runner, library, marketplace, converter, visualizer — or something completely different.

🗺️ Build Something Unexpected

This is probably what I’m most excited about.

Use OpenVerb for GIS.

Robotics.

Music.

Research.

Education.

Business automation.

Accessibility.

Developer infrastructure.

Games.

Scientific workflows.

Land surveying.

Or a use case nobody involved with OpenVerb has considered yet.

A Simple Example

Imagine the user says:

“Add Sarah Chen from Atlas Engineering to my CRM.”

The model could translate that into:

{
"verb": "crm.create_contact",
"input": {
"first_name": "Sarah",
"last_name": "Chen",
"company": "Atlas Engineering"
}
}

OpenVerb can then validate the request.

Policy determines whether the operation is permitted.

The appropriate executor performs the action.

A receipt records the result.

Natural Language
↓
Structured Intent
↓
crm.create_contact
↓
Validate
↓
Policy
↓
Execute
↓
Receipt

That’s the pattern I want developers to experiment with.

🛡️ The Trust Problem

The hackathon isn’t only about whether an agent can perform an action.

I want projects to explore whether it should.

Take:

email.send

A useful implementation should be able to think about questions like:

Who is the recipient?
Is this agent allowed to send email?
Does this action require confirmation?
Are certain domains prohibited?
What information can be included?
How do we prove what was actually sent?

As agents become more capable, these questions become infrastructure problems.

That’s why schemas, policies, executors, and receipts are important parts of OpenVerb.

What I’m Looking For

The biggest project won’t necessarily win.

I’d rather see three beautifully designed verbs than 100 poorly controlled tools.

Projects should focus on four things:

Creativity — Apply OpenVerb somewhere interesting.

Execution — Make the AI actually accomplish something.

Structure — Define clear capabilities and interfaces.

Trust — Think about validation, policies, permissions, and receipts.

The Ecosystem

OpenVerb has grown beyond the original protocol.

The ecosystem includes work around:

Protocol
Framework
Runtime
Policy
SDK
CLI
Core
.ov
Viewer
Studio
CRM
GIS
IDE
Pulse
Stdlib
Markdown
Python Core
Fellowship

You don’t need to use everything.

Choose the part that makes sense for your project.

Or build something that extends the ecosystem itself.

Why I’m Doing This

I’ve spent a lot of time thinking about what OpenVerb could become.

But that’s also a limitation.

I know what I would build with it.

An open protocol becomes much more interesting when someone else looks at the same primitives and says:

“Wait — I could use this for something completely different.”

That’s what I want this hackathon to uncover.

Build. Share. Execute.

Full dates, rules, registration, judging, prizes, and submission details will be announced separately.

For now, start thinking about one question:

What would you build if AI could reliably take action?

⚡ OpenVerb
https://openverb.dev

📦 NPM
https://www.npmjs.com/package/openverb

If you’re interested in participating, contributing, mentoring, judging, sponsoring, or partnering with the OpenVerb Hackathon, reach out.

Don’t just make AI talk. Make it act.

OpenVerb #AI #AIAgents #Hackathon #OpenSource #AIInfrastructure #DeveloperTools #Automation #TypeScript #Pyth

The Missing Piece of AI Automation: Portable Workflow Files (.ov)

Roman — Fri, 07 Aug 2026 14:13:16 +0000

Every major AI model today can generate text.

Many can call tools.

Some can execute functions.

But very few can produce something you truly own.

That’s the problem I’ve been thinking about while building OpenVerb.

⸻

AI conversations disappear. Workflows shouldn’t.

Imagine spending an hour building an automation with an AI assistant.

Tomorrow you want to:

run it again,
edit it,
review it,
send it to a coworker,
store it in Git,
or execute it from another application.

Most AI platforms make this surprisingly difficult because the automation is trapped inside a conversation.

The workflow isn’t portable.

⸻

What if AI generated documents instead?

Instead of generating another block of text, what if AI generated a structured execution document?

That’s the idea behind .ov files.

A .ov file is a portable workflow that describes what should happen, not just what the AI said.

Think of it as the equivalent of:

PDF for documents
Markdown for notes
Docker for containers

…but for AI execution.

⸻

Example

version: "1.0"
name: New Client Onboarding
actions:

verb: crm.create_contact params: name: "John Doe" email: "john@example.com"
verb: email.send params: to: "john@example.com" subject: "Welcome!" template: "welcome"
verb: file.create_folder params: path: "/Clients/John Doe"

The AI doesn’t execute these actions.

It simply generates the workflow.

An OpenVerb-compatible runtime can then:

validate it,
collect missing inputs,
enforce policies,
execute each verb,
produce receipts.

⸻

Why not just use function calling?

Function calling is useful, but it’s usually tied to a particular model, SDK, or provider.

A portable execution document separates:

reasoning
execution

The model decides what should happen.

The runtime decides how it happens.

That makes workflows reusable across applications instead of being locked inside one AI ecosystem.

⸻

Why this matters

Portable workflow files unlock possibilities that conversations can’t.

Imagine:

Version-controlling automations with Git.
Reviewing AI-generated workflows before execution.
Sharing workflows with teammates.
Publishing workflow libraries.
Executing the same automation across multiple applications.
Building marketplaces of reusable AI workflows.

Once workflows become files, they become assets.

⸻

The OpenVerb vision

OpenVerb isn’t trying to build another chatbot.

It’s an attempt to build an open execution layer for AI.

The long-term vision is an ecosystem where applications speak a common language of verbs and portable execution documents, allowing AI-generated workflows to move freely between compatible tools instead of remaining locked inside proprietary platforms.

The web became powerful because of open standards.

I believe AI automation needs them too.

⸻

I’m curious:

If AI could export every automation as a portable workflow file, what would you build with it?

ai #automation #opensource #programming #webdev #softwareengineering #developertools #buildinpublic