Core concepts

Jive is a state observability layer for scopes. It reconciles Criteria (ideal state), Claims (reported state), and Evidence (actual state) to compute Integrity and detect Drift.

Scopes

Every unit of work is a scope with a kind: product, feature, project, milestone, or task. Tasks are optional and not a primary workflow. Scopes can be nested to match how your organization works, and any scope can be the root of your current view.

Each scope keeps multiple state systems separate:

• Lifecycle: human planning state (planned/live/archived for long-lived scopes; planned/in_progress/done for temporary scopes).
• Integrity: truthfulness of the claimed state (Verified, Drift, Unverified, Unknown).
• Dependency: whether it is blocked by other scopes.
• Health: optional risk signal (On track, At risk, Off track).

Relationships

Relationships are explicit and typed:

• contains: parent -> child hierarchy (outline view and rollups).
• depends_on: ordering constraints (dependency graph and blocking).
• scopes_to: many-to-many association (for example, a project spanning multiple features).

Hierarchy stays clean with a single canonical parent where needed. Cross-cutting associations use scopes_to.

State systems

Lifecycle and integrity are separate by design. A scope can be lifecycle "done" but integrity "drifted" if evidence does not support the claim.

Dependency state is computed from depends_on relations and does not change integrity directly.

Claims, evidence, criteria

Signals from tools are classified as claim or evidence:

• Claims: reported status from tools or docs (for example, Jira status).
• Evidence: observed signals that prove outcomes (approvals, checks, deploys).

Criteria evaluate evidence and return PASS, FAIL, or UNKNOWN. Evidence can expire, and stale signals become UNKNOWN until refreshed. Claims never set integrity on their own.

A criterion should include evaluator logic, not only a label. In practice, this means users define the evaluator type, selected inputs, and explicit PASS/FAIL/UNKNOWN conditions.

Drift

Drift is a comparison, not a criterion. When a claim condition is true (for example, "Jira status = Done"), linked criteria must PASS. If any linked criteria FAIL or are UNKNOWN, the scope is in Drift with a clear explanation and provenance.

Integrity rollups

Parents roll up integrity deterministically from required children:

• If any required child is Drift -> parent Drift
• Else if all required children Verified -> parent Verified
• Else if any required child Unknown -> parent Unknown
• Else -> parent Unverified

Optional children do not block parent verification by default.

Timeboxes

Timeboxes (sprints, quarters, custom ranges) are filters, not containers. A scope can be planned in, executed in, or reported in a timebox without changing the hierarchy.

Examples

Example 1: Scope hierarchy with drift

Product: Payments

• Feature: Checkout
  • Project: 3DS rollout
    • Milestone: API contract finalized

Claimed state:

• Jira status = Done

Criteria:

• Required review approval = missing (UNKNOWN)

Outcome:

• Integrity = Drift (claim says done, evidence is missing)

Example 2: Dependencies stay separate from integrity

Milestone: Launch to production

• Integrity = Verified (evidence passes)
• Dependency = Blocked (depends_on a compliance review that is not verified)

Result: the milestone is true, but blocked by ordering constraints.