Skip to content

Objective Intake And Objective Model

Objective Intake is the canonical read-only entry boundary where raw operator intent becomes a candidate objective artifact. It is earlier than Keeper coordination, strategy selection, loop proposal, approval, scheduling, dispatch, execution, and LifeVault retention.

This phase is scaffold only. It defines inert artifacts and deterministic validation. The Objective Intake Resolver is advisory and read-only only. It may inspect, validate, score, and recommend clarification for candidate artifacts, but it does not accept or reject candidates with authority. This phase does not add runtime routing, Keeper integration, Oracle integration, approval creation, scheduling, dispatch, execution, or memory writes.

Boundary

User Intent
  -> Objective Intake Candidate
  -> Objective Intake Resolver Assessment
  -> Lich Intake Gate
  -> Governed Keeper Objective only after Lich approval
     or explicit Lich no-approval-required determination

User intent is the raw operator expression. An objective intake candidate is a proposed objective extracted from user intent, not an accepted objective. A resolver assessment is evidence and recommendation only. Lich owns the gate that allows an intake candidate to become a governed Keeper objective. A Keeper objective exists only after Lich approval or an explicit, scoped, reviewable Lich determination that no approval is required for Keeper coordination. A Keeper job is a later coordination artifact and is not created by intake.

Authority Posture

Objective Intake may classify, inspect, validate, score readiness, and recommend clarification. It must not create Keeper objectives or jobs, execute work, schedule work, approve work, dispatch workers, mutate runtime state, or write LifeVault memory. Resolver readiness never implies Lich approval or Keeper eligibility. Missing required fields, unknown fields, or unclear authority fail closed.

The scaffold encodes this with explicit authority posture fields:

  • classification_allowed: true
  • validation_allowed: true
  • keeper_job_creation_allowed: false
  • execution_allowed: false
  • scheduling_allowed: false
  • approval_allowed: false
  • dispatch_allowed: false
  • runtime_state_mutation_allowed: false
  • lifevault_write_allowed: false
  • fail_closed_on_unknown: true

Artifacts

The objective model is defined in app/objectives/model_schema.py. The intake candidate model is defined in app/objectives/intake_schema.py. The read-only resolver is defined in app/objectives/intake_resolver.py and documented in Objective Intake Resolver. The read-only Lich gate artifact layer is defined in app/objectives/lich_intake_gate.py and documented in Lich Intake Gate Artifacts. These modules expose JSON-compatible schema mappings, deterministic SHA-256 hashing helpers, fail-closed validation helpers, advisory assessment data, deterministic assessment rendering, review request artifacts, and explicit decision artifacts.

The required objective fields are:

  • objective_id
  • title
  • summary
  • requester_ref
  • source_transport
  • created_at
  • status
  • priority
  • risk_level
  • authority_posture
  • success_criteria
  • constraints
  • required_evidence
  • approval_requirements
  • retention_policy
  • redaction_status
  • lifecycle_refs

Intake candidates include those fields plus raw user_intent, a candidate_id, deterministic advisory resolver classification, and clarification questions when intent is incomplete or ambiguous. Canonical resolver classifications are:

  • incomplete
  • ambiguous
  • unsafe
  • governance_blocked
  • ready_for_lich_review

ready_for_lich_review means only that the candidate is complete enough for Lich governance review. It is not acceptance, approval, Keeper eligibility, scheduling authority, execution authority, dispatch authority, or LifeVault write authority. Legacy serialized accepted_candidate values are normalized to ready_for_lich_review on read; canonical fixtures and hashes emit ready_for_lich_review.

Resolver assessment output includes candidate identity, title, advisory classification, deterministic completeness score, missing fields, ambiguity reasons, governance blockers, unsafe reasons, clarification questions, authority summary, execution_authority: none, mutation_authority: none, lich_gate_required, keeper_job_created: false, and memory_written: false.

Lich Intake Gate artifacts represent the next boundary without invoking Lich runtime services. A review request binds the candidate hash and resolver assessment hash for audit. A decision records one of approved_for_objective_creation, clarification_required, rejected, or no_approval_required. Only approved_for_objective_creation and no_approval_required may set keeper_handoff_authorized: true, and that flag authorizes only future Keeper objective creation by a later governed step. Every decision keeps execution, mutation, memory, schedule, and dispatch authority set to none.

Completeness scoring is based only on explicit fields: identity, requester, scope/title/summary, success criteria, constraints, evidence requirements, approval requirements, retention policy, lifecycle references, authority posture, and redaction status. Missing required governance fields classify as incomplete. Invalid non-missing schema failures classify as governance_blocked. Multiple targets or unclear target language classify as ambiguous. Any implied execution, scheduling, dispatch, Keeper job, runtime mutation, or LifeVault authority classifies as unsafe.

Inert Fixtures

Example artifacts live under app/objectives/fixtures/. They are static fixtures for validation and documentation. They do not create jobs, approvals, schedules, dispatches, runtime state, or memory.

The Lich intake gate fixtures include one ready candidate review request and decision examples for clarification required, approved for objective creation, rejected, and explicit no-approval-required outcomes. These are also inert fixtures and do not create Keeper objectives or Lich approvals.

Governance Relationship

Objective Intake is the entry boundary for the Governance Kernel lifecycle. It does not replace Objective Context Resolution and does not authorize Keeper coordination. Intake produces candidate objective artifacts and resolver assessments. Lich decides whether the candidate may become a governed Keeper objective, including any explicit no-approval-required determination. Context resolution later binds approved governed objectives safely and unambiguously.