This is the operating model for the two systems developed in this series: a cloud execution gateway and a SIEM assessment service. Both evaluate evidence, but they exercise different authority. One may stop an operation before it happens; the other helps interpret recorded activity. Their records and release criteria should reflect that distinction so a successful detection pilot does not silently become permission to take consequential response actions.
The examples below are proposed application records and rollout practices. They are not a claim that an enterprise implementation has been audited, deployed, or certified.
Preserve facts, assessments, and enforced outcomes
An auditor investigating an allowed resource change needs to know what the gateway saw, what the evaluator returned, what contract applied, and what the executor did. A security analyst reviewing an access alert needs the same separation between observation and interpretation. If those layers are collapsed into a single “risk” field, the organization cannot reliably determine whether an error originated in the source, the evaluator, or the application.
| Record layer | Example | Meaning |
|---|---|---|
| Source evidence | Identity session, approval, resource snapshot | What a particular source reported |
| Model assessment | Returned values for versioned questions | What the evaluator concluded from supplied state |
| Enforced outcome | Held write, executed action, escalated case | What the service or reviewer actually did |
Historical context matters. A current inventory entry may not establish the environment or dependency state at the time of an earlier action. Retain relevant versions or record that historical evidence is unavailable. Source timestamps and collection timestamps should remain distinguishable, particularly when SIEM data arrives late and changes an investigation after its first assessment.
Make the decision reconstructable without inventing an explanation
Store the actual service output and the versioned questions that give it meaning. A probability is difficult to interpret without the statement it evaluates; a category is ambiguous without its definition. Record the model identifier when available, evidence revision, routing configuration, and resulting authorization or case transition. Recalling the model later may help reproduce a test, but it is not a substitute for preserving the original response.
{
"decision_id": "decision-902",
"activity_id": "activity-208",
"evidence_revision": 3,
"evidence_refs": ["event-101", "approval-82", "inventory-9"],
"question_set_version": "access-review-v3",
"execution_contract_version": "cloud-ops-v2",
"assessment_record": "assessment-902",
"outcome": "HOLD",
"enforcement_reason": "required_approval_missing",
"execution_status": "not_started"
}
For executed actions, add normalized arguments, resolved target, acting identity, approval binding, provider request identifier, and reconciliation outcome. For security cases, retain earlier assessment revisions and the evidence changes that caused reevaluation. These records establish the operational history without claiming access to the model's internal reasoning.
Jev provides structured judgments rather than a generated narrative. If another model produces a readable explanation, label it as a summary and validate its references against the recorded evidence. It should not be presented as the original evaluator's reasoning. TypeSafe documentation
Retain evidence without creating another data exposure
The audit design should minimize unnecessary duplication of sensitive material. References to controlled source records are often preferable to copying customer payloads, credentials, or full query results into every alert. When a snapshot is necessary for reconstruction, store it with the appropriate access controls, retention policy, and access logging. Case summaries can expose limited context while authorized investigators retrieve the underlying evidence separately.
Hashes can identify records and help detect changes, but they do not replace retained evidence when a source disappears. Nor does adding a hash make a mutable store independently trustworthy. Integrity depends on the storage design, access authority, and retention controls. The record should allow an investigator to establish both what was evaluated and how that evidence was protected over time.
Before sending enterprise context to a hosted evaluator, verify the service's actual data handling, retention, regional availability, contractual terms, and permitted use for the relevant data class. Those are procurement and architecture inputs that this series does not establish for Jev. Minimize the supplied context where possible, but do not remove facts essential to the judgment without evaluating how that changes performance.
Assign operational ownership and authority
Platform engineering should own the execution boundary and its reliability, while resource owners define the operations eligible for automation. Security engineering owns detection coverage, triage behavior, and any response workflow. A named service owner should manage question definitions, evaluation data, model changes, and releases. Without these responsibilities, a changed prompt or a broken inventory feed can alter production behavior without an accountable decision-maker.
Human overrides need evidence and authority of their own. Record why a reviewer changed the outcome and whether new information was supplied. An override is valuable feedback but is not automatically a correct label for future evaluation; disputed cases need adjudication. For employee-related investigations, preserve appropriate review mechanisms and restrict sensitive case material to authorized personnel.
Introduce autonomy through separate release stages
Begin with offline replay using historical cases and synthetic failures. Establish telemetry coverage, reference labels, enforcement behavior, and baseline performance before changing production authority. Next, run in shadow mode: compute assessments while the existing execution or review path remains authoritative. This reveals operational gaps such as late evidence, queue growth, and missing approvals that an offline dataset may not capture.
Assisted review is a useful subsequent stage because it can improve evidence collection and routing without automatically closing difficult cases. Measure whether analysts reach independently supported conclusions faster, and sample cases without model suggestions to detect automation bias. Only after those results should the organization consider automatic execution for selected actions or automatic closure of well-supported routine alerts, each with its own acceptance criteria.
Containment deserves a separate release. Account suspension, credential revocation, or destination blocking can interrupt legitimate operations even when motivated by a security concern. A good assessment result does not by itself establish authority for that action. Define the evidence, approvals, reversibility, and ownership of the response independently.
Make rollback and change evaluation part of the service
Set stop conditions before deployment, including an execution bypass, an unsafe automatic action, loss of durable decision recording, or a material increase in missing evidence. Keep a tested way to disable automatic behavior while preserving visibility and the existing manual path. Model versions, question changes, parsers, and inventory sources can all affect results, so relevant changes need regression evaluation and a recorded release decision.
The CTO's final proposal should specify protected operations, evidence coverage, measured errors, supported automation, review requirements, operating cost, and unresolved failure modes. The benchmark methodology provides the performance evidence; the operating design establishes who controls its use. Together, they make adoption a bounded engineering decision that can be inspected and revised as the system changes.
Frequently asked questions
Are Jev outputs sufficient evidence of compliance?
No. They are assessments of supplied evidence. Compliance conclusions require the applicable obligations, reliable source records, controls, and authorized review; a model output alone does not establish them.
What should be logged for every Jev decision?
Record the evidence references and versions, question definitions, actual model output, available model identifier, execution contract, timestamps, and enforced outcome. Add approval and execution details when an action is performed.
Should detection and prevention use the same rollout approval?
No. Evaluating recorded activity and authorizing future actions create different operational risks. Release each capability with its own scope, acceptance criteria, authority, and rollback behavior.