An ontology is a formal description of a domain. It defines what things exist, what they are called, what data they carry, and how they relate to each other.
In business terms, an ontology is a shared language for the company. It answers basic but critical questions. What is an order? When is an order approved? What makes a customer active? Which fields are required for a shipment? If different systems answer those questions differently, teams move slower and errors multiply.
Prophet was built to make that shared language explicit. It lets teams drive engineering from the real-world business models of the organization, then generate consistent backend scaffolding from that definition.
Most organizations eventually duplicate the same business model across many places. It gets rewritten in API contracts, database schemas, service code, validation logic, and event payloads. Each copy starts correct. Over time, the copies drift.
Prophet treats that as a modeling problem, not just a coding problem. You define the domain as an ontology, and Prophet projects that model into the repetitive integration layer around it. APIs, schema artifacts, runtime contracts, and framework wiring come from one source instead of being hand-maintained in parallel.
The result is not a rigid platform. Teams can stay polyglot and still keep one coherent domain model across Java, Node, and Python services.
Action outputs are modeled as events: each action produces exactly one event payload. For objects with lifecycle state, generated stacks treat the declared enum field as ordinary persisted/queryable data rather than generating a separate workflow runtime.
Reliability problems in large systems often begin as language problems. Team A uses one definition. Team B uses another. Both are reasonable on their own, but the integration breaks.
Prophet helps by giving those boundaries a common contract. Generated outputs stay aligned because they are derived from the same ontology, not maintained by hand in parallel.
That also changes how teams approach change. When the domain evolves, the impact can be reasoned about clearly instead of discovered late.
A core value proposition is speed from a minimal model. A small domain DSL can generate most of the scaffolding and wiring that teams usually build by hand: contracts, routes, schema artifacts, and framework integration surfaces. That removes a large amount of repetitive setup work at the start of a project.
The longer-term value is coordination. As systems grow, teams make many local changes that can drift into one global mismatch. Prophet addresses that by encoding domain meaning, not just table shape, so actions, events, queries, and persistence evolve together. You get faster initial delivery and a model that stays understandable over time.
From a .prophet ontology file, Prophet can generate:
- SQL schema files
- OpenAPI contracts
- Turtle ontology projections (
gen/turtle/ontology.ttl) - Spring Boot integration code (DTOs, JPA entities/repositories, query and action endpoints)
- Node/Express integration code (typed contracts, zod validation, action/query routes, event publisher contracts)
- Python integration code (typed dataclass contracts, action/query routes, event publisher contracts)
- Event publisher wire envelopes with optional extracted object snapshots (
updated_objects/updatedObjects) from ref-normalized event payloads - Prisma schema + repository adapters for Node targets
- TypeORM entities + repository adapters for Node targets (wired through your application-owned
DataSource) - Mongoose models + repository adapters for Node targets (wired through your application-owned Mongoose connection)
- SQLAlchemy adapters + models for Python targets
- SQLModel adapters + models for Python targets
- Django adapters + models for Python targets
- Flyway/Liquibase migration artifacts
- Generation manifests for ownership and extension hooks
Turtle target conformance notes:
- Uses
prophet:vocabulary fromprophet.ttl - Uses a local prefix derived from ontology name (not a hardcoded
exampleprefix) - Supports SHACL validation via
pyshaclagainstprophet.ttl
- Define your business domain in Prophet DSL.
- Keep technical symbols stable for references and generated wire keys.
- Use
name "..."metadata for human-facing labels.
- Run validation.
- Generate artifacts.
- Add your business logic in user-owned extension points.
- Evolve safely with compatibility/version checks.
From PyPI:
python3 -m pip install --upgrade prophet-cli
prophet --helpFrom source (editable install):
python3 -m venv .venv --system-site-packages
.venv/bin/pip install --no-build-isolation -e ./prophet-cli
.venv/bin/pip install -r requirements-dev.txt- Quickstart overview: Quickstart
- Java quickstart: Spring + JPA
- Node quickstart: Express
- Python quickstart: FastAPI / Flask / Django
- Turtle target reference: Turtle
- Runnable sample apps: Examples
- Full user reference: Reference Index
- Developer docs: Developer Index
| Language | Framework | ORM/Adapter | Stack ID | Example |
|---|---|---|---|---|
| Java | Spring Boot | JPA | java_spring_jpa |
Spring Example |
| Node | Express | Prisma | node_express_prisma |
Express + Prisma Example |
| Node | Express | TypeORM | node_express_typeorm |
Express + TypeORM Example |
| Node | Express | Mongoose | node_express_mongoose |
Express + Mongoose Example |
| Python | FastAPI | SQLAlchemy | python_fastapi_sqlalchemy |
FastAPI + SQLAlchemy Example |
| Python | FastAPI | SQLModel | python_fastapi_sqlmodel |
FastAPI + SQLModel Example |
| Python | Flask | SQLAlchemy | python_flask_sqlalchemy |
Flask + SQLAlchemy Example |
| Python | Flask | SQLModel | python_flask_sqlmodel |
Flask + SQLModel Example |
| Python | Django | Django ORM | python_django_django_orm |
Django + Django ORM Example |
| Turtle | SHACL/RDF | Ontology projection | N/A | Minimal Turtle Example · Small Business Turtle Example |
Each example includes a README describing the domain model and stack-specific integration surfaces.
Apache-2.0. See LICENSE.