Platform
SieF Architecture
Brain, Engine, Judge and Fleet: the authority each one holds, the four execution routes, and the contracts a framework extends.
Four systems, two of which use AI
The architecture separates deterministic authority from generative assistance, in the structure itself rather than in policy.
| Pillar | AI | Responsibility |
|---|---|---|
| Brain | No | Holds the domain rules, the job catalogue, routing, permissions and approval gates. Every job starts here. |
| Engine | No | Executes approved workflows and tools, produces records and files, and logs what happened. |
| Judge | Yes | Gives bounded advice to Brain where a case needs interpretation. Never authorises execution. |
| Fleet | Yes | Runs the model workloads Brain delegates, inside the resource policy the OS enforces. |
The ordering matters: Brain decides, Engine acts, Judge advises, Fleet computes. Advice is not a decision, and computation is not authority.
The four execution routes
Every piece of work follows one of four paths, and which one it followed is part of its record:
- Brain to Engine. The rules fully decide. Engine executes and records.
- Brain to Judge to Brain to Engine. The case needs bounded interpretation. Judge advises, Brain decides, Engine executes. The advice is kept with the record.
- Brain to Fleet to Engine. A marked gap needs generative work. Fleet fills only that gap, and the result is checked before it counts.
- Brain to a person to Engine. The decision belongs to a human. Work stops at the gate until an authorised person acts.
What a framework supplies
The operating system implements the universal core. A framework extends it through four packages and never patches it:
- Brain extension: domain rules, jobs, schemas, gates, approvals, fixtures.
- Engine extension: workflows, domain tools, integrations, records, failure and recovery behaviour.
- Judge extension: advisory scopes, evaluation criteria, escalation rules.
- Fleet workload manifest: the model capabilities required, the quality bars and the quotas, declared rather than requested at runtime.
A framework that needs the core to behave differently is asking for a change to the core, which is reviewed as one.
Capability promotion
A new framework may lean on bounded AI more at the start. Each resolved case can become a candidate rule, but a successful inference does not become a trusted rule by itself. Promotion requires regression tests, domain review, security and permission testing, a named approver, a version and rollback.
On a customer site, people approve new rules in the gate, customer-added rules may only tighten behaviour and need two approvers, and no model is trained there.