authorized
A current, signed authorization manifest covers the operation.
LAKA Volumetric Security Grammar · version 1.0.0
Security, written as grammar.
A checklist asks whether a control exists. A volumetric grammar asks how that control behaves — across 10 internal variables, 14 measurement meta-variables and five change levels, from baseline visibility to paradigm change. Every operation is a full sentence, and every active operation passes an authorization gate first.
This is a defensive, authorization-first reference. It does not automate exploitation; the default answer to any unauthorized, out-of-scope or unverified operation is no.
The unit of analysis
The SECURITY_UNIT
Every assessed thing is described with the same 16-component sentence. A unit missing its authorization, owner or failure mode is incomplete by definition.
SECURITY_UNIT =
OBJECT + CONDITION + THREAT + WEAKNESS + CONTROL + ACTION + TOOL
+ EVIDENCE + OUTCOME + FEEDBACK + CONSTRAINT + FAILURE_MODE
+ AUTHORIZATION + OWNER + TIME + CHANGE_LEVELOBJECT
CONDITION
THREAT
WEAKNESS
CONTROL
ACTION
TOOL
EVIDENCE
OUTCOME
FEEDBACK
CONSTRAINT
FAILURE_MODE
AUTHORIZATION
OWNER
TIME
CHANGE_LEVEL
The governing production rule
Authorization first. Deny by default.
One rule governs every operation the grammar can describe. It is served as code at POST /v1/authorize-check — give it the state of the five gates and it returns allow or deny, with the failed conditions named.
IF authorized
AND target_is_in_scope
AND mode_is_allowed
AND preconditions_are_true
AND rollback_is_verified_when_change_is_possible
THEN execute_the_least_invasive_action
USING an_allowlisted_tool
WITH rate_limits + timeout + evidence_capture + kill_switch
ELSE deny_and_record_the_reasontarget_in_scope
The target is explicitly listed in the manifest for the environment in question.
mode_allowed
The execution mode (inventory, audit, passive, active, change) is allowed by the manifest.
preconditions_true
All declared preconditions hold — ownership proof, rate limits, kill switch, maintenance window where required.
rollback_verified
Where the operation can change state, rollback and backup/restore evidence is verified first.
What is in the package
15
Chapters
8
JSON Schemas
7
Worked examples
9
Deny rules
Counts derive from the corpus at load time: 15 chapters, 8 document schemas, 7 schema-conformant worked examples, 9 deny-first policy rules, 10 adopted standards and 8 registered tool classes — all served at /v1.
Three planes of work
Observe. Verify. Change.
Passive verification
Continuous read-only observation: inventory, audit, monitoring, drift detection and evidence capture. Always on, never mutating.
Controlled active testing
Authorized, rate-limited, evidence-capturing verification of client-owned targets — gated by a signed manifest, exact scope and a kill switch.
Guarded change
Configuration change only inside a maintenance window, with verified backup, verified rollback and lockout-risk acknowledgement.
Read this before you use it
A defensive reference, not an attack tool.
A specification and reference set — not an attack tool, a scanner, a certification or a completed assessment. It does not automate exploitation. Active or state-changing operations require a valid authorization manifest, an in-scope target, an allowed mode, verified preconditions and verified rollback.