DEV Community: Roman

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

Building Topics Archive to turn history, science, sports, and more into original music through AI-assisted publishing. 🌐 https://topicsarchive.openverb.org

Roman — Fri, 17 Jul 2026 10:57:24 +0000

topicsarchive.openverb.org

Built PaywallOS to make subscriptions and feature gating semantic by protecting actions instead of pages. 🌐 https://paywallos.openverb.org

Roman — Fri, 17 Jul 2026 10:57:08 +0000

paywallos.openverb.org