Compliance, finance, operations

Three services share one request and response shape:

Each takes an AnalyzeComplianceRequest (system_context) and returns an AnalyzeComplianceResponse with these fields:

• compliance_status: Pass, Warning, Fail, or Unable to Assess.
• violations (ComplianceViolation): the category, severity, description, related rule and remediation for each finding.
• audit_trail.
• spoken_response.
• orders: remediation orders (see below).
• live_data_note.

How a verdict is produced

The compliance agent reads its system prompt from the compliance.jinja template. It then assembles the system state for the model, and the model answers in TOON. See Structured output.

Configuration values are labelled as declarations. Environment values such as ENFORCE_AUDIT_LOGGING, REQUIRE_HITL, DATABASE_ENGINE and PRIMARY_SERVER_URL go to the model marked OPERATOR DECLARATION, followed by a NOTE TO THE ASSESSOR: a declaration is what an operator asserted, not evidence that a control is implemented. Facts the code can establish for itself are marked OBSERVED. One example is that audit logging runs on every call and no code path disables it.

No usable answer means no verdict. With no model plane, or when generation times out or fails, the status is Unable to Assess with the reason, and the failure is audit-logged. It is never a pass, and never an invented finding.

live_data_note says which live data was read. A current server always sets it. FACE has no mapping from a domain (compliance, finance or operations) to a specific connection and table. So the note tells the reader that the verdict rests on the session context sent with the request and on the instance’s own configuration.

Remediation orders and the workflow

A RemediationOrder is the dispatchable form of a finding. It’s shaped like an evidence document: a subject, facts read from records (specifications), coded determinations, citations, deadlines, ordered steps, and a seal written at approval.

An order may not contain any of the following:

• A step whose parameters weren’t read from a record. A step that needs an unmeasured figure is not emitted.
• A department FACE inferred. FACE receives no org chart. An external service_provider, such as a carrier named on the cited record, may be derived.
• A deadline with no authority. A date appears only when a cited contract clause, SLA or statute supplies it.

Order ids are stable (the rule id plus the subject), so an operator’s routing and decision survive the next analysis. The operator’s half of an order is stored apart from the derived half and merged when the order is read:

    flowchart LR
    A[Derived order<br/>NOT_ROUTED] --> B{Operator addressed<br/>this order?}
    B -- AssignRemediation --> C[OPERATOR_ASSIGNED]
    B -- no --> D{Routing rule for<br/>this category?}
    D -- SetRemediationRoute --> E[OPERATOR_ROUTING_RULE]
    D -- no --> F[stays NOT_ROUTED]
    C & E & F --> G[DecideRemediation<br/>DRAFT / APPROVED / REJECTED / SENT]
  

• AssignRemediation addresses one order to a department and contact. The server records assigned_by from the verified session, and ignores any author fields the client sends.
• SetRemediationRoute, ListRemediationRoutes and DeleteRemediationRoute manage a standing table. The table maps a finding category, matched exactly, to a department. An order routed by the table says so (OPERATOR_ROUTING_RULE), which is distinct from a person addressing that particular order. A person’s assignment always takes precedence over a rule.
• DecideRemediation records the human decision (RemediationDispatch). An empty state means nobody has decided yet, which is not the same as DRAFT. decided_by is the verified subject. FACE sends nothing by itself. SENT records something a human did outside the platform, and channel records how.

RemediationAssignment.basis takes one of these values:

An empty orders list is a valid response. The overlay and routing apply to whatever orders the analysis produced.

Rules

RulesService serves the rules that the rules-reconciliation agent recognises in the data:

• ListRules, AnalyzeCode and CheckCode read.
• UpdateRulePolicy sets only the operator-owned enforcement posture (RulePolicy). It can’t edit the agent’s findings (name, logic, proposed code or reconciliation_status). An operator who could overwrite a finding could make the cockpit agree with them.

What this does not establish

• A Pass is the model’s reading of the context it was given. It isn’t an audit of the live systems. Read live_data_note.
• Operator declarations are claims about the environment, not controls the system has verified.
• An order with an assignment has not necessarily been sent. Only a recorded SENT dispatch says a person sent it.