Functions — วางแกนฟังก์ชันรอบโมเดลที่พลาดได้Keep a Functional Core Around a Fallible Model

1. The engineering problem

The first refactor is familiar to experienced programmers: separate decisions from effects. A pure function receives values and returns a value without reading credentials, calling a provider or writing files. An imperative shell coordinates those operations. Gary Bernhardt's Boundaries talk makes simple values the interfaces between components [1]. For an AI workflow, that division gives us a stable place to test policy while the model remains replaceable.

In the companion, core.py contains input_check, authorize, output_check and quality_gate. runtime.py owns ordering, provider calls, budgets and trace assembly. A provider object supplies decide, generate and judge. FixtureProvider makes those boundaries visible without a network connection. JevProvider implements real semantic decisions as an optional adapter. Generation remains a supplied candidate in that adapter; the course does not quietly pretend Jev writes code. A production generator would be a separate adapter with its own version, prompt and usage record.

2. The boundary to design

Notice that functional purity does not make a semantic judgment deterministic. The response is an explicit input to a pure policy function, so the same response and policy produce the same routing decision. A different model response can still change the workflow. This distinction is useful during incident review: replay recorded values to inspect policy behavior, then run a separate live experiment to investigate model variation. Neither experiment substitutes for the other.

3. Read the implementation

Implementation excerpt from the companion. Run the complete lesson below with its imports and fixtures.

def authorize(request, principal):
    # principal comes from the application's auth layer, never from model output.
    if principal != "maintainer" or request["repo"] != "demo/shop":
        return Gate("reject", "permission_denied")
    if request["action"] != "draft_patch":
        return Gate("reject", "action_denied")
    return Gate("pass", "draft_capability")

Keep principal identity outside the model-facing issue. authorize(request, principal) reads the authenticated caller supplied by the application. Repeating the call with the same values yields the same verdict; changing principal from maintainer to guest yields permission_denied. We can test this without a mock server or API key. The tradeoff is a little more explicit plumbing. In return, a new model provider does not silently inherit the power to grant itself access. For larger applications, use typed interfaces and dependency injection to preserve this division across modules.

4. Compare the outcomes

The following output comes from scripted fixtures that verify architecture behavior. It is not a measurement of live Jev accuracy, latency, or cost.

{
  "same_input_same_policy": true,
  "reviewer": "permission_denied"
}

5. Run, break, and explain

Part 02 code · Implementation · Tests: test_permission_stops_before_inference · Exercise

git clone https://github.com/Anirach/ai-core-engineering-workbench.git
cd ai-core-engineering-workbench
git checkout 18cdfcd4156d3d02acb8badf3b3a0a823113e0ed
python3 -m workbench.lesson 2
python3 -m unittest tests.test_boundaries.BoundaryTests.test_permission_stops_before_inference -v

Your turn

Move an existing permission check into a pure function. Test two principals against the same model response.

Keep three artifacts: the input you tried, the resulting state and reason, and an explanation of which boundary owns that result. Do not change an expected result merely to make a test pass.

6. Sources and limits