Private workspace
Purpose, minimization, consent, isolation, retention, export, and erasure.
Product and legalBlueprint · careervector.blueprint-graph/v5
Graph explorer
Twenty composable top-level diagrams plus recursively nested 21×21 semantic layers. Nodes descend; boundary arrows cross to neighbours.
Cell 4.4 · operations · governance · privacy · evidence
CareerVector-facing operating stack
Privacy, AI governance, accessibility, and zero-user-cost commitments become explicit product gates and evidence.
- Private workspace to AI governance: constrains
- Accessibility to Zero user cost: guarantees viable path
AI governance
Purpose, provider, risk, explanation, override, BYOK, Local AI, and outcome evidence.
Product and AI ownerAccessibility
Core work cannot require a particular ability, device, GPU, or provider.
Product ownerZero user cost
No paywall, surprise charge, inference margin, or inaccessible fallback.
Product owner01 · obligation · open Private workspace Purpose, minimization, consent, isolation, retention, export, and erasure.
Product and legal02 · obligation · open AI governance Purpose, provider, risk, explanation, override, BYOK, Local AI, and outcome evidence.
Product and AI owner03 · obligation · open Accessibility Core work cannot require a particular ability, device, GPU, or provider.
Product owner04 · obligation · target Zero user cost No paywall, surprise charge, inference margin, or inaccessible fallback.
Product owner
Flows
- Private workspace → AI governance constrains
- Accessibility → Zero user cost guarantees viable path
Canonical architecture note
Open note ↗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.