Skip to main content

A HUMAN's call on an object.

POST 
/api/threats/designate

This is an ROE-relevant act, not a UI toggle. Our doctrine says kinematics alone may never reach hostile (a fast, inbound, unidentified contact maxes out at suspect); operator designation is the sanctioned path there. The runtime installs it on the ThreatManager on the next tick, and the resulting state change is persisted as threat.v1 (the change-signature includes designation + affiliation, so a declaration on an already-confirmed threat is recorded rather than silently vanishing — it previously did).

SECURITY: the attribution here is NOT trustworthy yet

by is supplied by the caller and never verified, and this whole /api scope is unauthenticated (the walking skeleton runs tokenless in dev — see router.rs). So the audit trail records a claim about who decided, not a proven identity: anyone who can reach this port can declare anything hostile, under any name.

That is a system-wide posture, not a hole unique to this route — PUT /api/engagement/mode, which sets the weapons-release autonomy gate, is equally open. Gating only this endpoint would buy no real safety while creating a false impression that designation is authenticated. The fix is the /v1 authenticated scope (scaffolded, childless) growing to cover the mutating surface, tracked separately. Until then: do not treat by as identity, and do not expose this port outside a trusted network.

Request​

Responses​

the recorded declaration; attribution is the caller's unverified claim