Skip to main content

How the rules are enforced

Every platform makes promises about what its agents will and won't do. The question worth asking is where those promises live - because a rule that exists only in application code is a rule that survives exactly until someone forgets it.

Yekar.AI puts each guarantee at the lowest layer that can hold it.

In the database itself​

The strongest guarantees are stored-state rules PostgreSQL enforces on every write, no matter which part of Yekar.AI made it:

  • Agent memories are append-only. A memory can be superseded by a newer one; it cannot be rewritten to say something it never said.
  • Published Setup revisions are immutable. The version an agent ran last Tuesday is the version you can read today.
  • A published agent or flow cannot be un-published. You can repoint it at a different revision; you cannot make live work vanish.
  • Ownership can't drift across organizations. Every relationship carries its tenant, so a row cannot end up owned by someone else's workspace.

These protections apply consistently to changes made through Yekar.AI.

At the boundaries of the product​

Permissions are checked when work starts and when an action is performed. Queued work retains its original identity and authorization, and replaying an execution preserves its recorded decisions.

In the service layer, where the message is useful​

Before a database refusal, service checks give you a specific, actionable error - which credential is missing, which role you need, which state transition isn't allowed. That's the layer that turns "no" into "here's what to fix".

In tests, against a real database​

Behaviour that isn't a stored shape gets proven by running it: tenant scoping, the absence of cross-identity fallback, audit ordering, approval resume, publish and fire semantics. The test database is rebuilt through the real migrations every run, so the schema the tests exercise is the schema you get.

Why layer at all​

Each layer answers a different question. A database constraint proves a shape can never be stored; a permission check proves who was allowed to act just now; a test proves the sequence behaved. A change has to satisfy all of them that apply - which is what lets Yekar.AI say a guarantee holds rather than that it usually does.

Where to go next​