1. Scope and Current-State Rules
Important: This SOP reflects the current implementation, not target-state marketing flow. The advisory plane can capture intent and generate a draft proposal, but it does not create missions automatically.
| Area |
Current State |
Operational Rule |
| Advisory / GenUI |
Advisory only |
Use /api/v1/advisory/declare-intent and /api/v1/advisory/propose-mission for intent and proposal generation. These do not create sovereign missions. |
| Mission lifecycle |
Implemented |
Use lock and sequential transition operations before execution. |
| Mission execution |
Implemented |
Use POST /api/v1/missions/{mission_id}/execute with mission inputs. Do not rely on an undocumented mode=governed payload. |
| Approvals |
Implemented |
Use approval requests and /api/v1/approvals/{id}/resolve or the alias approve endpoint. |
| Evidence |
Implemented |
Use /api/v1/evidence?mission_id=... and evidence bundle/proof-pack endpoints for verification. |
| AWS observability URLs |
Environment-specific |
Do not assume *.arka.aws.internal hostnames unless your cluster ingress has been explicitly configured with them. |
2. Prerequisites
- Deployed AWS environment with ARKA control plane, worker, Temporal, PostgreSQL, Redis, OPA, and Kafka/Redpanda components reachable.
- A valid bearer token for the target AWS environment.
- Known control-plane base URL, for example https://<control-plane-host>/api/v1.
- Operator account scoped to the client/account you intend to run against.
Token rule: Before doing anything else, prove the token is valid and scoped by calling GET /api/v1/auth/me.
export ARKAI_CONTROL_URL="https://<control-plane-host>"
export ARKAI_BASE_URL="$ARKAI_CONTROL_URL/api/v1"
export ARKAI_TOKEN="<valid-bearer-token>"
curl -s "$ARKAI_BASE_URL/auth/me" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Expected result: a valid identity payload including role/account information. If this fails, stop. Do not proceed with mission operations on an unverified token.
3. Health and Environment Verification
3.1 Control-plane readiness
curl -s "$ARKAI_CONTROL_URL/health/ready"
curl -s "$ARKAI_CONTROL_URL/health/dependencies"
Expected result: readiness and dependency checks return healthy responses for the deployed control plane.
3.2 Optional Kubernetes checks
kubectl get pods -n <arkai-namespace>
kubectl get svc -n <arkai-namespace>
Use the actual namespace configured in your cluster. Current repo defaults vary by Helm values and environment, so do not assume one namespace string across all deployments.
4. Optional Advisory Draft Flow
This is optional. Use it when you want business-language intent capture before manual mission creation.
It is advisory-only and does not create a mission record automatically.
4.1 UI path
Open the web console /insights page and submit the intended outcome, domain, scope, and risk constraints.
4.2 API path
curl -s -X POST "$ARKAI_BASE_URL/advisory/declare-intent" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"target_outcome": "Reduce churn in strategic migration accounts",
"domain": "migration",
"target_kpi": "churn_risk_score",
"scope_boundary": "IRIS enterprise accounts",
"time_horizon": "90 days",
"risk_constraints": ["no unauthorized outreach"]
}'
curl -s -X POST "$ARKAI_BASE_URL/advisory/propose-mission" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"domain": "migration",
"target_outcome": "Reduce churn in strategic migration accounts"
}'
Current-state limitation: the result is a proposal, not a created mission. You still need to create the mission through POST /api/v1/missions.
5. Create the Mission
Create a mission directly through the canonical mission router.
curl -s -X POST "$ARKAI_BASE_URL/missions" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"mission_id": "mission_iris_ops_001",
"blueprint_id": "blueprint.migration.core_control_runtime_v1",
"input_data": {
"account_scope": "iris_enterprise",
"time_horizon": "90d",
"objective": "reduce strategic migration churn"
}
}'
Expected outcomes:
- status = CREATED, or
- status = PENDING_APPROVAL if OPA requires approval at create time.
5.1 Verify mission creation
curl -s "$ARKAI_BASE_URL/missions" \
-H "Authorization: Bearer $ARKAI_TOKEN"
curl -s "$ARKAI_BASE_URL/missions/mission_iris_ops_001" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Confirm the mission exists and is scoped to the expected account.
6. Govern the Mission Before Execution
The current lifecycle model is sequential:
DRAFTED -> SIMULATED -> GOVERNED -> EXECUTED -> REVIEWED
Current code enforces lock-before-governed. Follow this order.
6.1 Lock the mission
curl -s -X POST "$ARKAI_BASE_URL/missions/mission_iris_ops_001/lock" \
-H "Authorization: Bearer $ARKAI_TOKEN"
6.2 Transition to SIMULATED
curl -s -X POST "$ARKAI_BASE_URL/missions/mission_iris_ops_001/transition" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{"target_status": "SIMULATED"}'
6.3 Transition to GOVERNED
curl -s -X POST "$ARKAI_BASE_URL/missions/mission_iris_ops_001/transition" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{"target_status": "GOVERNED"}'
6.4 Confirm lifecycle state
curl -s "$ARKAI_BASE_URL/missions/mission_iris_ops_001/lifecycle" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Expected result: mission is locked and lifecycle status is GOVERNED.
7. Execute the Mission
Use the canonical execute endpoint. Provide mission inputs as the payload.
curl -s -X POST "$ARKAI_BASE_URL/missions/mission_iris_ops_001/execute" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"run_reason": "aws_e2e_validation",
"source": "operator_runbook",
"inputs": {
"account_scope": "iris_enterprise",
"objective": "reduce strategic migration churn"
}
}'
Expected result: a running workflow response containing workflow and run identifiers.
7.1 Verify mission state after launch
curl -s "$ARKAI_BASE_URL/missions/mission_iris_ops_001" \
-H "Authorization: Bearer $ARKAI_TOKEN"
curl -s "$ARKAI_BASE_URL/missions/active" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Expected result: mission enters a running/native execution state.
8. Handle Approval Gates if Present
If mission creation or downstream decisions require approval, use the approvals API rather than older decision/approval aliases.
8.1 List approval requests
curl -s "$ARKAI_BASE_URL/approvals?mission_id=mission_iris_ops_001" \
-H "Authorization: Bearer $ARKAI_TOKEN"
8.2 Resolve an approval
curl -s -X POST "$ARKAI_BASE_URL/approvals/<approval_request_id>/resolve" \
-H "Authorization: Bearer $ARKAI_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"decision": "APPROVE",
"comment": "Approved for governed AWS validation"
}'
8.3 Retrieve governance trace
curl -s "$ARKAI_BASE_URL/approvals/trace/<decision_id>" \
-H "Authorization: Bearer $ARKAI_TOKEN"
9. Verify Evidence and Proof
Mission success is not complete until evidence is present.
9.1 Retrieve evidence chain
curl -s "$ARKAI_BASE_URL/evidence?mission_id=mission_iris_ops_001" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Expected result: a response with evidence_chain, ledger_root, and verification status.
9.2 Retrieve evidence bundle
curl -s "$ARKAI_BASE_URL/evidence/bundles/mission_iris_ops_001" \
-H "Authorization: Bearer $ARKAI_TOKEN"
9.3 Retrieve proof packs if available
curl -s "$ARKAI_BASE_URL/missions/mission_iris_ops_001/proof-packs" \
-H "Authorization: Bearer $ARKAI_TOKEN"
Fail-closed behavior: governed profiles return errors when evidence is missing. Treat missing evidence as a real run failure, not as a dashboard gap.
10. AWS Observability and Runtime Checks
Use the deployed environment's actual ingress/service names. The repo does not guarantee one fixed AWS DNS pattern.
| Component |
What to verify |
Current source of truth |
| Temporal |
Workflow created and progressing |
Temporal UI or workflow logs from the deployed namespace |
| OPA |
Policy service reachable; decisions recorded where applicable |
OPA service configured through deployed Helm values |
| Kafka / Redpanda |
Event pipeline healthy if used by the mission path |
Cluster service / console for the deployed environment |
| Grafana |
Operational telemetry and evidence-related dashboards if provisioned |
Deployed Grafana ingress, if configured |
10.1 Kubernetes log fallback
kubectl logs -f deployment/<worker-deployment-name> -n <arkai-namespace>
kubectl logs -f deployment/<control-plane-deployment-name> -n <arkai-namespace>
Use your real deployment names. The repository contains multiple deployment and namespace variants.
11. Post-Run Verification Checklist
- Token verified through /auth/me.
- Control plane healthy through /health/ready and /health/dependencies.
- Mission created under the correct account.
- Mission locked before transition to GOVERNED.
- Sequential lifecycle transitions completed successfully.
- Mission execution returned workflow metadata.
- Any approval requests were resolved through the approvals API.
- Evidence chain exists and returns a non-empty ledger root.
- Optional proof-pack retrieval works if enabled for the mission.
12. Known Gaps and Non-Claims
Do not treat this SOP as proof of automatic GenUI-to-mission creation. Current advisory endpoints generate draft intent/proposal objects only.
- This SOP does not assume fixed AWS hostnames such as temporal.arka.aws.internal.
- This SOP does not use static KPI state labels such as CONVERGING or STEADY as proof of success.
- This SOP does not rely on deprecated workflow or approval routes.
- This SOP does not claim Gold Master authority. It is a current-state operator runbook derived from the code.