How Dokeo is built
How the gate is built.
The loop, not the checklist.
Every object Dokeo touches moves through the same nine-step loop. Blog posts, landing pages, emails, AI drafts, video scripts, and 17 content types all run through this loop today.
The primitives.
Eight reusable building blocks. Every content type is built entirely out of these, not a one-off schema per type.
Object
Anything under test - a blog post, landing page, email, video script, or AI draft. Its actual fields live in a versioned payload, not in the platform's core tables.
Policy
What pass/fail means for an object type. Required, Blocked, or Threshold rules, inheritable from org down to a single object type.
Test
Runs an object's policy against its current version and returns a verdict - one of five severities, not just pass/fail.
Issue
A single finding from a test run: what failed, why, the evidence, and a recommended fix - the same shape whether a human or an agent reads it.
Fix
A recorded change made in response to an issue. Submitting a fix never marks the issue resolved on its own - only a fresh, verified test run does.
Approval
A human sign-off gate before deploy, modeled like a pull request: pending, approved, or changes requested.
Deployment
The record of an object shipping, and where.
Monitor
A cadence that watches a deployed object and can reopen it if real-world performance changes.
Five verdicts, not two.
Pass/fail is too coarse once a test can also mean "ship with a note" or "here's an idea, no rush." Every test run lands on one of five severities.
Ships never. A hard stop - confidentiality leaks, banned claims.
Ships with a fix. Blocks CI, blocks deploy until resolved.
Ships with a note. Visible, not blocking.
A suggestion. Never blocks anything.
Clean. No issue created.