Project: answer an incident question through a governed query plan

Last updated: 6 Oct 20265 min read

project

Parse an operational question into approved fields, compile a bounded tenant-scoped query and hold ambiguous or unauthorized requests.

Define the fixture

An operator asks for gateway-west incidents opened after a specific rollout. The system must identify the rollout event and translate its approved timestamp into a read-only incident filter. Add a second rollout with a similar name, a restricted notes field and a request for too many rows. The ambiguous rollout should produce a clarification request, not a guessed time boundary. Semantic grounding maps words to known fields and values.

Build the contract

Annotators provide the intended dataset, service, time boundary, projection and expected result type for each question. Record schema version and user role. Freeze a small database fixture with cases that distinguish wrong service, wrong rollout and wrong tenant. Keep data synthetic but realistic enough to expose a missing filter. A match on a trivial one-row database would not validate the plan. Group paraphrased questions by intent family before model evaluation.

Execute behind a boundary

Validate the plan shape and user scope, compile identifiers from an allowlist, bind values and enforce a limit. Use a read-only database identity with its own row policy. Log the semantic plan and compiled query shape without storing unnecessary private result data. Safe compilation prevents raw model text from becoming SQL; the application must still verify the result against the user’s question.

Gate the release

Report field-link errors, ambiguous questions correctly held, unauthorized-column attempts, tenant leaks, result correctness and query cost. Review both the generated plan and actual rows. A correct SQL string can still represent the wrong interpretation. The code below checks an approved plan and scope before compilation; a production release also tests the database’s independent access controls.

Implementation

def admit_incident_query(plan, user_scope):
    if plan.get("state") != "validated":
        return {"state": "clarify-or-review"}
    request = plan["plan"]
    if request["service_id"] not in user_scope["service_ids"]:
        return {"state": "deny", "reason": "service-scope"}
    if set(request["projection"]) - user_scope["field_ids"]:
        return {"state": "deny", "reason": "field-scope"}
    return {"state": "eligible-for-read", "tenant_id": user_scope["tenant_id"]}

validated = {"state": "validated", "plan": {
    "service_id": "gateway-west", "projection": ["incident_id"]}}
scope = {"tenant_id": "tenant-82", "service_ids": {"gateway-west"},
         "field_ids": {"incident_id", "opened_at"}}
assert admit_incident_query(validated, scope) == {
    "state": "eligible-for-read", "tenant_id": "tenant-82"}
assert admit_incident_query({"state": "unresolved"}, scope)["state"] ==     "clarify-or-review"

Performance and operating cost

Checking s permitted services and p projected fields is expected O(p) time with O(p) temporary space for the set difference. Actual query cost depends on database indexes and cardinality. The eligible state is not execution; separate authentication, read-only credentials and result checks remain mandatory.

Common Mistakes

Executing a plan that still contains an ambiguous rollout.
Using a model-supplied tenant value.
Testing only SQL syntax instead of returned rows and user intent.
Treating an application field allowlist as a substitute for database access policy.