Get Smart Readiness Requests

AACM Compliance Policy

The readiness request should not just ask, “Can this machine join?”

It should ask:

Can this machine join under the current policy for the role it is requesting?

And for your side-thread with the Merry Men and BB, you can absolutely call that:

AACM Compliance Policy

That does two useful things:

1. Keeps AACM in the story.
2. Turns “how do we test AACM?” into something concrete.

The policy is what tells Get Smart how to test

The readiness request arrives with a requested role:

{
  "machine_id": "gsmr-lab-001",
  "requested_role": "aacm_demo_candidate",
  "requested_action": "join_managed_workflow",
  "policy_set": "aacm-compliance-policy-v0.1"
}

Then Get Smart says:

“Fine. For aacm_demo_candidate, what evidence is required?”

The AACM Compliance Policy defines that.

What the policy contains

The policy should define:

Policy section	Purpose
Role	What kind of machine is requesting admission
Required evidence	What the machine must provide
Required checks	What must be tested
Pass criteria	What counts as compliant
Review triggers	What sends it to human review
Remediation triggers	What sends it to AACM or another path
Prohibited actions	What AACM must not do
Output format	What AACM/Get Smart must return
Traceability	What evidence, rule version, and decision must be recorded

This becomes both:

• the readiness rulebook
• the AACM test specification

Lovely double-use. One scroll, two dragons. 🧾

The important separation

Get Smart does not need to know AACM’s secret inner workings.

Get Smart needs to know:

Given this policy, this input, and this evidence, what output should AACM produce?

That means you can test AACM from the outside.

Not:

“Show me your magic brain.”

But:

“Here is a known case. Here is the policy. Here is the expected classification. Does AACM produce the correct recommendation?”

That is exactly demo-readiness thinking.

Example policy logic

For a machine requesting AACM demo admission:

policy_id: aacm-compliance-policy-v0.1
role: aacm_demo_candidate

required_evidence:
  - machine_id
  - owner
  - requested_role
  - os_name
  - os_version
  - patch_status
  - agent_status
  - build_source

rules:
  - id: owner_required
    if_missing: owner
    status: insufficient_evidence

  - id: patch_status_required
    if_missing: patch_status
    status: review_required

  - id: outdated_patch_status
    if: patch_status == "outdated"
    status: remediation_required
    remediation_path: aacm_review

  - id: clean_machine_no_agent_required
    if:
      patch_status: current
      agent_status: not_installed
    status: approved
    agent_required: false

  - id: agent_only_if_remediation_approved
    if:
      status: remediation_required
    agent_required: policy_decision

The gem is this rule:

Clean machine, no agent required.

That preserves your whole design principle.

How this tests AACM

You create test cases.

Test case 1: Clean machine

Input:

{
  "machine_id": "gsmr-lab-001",
  "owner": "get-smart-lab",
  "requested_role": "aacm_demo_candidate",
  "os_name": "RHEL-compatible",
  "os_version": "9",
  "patch_status": "current",
  "agent_status": "not_installed",
  "build_source": "kickstart:rhel9-minimal.ks"
}

Expected output:

{
  "readiness_status": "approved",
  "agent_required": false,
  "remediation_required": false
}

Test case 2: Missing patch evidence

Expected output:

{
  "readiness_status": "review_required",
  "agent_required": false,
  "reason": "patch_status_missing"
}

Test case 3: Outdated machine

Expected output:

{
  "readiness_status": "remediation_required",
  "remediation_path": "aacm_review",
  "agent_required": "requires_policy_decision"
}

Test case 4: YeOldeBox

Expected output:

{
  "readiness_status": "legacy_exception_required",
  "agent_required": false,
  "reason": "legacy_or_vendor_restricted_machine"
}

That is how you test AACM without letting it run wild through the village with a wrench.

Where AACM sits

The flow becomes:

Machine readiness request
        ↓
Machine identity check
        ↓
AACM Compliance Policy selected
        ↓
Evidence collected
        ↓
Get Smart readiness rules applied
        ↓
Decision:
  approved / review_required / remediation_required / rejected
        ↓
Only if needed:
  route to AACM recommendation or remediation path

So AACM is not the gatekeeper by default.

Policy is the gatekeeper.

AACM is a possible evaluator/remediator under policy.

The phrase I’d use

AACM Compliance Policy defines what evidence is required, what checks are valid, what outputs are expected, and when AACM is allowed to recommend or perform remediation.

Or shorter:

The policy tells us how to test AACM, and when AACM is allowed to act.

That is the spine.

Phase One version

For the Camelot/Kickstart lab, your first target can be tiny:

Goal: prove that a machine built from a known Kickstart profile can submit a readiness request and be classified under aacm-compliance-policy-v0.1.

Minimum pieces:

• one sample Kickstart profile
• one sample machine evidence JSON
• one policy YAML
• one readiness assessment script/checklist
• one expected output JSON
• three test cases:
  • approved
  • review required
  • remediation required

That lets you say, truthfully:

Get Smart Machine Readiness can evaluate a machine readiness request against a named policy and produce a traceable status.

That is a real claim. Not vapor. Not “AI dust in a velvet pouch.”