Omnismith was built around a simple constraint: many operational systems need different schemas, but the same platform capabilities.
Many operational systems have different schemas but the same platform requirements.
A product catalog needs categories, brands, and products. An infrastructure workspace needs servers, services, incidents, and metrics. An IT asset system needs contracts, devices, licenses, and owners.
The fields are different. The surrounding platform needs are usually the same.
You still need structured records, permissions, history, dashboards, imports, API access, and, in some cases, time-series data.
That is the problem Omnismith was built to address.
The Repeated Problem
The core issue is not that teams need databases. The issue is that they repeatedly need systems built around different data models while the surrounding platform requirements stay mostly stable.
The implementation pattern is familiar:
- define a schema
- build CRUD screens
- add permissions
- add history
- add imports and exports
- add charts or reporting
- expose the result through an API
That work is manageable when the schema is stable and the system is narrow.
It becomes expensive when the structure changes often or when the same product needs to support several operational domains. In those cases, too much work goes into rebuilding the platform around the schema instead of working on the domain itself.
This is common in internal tools, operational backoffice systems, monitoring workspaces, and domain-specific SaaS products. The schema changes with the business model, but the surrounding platform needs remain familiar.
Why Flexible Schema Is The Core Model
Omnismith uses an Entity-Attribute-Value model so the structure itself can be managed as data.
In practical terms:
- attributes define fields
- templates define structure
- entities store actual records
That allows a workspace to define its own schema without requiring code changes for every new field or template.
If a team needs a Server template with hostname, CPU cores, environment, and owner, that structure can be created directly in the product. If another team needs Supplier, Contract, and Renewal Date, it can define a different model in the same system.
The point is not schema flexibility for its own sake. The point is to reduce the cost of building and maintaining operational systems whose structure changes over time.
This changes the development boundary. Instead of treating every schema adjustment as an application change, the product can treat structure as workspace data and handle the surrounding operational behavior in a consistent way.
Why Dynamic Schema Alone Is Not Enough
Flexible schema alone is not enough for the types of systems Omnismith is meant to support.
Operational data usually needs more than field definition and record editing.
It also needs:
- history, so changes are traceable
- role-based access control, so access is scoped properly
- API-first access, so the workspace can be integrated into other systems
- time-series support, so metrics can be attached to entities instead of stored somewhere else
That combination defines the actual product boundary.
Omnismith is meant for systems where the schema is flexible, but auditability and operational visibility still matter.
That is also why the product is opinionated in a few specific directions. Changes are tracked. Access is scoped. API access is a first-class interface rather than an afterthought. Metrics can be stored against the same entities that define the operational model.
A server, sensor, contract, or product record does not need a separate system just because one part of its state changes over time.
Example Use Cases
This model fits several kinds of structured operational work particularly well:
- IT asset management
- server and service monitoring
- product and catalog management
- consent and compliance tracking
- internal backoffice systems with changing data models
The common pattern is not the domain itself. The common pattern is that each use case needs structured records together with operational behavior around those records.
An IT asset workspace needs devices, owners, contracts, warranties, and licenses. A monitoring workspace needs services, incidents, servers, and metric history. A catalog needs products, categories, pricing, stock state, and references. These are different models, but they benefit from the same platform shape.
Scope
Omnismith is not trying to be a universal replacement for every spreadsheet or content tool.
The intended scope is narrower and more practical: structured operational data that changes over time, needs clear access control, and benefits from being exposed through an API.
That is why flexible schema is combined with time-series support, full history, dashboards, RBAC, and API-driven workflows. Those capabilities make the schema model useful in day-to-day operation rather than only convenient during setup.
Conclusion
Omnismith was built for teams that need to model structured operational data without rebuilding the surrounding platform every time the schema changes.
Flexible schema is the core mechanism. History, permissions, API access, and time-series support are what make that mechanism useful in practice.
That is the product boundary: not only storing custom fields, but supporting the operational systems built on top of them.
Top comments (0)