Blueprint · operating model

JobCache-facing operating stack

Source rights, corpus provenance, customer promises, and commercial separation constrain JobCache operation.

Cell 2.4 · operations · governance · evidence
  • Source and content rights to Corpus provenance: requires
  • Service commitments to Paid-placement boundary: constrains
requiresconstrains
obligationopen

Source and content rights

Acquire, retain, transform, publish, correct, and remove by declared policy.

Legal and product
obligationopen

Corpus provenance

Every claim remains attributable and contestable.

Product and data
obligationopen

Service commitments

Freshness, availability, support, export, and retention.

Product owner
boundaryopen

Paid-placement boundary

Advertising and organic relevance remain distinguishable.

Product owner
product dutiescontrols implement obligationsshared controls and evidence
  1. 01 · obligation · open Source and content rights

    Acquire, retain, transform, publish, correct, and remove by declared policy.

    Legal and product
  2. 02 · obligation · open Corpus provenance

    Every claim remains attributable and contestable.

    Product and data
  3. 03 · obligation · open Service commitments

    Freshness, availability, support, export, and retention.

    Product owner
  4. 04 · boundary · open Paid-placement boundary

    Advertising and organic relevance remain distinguishable.

    Product owner

Flows

  • Source and content rights Corpus provenance requires
  • Service commitments Paid-placement boundary constrains
as built target / open Boundary arrows open the neighbouring module; ports stay machine-only

Operating Stack

Purpose

Translate the external and self-imposed conditions of operating the products into concrete system constraints, controls, evidence, and responsibilities. This is broader than legal.

The canonical translation path and source-backed register are defined in Operating Obligation Model. Its machine record is explained in Operating Obligation Record and encoded in architecture/operating-obligations.ts.

Categories

Category Questions the architecture must answer
Privacy and GDPR What personal data exists, why, where, for how long, and how is access/erasure proven?
AI governance Which AI systems and purposes exist, what risk class applies, and what human explanation or control is required?
Source and content rights What may be acquired, retained, transformed, published, corrected, or removed?
Security Who and what may read or change each plane, and how is compromise contained?
Retention and records Which evidence is immutable, aged, compacted, exported, or deleted?
Audit and accountability Which actor or policy caused a consequential decision or state change?
Reliability and resilience What degrades, fails over, recovers, and communicates incidents?
Financial operation Which quotas, free tiers, budgets, and unit costs gate work?
Accessibility and inclusion Can people use and understand the products across abilities and devices?
Change management Which decisions, releases, migrations, and reversals require evidence or approval?

“EU AI Act” is not a label to paste onto the diagram. Its applicable duties must become specific requirements linked to the relevant AI purpose, provider, data flow, product experience, operator control, and evidence.

Invariants

  • Policy is versioned and attributable.
  • A legal or operating requirement links to an enforceable control and observable evidence.
  • Product-specific obligations extend this stack; they do not fork it silently.
  • The operating stack constrains Management but does not itself become a runtime superuser.

Decisions still required

This module needs a real obligations register, jurisdiction and role analysis, data inventory, retention schedule, AI-system inventory, threat model, and accountable owners. Legal advice and product strategy remain human-authority inputs; agents can structure and trace them.

Source: architecture/modules/operating-stack.md