How Ceez works, from meaning to action.

1 · System overview

Two problems. Two products. One operating loop.

Enterprise AI fails on two separate problems. The enterprise has no continuously maintained understanding of itself — definitions drift, the same metric means different things in different systems, and rules live in documents and heads. And knowing is not doing — multi-step objectives cross applications and teams, and execution needs tools, permissions, escalation and measurement. Ceez addresses each with its own product and joins them through Business Intents.

2 · Ceez Ground

The context intelligence platform beneath every crew.

Systems of record capture what happened; almost none of them hold what it means. Dashboards count, warehouses store, catalogs list tables — but the definitions, rulings and decisions that make a number mean one thing and not another live in policy PDFs, in people's heads, and in the code that actually runs. Ground is built to hold that meaning, arbitrate it, certify it, keep it true — and run every crew on it.

2.1 · The engine

Every crew runs the same five operations. All are bidirectional and none is a phase: three generate meaning, two spend it, and each one both reads Ground and adds to it. An archetype (§2.5) does not sit in the flow — it wraps it, telling each operation what to target.

2.2 · Semantic intelligence: three graphs, one identity space

What the engine makes — and what Ground is. The three graphs share one identity space, are certified per domain and versioned like code. A measure is reachable from the entity it describes and from the step that produces it; that connective tissue is what lets a crew answer in the enterprise's terms rather than the model's.

• GRAPH 01Knowledge

  Entities, authoritative sources and lineage — plus assertions pulled from the unstructured corpus, each linked to a real entity and carrying its source.

• GRAPH 02Metric

  Definitions, grain, filters and rulings — each recorded with an owner, a rationale and an expiry, so a certified meaning cannot quietly rot.

• GRAPH 03Context

  Decision rights, unwritten convention, run and release discipline — the things no source states, supplied by the people who hold them.

2.3 · Capabilities

• Discover & Catalog

  Find entities, attributes, relationships, concepts, metrics, definitions, sources and existing mappings.

• Semantic Mapping

  Separate raw fields from the business meaning they carry. A field like created_at can mean different things by source; Ground makes the interpretation explicit.

• Decision Deck

  Accept, settle or investigate competing interpretations — with human ownership rather than silent inference.

• Institutional Decisions

  Rulings persist with rationale, owner and provenance instead of disappearing into a meeting, an email or a one-off prompt.

• Semantic Contracts

  Publish reviewed meaning as a consumable record with stable identifiers, versions and provenance.

• Business Intents

  Register the questions the business commits to validate, measure and watch (§3).

• Provenance

  Trace why every meaning and decision is trusted, back to the source that produced it.

• Versioning

  Know when meaning changed; run workflows against a known semantic state.

• Checks & Execution

  Validate contracts and run them against live data.

• Drift Monitoring

  As data, definitions and policies change, surface semantic drift before it goes stale. Ground is a continuous system, not a cataloging project.

2.4 · The initiative harness

Every initiative runs on a harness, the workflow it follows: six moves with two gates between them. G1 is the counter-signed specification; G2 is the approval to grant write access. The first four moves are run by people — the context steward and the forward-deployed engineer — using Ground for discovery and authoring and Crew to install the delivery set. The harness carries the initiative's live meaning as it goes — instantiated at the first move, not handed over at the end. There is no point where curation stops and execution starts: agents harvest and propose; humans originate and rule. Gates are steps in the workflow, not exceptions to it.

2.5 · Archetypes

Four families share the same engine and differ only in what they target, what they write into Ground, and who stewards the result.

2.6 · Shared building blocks

Two layers: cross-cutting stock every archetype inherits — including everything that senses, arbitrates and certifies — and per-archetype stock. What differs between families is mostly targets and evaluations, not machinery.

• Skills

  Named, constrained capabilities — harvest, arbitrate, author-grounded, resolve, evaluate — invoked by name, never improvised.

• Agents

  Roles that staff a crew: steward copilot, arbitration assembler, coverage analyst, spec author, custody recorder.

• Tool grants (MCP)

  Scoped access to exactly the systems a step may touch — warehouse, catalog, git, ticketing, identity — and nothing more.

• Knowledge packs

  Modeling conventions, arbitration protocol, elicitation playbooks, custody and audit standards — the method, made reusable.

• Evals

  Gold-question sets, regression against the previous release, citation-integrity and assumption-completeness checks.

• Harness profiles & runtime

  Workflow shapes with default crew and gates; the engine release, the player release, and one adapter per agent runtime.

3 · Business Intents

The bridge between meaning and action.

A Business Intent is a question or concern the organization commits to validate, measure and watch as the underlying semantics change. It is registered in Ground and consumed by Crew: when the meaning beneath an intent shifts, the intent sees it; when a crew pursues an objective, it inherits the intent's certified context.

4 · Ceez Crew

An agent has a job. A Crew has an objective.

Ceez Crew is the enterprise's AI workforce: teams of specialized agents with the knowledge, skills, tools and authority to pursue objectives — and the oversight to stay accountable. A single agent is often insufficient for multi-step work that crosses applications, functions and teams; a Crew decomposes that work across roles and runs it on certified Ground.

• Agent Studio

  Roles, instructions, constraints, model connections, autonomy tiers, immutable versions and validation.

• Teams

  Decompose complex objectives across research, analysis, policy, execution and verification roles.

• Skills

  Reusable capabilities attached to any agent or team — separating a worker's role from what it can do.

• Tools

  Connect agents to enterprise data, applications, APIs and workflows — from recommending to executing.

• Policies & Hooks

  Boundaries, checks and intervention points around every agent's behavior.

• Triggers

  Work starts from schedules, events or conditions — not only when a person asks.

• Evaluations

  Measure agent quality and readiness before increasing autonomy.

• Investigations

  Accumulate evidence across rounds to a conclusion.

• Workflow Composer

  Describe the work in plain language; get a runnable workflow.

• Autonomous Workforce

  Queues, goal daemons and briefings for continuous operation.

• Memory & Knowledge

  Tenant, team and agent memory, knowledge bases and graphs — with confidence and durable lessons.

4.1 · The objective model

Don't manage prompts — manage objectives. The objective is the unit a Crew is configured, governed and measured against. It carries ten components:

1. INTENT

   What does the business care about?

2. OBJECTIVE

   What must be accomplished?

3. SUCCESS CRITERIA

   How will we know it worked?

4. CREW

   Which digital workers pursue it?

5. KNOWLEDGE

   What enterprise context is required?

6. AUTHORITY

   What can the workforce do autonomously?

7. CADENCE

   When or how often should it operate?

8. EXCEPTIONS

   When must a human intervene?

9. OUTCOME

   What actually changed?

10. LEARNING

    What should the enterprise remember?

4.2 · Execution path of one objective

How the engine operations (§2.1) and Crew capabilities combine at run time. A run starts from a person, an event, a condition or a schedule; every step is bound to certified meaning and a pinned capability set before it executes.

1. 01
   Trigger

   A person states the objective, or a trigger fires on a schedule, event or condition — including a Business Intent whose watched semantics have changed.

2. 02
   Ground

   Terms in the objective are resolved to certified entities, metrics and rulings at a known version.

3. 03
   Plan & staff

   The Crew decomposes the objective into steps across research, analysis, policy, execution and verification roles.

4. 04
   Bind

   Each step receives exactly the skills, tool grants, knowledge and evals it is entitled to — pinned by digest so the run is reconstructible.

5. 05
   Execute

   Steps run on the enterprise's chosen agent runtime through the adapter (§6), inside policies and hooks.

6. 06
   Gate

   Actions beyond the objective's authority stop and route to a named approver; spend limits, one-click pause apply throughout.

7. 07
   Measure & evidence

   The outcome is measured against the success criteria; every decision and action is recorded in the audit trail.

8. 08
   Learn

   Durable lessons and new candidate meaning flow back into Ground (Sense, Observe). The next run starts from a richer state.

5 · Oversight & evidence

Shared across both products.

• Cockpit & Oversight

  Approvals, spend limits, one-click pause — operate and intervene in the workforce in real time.

• Memory & Knowledge

  Context and knowledge graphs and durable lessons, shared between Ground and every Crew.

• Audit & Evidence

  Trails for every decision and action: what ran, on whose authority, against which rule, at which version.

• Outcome Measurement

  Did the business objective move? Measured against the objective's own success criteria.

6 · Runtime & sovereignty

Runs on the runtime you already have.

The engine and the player are runtime-agnostic. A runtime executes a single step — a model-call cycle with tools. It never owns the route, the gates or the context; the platform does.

• Own instance

  Each client runs their own instance, in their own cloud or fully offline. Source records are read in place.

• Signed registry

  The core resolves every capability by digest from a signed registry — so what runs can be named exactly, reproduced later, and withdrawn in a single operation.

• The crossing

  The single path from an account into any shared catalog: runs an identifier scan, generalizes, re-evaluates, and requires a named human approval.

7 · Glossary

Glossary

Archetype

A family that adapts the engine to one lifecycle by setting its targets.

Business Intent

A concern the organization commits to validate, measure and watch.

Context steward

The human custodian of certified meaning after hand over.

Crossing

The governed path from an account into a shared catalog.

Digest

A content hash identifying an exact capability version in the signed registry.

FDE

Forward-deployed engineer; elicits what no source states and co-drives the run.

Gate

A workflow step requiring human sign-off (G1 spec, G2 write access).

Harness

The six-move structure every initiative runs on, carrying its live meaning.

Semantic contract

Reviewed meaning published with stable IDs, versions and provenance.