Assessment Objectives

Assessment objectives are the assessable leaves beneath controls in CMMC and compatible catalogs such as NIST 800-171A. The objective command group reads and updates their per-system implementation rows through the same governed public API used by MCP tools and the web workspace.

Read Objective Readiness

List all objectives for one control:

pretorin objective list \
  --framework-id cmmc-l2 \
  --control AC.L2-3.1.1 \
  --system "My System"

Each row includes the stable catalog objective ID, per-system implementation UUID, effective status and source, approval posture, conflict state, linked evidence count, and evidence-expectation coverage.

Use --open-only to show only objectives that still need work:

pretorin objective list -f cmmc-l2 -c AC.L2-3.1.1 --open-only

--open-only is an assessment-objective filter, not a CMMC score. It uses the status, approval, initialization, and conflict fields returned by the platform. It requires --control so the CLI can read the complete catalog objective set, including an uninitialized objective, in one bounded control-context call.

Framework-wide triage supports server-side status, conflict, limit, and offset filters:

pretorin objective list --status in_progress --only-conflicts --limit 100

Inspect one implementation UUID to see its determination statement, current narrative and API-token-authored draft, approval actor/time, evidence, expectation coverage, and merged history:

pretorin objective show <objective_implementation_uuid>
pretorin objective show <objective_implementation_uuid> --history-limit 100

Evidence-Expectation Coverage

Objective-linked evidence and expectation coverage are intentionally separate:

• Only operating evidence explicitly bound to an expectation makes it covered.
• Suggested evidence is labeled unconfirmed and never counts as coverage.
• Objective-linked evidence without any expectation binding is listed separately.
• A bound expectation absent from the active-tier coverage response is shown as unavailable; it is never silently dropped or treated as covered.

An objective can therefore have linked evidence while one or more of its bound expectations remain uncovered.

Author and Approve Objectives

Initialize rows for a control when needed. Seeding is idempotent; current CMMC attachments normally materialize these rows automatically:

pretorin objective seed AC.L2-3.1.1 --framework-id cmmc-l2

Start work, author the narrative draft, and manage evidence:

pretorin objective start <objective_implementation_uuid> --reason "Begin assessment"
pretorin objective narrative <objective_implementation_uuid> \
  "Authorized users are identified through the governed account inventory."
pretorin objective link-evidence <objective_implementation_uuid> <evidence_id>
pretorin objective unlink-evidence <objective_implementation_uuid> <evidence_id>

Approve only after the platform’s grounding prerequisites are satisfied:

pretorin objective approve <objective_implementation_uuid>
pretorin objective reopen <objective_implementation_uuid>

API tokens may approve grounded objective leaves and the platform records agent attribution. These commands never approve the parent control. A 409 approval failure prints the server’s structured prerequisite list; --json preserves the error code, HTTP status, complete details, and missing_prerequisites array.

JSON Output

Place the global flag before the command:

pretorin --json objective list -f cmmc-l2 -c AC.L2-3.1.1
pretorin --json objective show <objective_implementation_uuid>

JSON output is complete and untruncated. It preserves the server response and adds explicit readiness and expectation_coverage projections for scripting.