edictIn development

Declarative business logic

Planned typed rules for quotas, streaks, capacity, credits, and state changes, written as configuration.

PlannedBusiness logic and automation module. Not available yet. Edict is in development.

Illustrative streak and quota rules

AgentEdit edict.yaml+10illustrative
1modules:
2+ rules:
3+ workout_streak:
4+ counts: workouts
5+ per: day
6+ reset_after: 1_missed_day
7+ emits: streak.at_risk
8+ daily_exports:
9+ limit: 3
10+ per: day
11+ unless_plan: premium

The syntax is not final. Your coding agent would edit this file.

What is the planned Declarative business logic module designed to do?

Many app features are built from a small set of repeating patterns. Edict calls out daily usage quotas, workout streaks, premium access rules, booking capacity, credits, achievements, scheduled reminders, inventory adjustments, social relationships, state transitions, and purchase-driven workflows. This is one of the most important parts of the product plan.

The aim is to represent these behaviors as typed, declarative configuration. You state the rule. The system is designed to turn it into authorization, enforcement, accounting, and failure handling, so you do not rewrite the same checks in each project.

How does the Declarative business logic module connect to other modules?

Modules communicate through typed contracts. The compiler is designed to resolve the connections, validate the configuration, and produce executable backend behavior. Business logic is the layer where those contracts meet your rules.

  • Business logic + Database. A rule is designed to read and write your entities. Atomic changes, such as an inventory adjustment, are meant to run safely under concurrent requests.
  • Business logic + Subscriptions. A rule can depend on an entitlement, such as a higher limit for premium users.
  • Business logic + Authentication + Subscriptions + AI gateway. A premium AI coach with a monthly allowance is the standard example. Identity, plan, and quota are designed to be checked together, and a failed request is intended not to count against the user.
  • Business logic + Background jobs. A rule can schedule follow-up work or expire a state after a set time.
  • Business logic + Push notifications. A rule can emit an event that a notification trigger listens for.
  • Business logic + Payments and credits. Rules are designed to decide when credits are granted, reserved, or released.

The intended experience is that most users configure high-level packages and do not touch low-level execution primitives.

What would you configure in the Declarative business logic module?

You choose the pattern, the data it counts or limits, the period it applies to, and what happens when the limit is reached or a condition changes. You can name events that a rule emits, so other modules can react.

The configuration on this page is illustrative. The syntax is not final.

What stays your own code with the Declarative business logic module?

Rules that do not fit a known pattern stay in your own code. So do the product decisions behind each rule, such as how many free exports are fair. Edict is designed to enforce and account for a rule you state. It does not tell you which rules your product needs.

Is the Declarative business logic module available yet?

Planned. Edict is in development, and this layer is not available. The set of supported patterns is not final and will grow only as each pattern is built and tested. This page describes intended design and gives no dates.

Join the beta waitlist to follow progress.

What does the Declarative business logic module work with?

Declarative business logic is designed to connect to 5 other modules. The lit arcs on the map show which.

Composition mapplanned, illustrative
  • Database and backend APIs

    Planned PostgreSQL-backed entities, relationships, and typed APIs generated from your schema.

  • Subscriptions and paywalls

    Planned store subscription sync, entitlements, and backend enforcement of paid access.

  • Payments and credits

    Planned store purchases for credits, with credit balances and atomic, refund-aware accounting.

  • Push notifications

    Planned device registration, templates, and event-triggered or scheduled notifications.

  • Background operations

    Planned scheduled tasks, durable event reactions, retries, and execution history without your own workers.

Common questions about the Declarative business logic module

Short answers about this planned module.

Is this a programming language?
No. The intent is typed, declarative configuration for common patterns. Custom logic that does not fit a pattern stays in your own code.
Which patterns are planned?
Examples include usage quotas, streaks, premium access rules, booking capacity, credits, achievements, scheduled reminders, inventory adjustments, and state transitions.
Is the syntax final?
No. Every snippet on this site is illustrative. The syntax is not finalized.

Get an invitation when the beta opens.

Joining gets you email updates while Edict is built, and an invitation to the hosted beta when it opens.

Building now. No launch date yet.