Imagine you're building furniture from IKEA instructions. Hand someone a photo of the finished bookshelf and say "build this" — that's the single-prompt LLM baseline, and it works about 15% of the time. Now hand them step-by-step instructions: identify the parts, check each piece against the diagram, lint the screws, test the joints before you tighten anything. That's what this paper does for access control policy generation — and it triples the success rate. Still only lands half the time, but the failures are now traceable. The committed claim: structured decomposition of natural-language access control policies (NLACPs) into a multi-stage pipeline — detection, extraction, schema validation, linting, compilation, test generation — raises end-to-end deployable correctness from 15.3% to 50.3% on 372 ACRE-benchmark statements. A policy counts as correct only if it compiles, passes lint, and survives both positive and negative test cases. That's an honest bar. The architecture is straightforward software engineering wrapped around LLM calls. Each stage is a separate module: first detect whether a statement is actually an access control policy, then extract subject-action-resource triples, validate against a schema, generate Rego code for Open Policy Agent, lint and compile it, then auto-generate and execute test cases. The key insight isn't any single module — it's that decomposing the problem into verifiable stages lets you catch failures early and gives the LLM a narrower task at each step. This is the "tool use as guardrails" pattern that's becoming standard in production LLM systems. The ladder comparison is minimal but informative. The baseline is a single-prompt LLM given the same natural-language policy and asked to produce Rego directly. On security-critical patterns, the gap widens dramatically: deny semantics go from 37.5% to 87.5% correct, ownership conditions from 40% to 100%, status qualifications from 55.6% to 100%. These are the patterns where a wrong answer is a security hole, not just a bug. The paper doesn't compare against any non-LLM baselines (hand-written policy generation tools, rule-based transpilers) or against other structured LLM approaches. Integrity is mixed. The ACRE benchmark with 372 annotated statements is a real community dataset, and the correctness bar — compilation + lint + positive/negative tests — is stricter than most LLM evaluation setups. But validation is entirely self-contained: the system generates its own tests and grades its own homework. There's no independent human audit of whether the generated tests actually capture the policy intent, which is the load-bearing question. A policy that passes its own auto-generated tests might still be wrong if the test generation module misunderstood the same thing the code generation module did. The 50.3% ceiling is the elephant in the room. For production access control — where a wrong policy means unauthorized access or denial of service — a coin flip isn't deployable without human review. The paper is honest about this implicitly (it reports the number plainly) but doesn't discuss what the failure modes look like or how a human-in-the-loop workflow would integrate. The real milestone isn't 50% → 100% on this benchmark; it's demonstrating that the failure cases are safe failures (over-restrictive rather than over-permissive) and that the pipeline flags when it's uncertain. The obvious next experiment is scaling to more complex, multi-clause policies and testing on real enterprise policy sets rather than atomic ACRE statements. Each ACRE statement is a single subject-action-resource triple — real-world policies involve conditionals, role hierarchies, temporal constraints, and exceptions. The authors likely didn't run this because ACRE is the available annotated benchmark, and building a complex-policy dataset is expensive. But the question of whether decomposition still helps when the policies themselves are compound is the one that matters for deployment.
