OKR

Strategy operating-systems fail at three points: (1) the cascade is built once and goes stale; (2) progress is self-reported and therefore self-inflated; (3) the retrospective is performative because the team is graded on whether they hit, not on what they learned. OKR addresses all three. The cascade is a graph stored in the database; it is read every check-in and rebuilt every cycle. Progress is computed, not typed — every KR declares a progress source (a query against another module) and the value moves on its own. Retrospectives are framed in face-saving Vietnamese language and stored as BRAIN memories, so the lesson outlives the quarter that produced it. The Founder gets a Monday-morning CUO digest of confidence-band drops; if four KRs in a row drop two points this week, that is a signal that surfaces automatically.

The bet is that an OKR system that cannot be gamed (because progress is computed) and that actively learns from each quarter (because retros are persisted, citable memories) compounds over years. A 12-quarter-old company has 12 BRAIN-archived retros; planning quarter 13 starts by reading them. That is a fundamentally different artefact than 12 forgotten Notion pages.

Structured decomposition of OKR's scope. Cells trace to PRD §9.19 + SRS §7.15.

OKR is a Rust service with a TS cascade-tree SPA. It owns the OKR graph + check-in history; reads auto-progress from five upstream modules through GraphQL federation; writes summaries to BRAIN; emits Notify cards to CUO. The progress-source DSL is parsed at KR creation time and stored as an AST; refresh is a scheduled job that walks each KR's AST and executes the query against the appropriate module's federated subgraph.

Internal components

The OKR graph is six tables: Cycle (calendar), Objective (qualitative goal), KeyResult (quantitative outcome), Alignment (cascade edges), CheckIn (weekly confidence), ProgressSource (DSL-typed auto-pull config). Retrospective is a BRAIN memory, not a Postgres row.

Progress-source DSL grammar (planned)

progress_expr  = source_call , { '.' , method_call } ;
source_call    = source_name , '(' , [ args ] , ')' ;
source_name    = 'proj' | 'time' | 'inv' | 'hr' | 'learn' ;
method_call    = method_name , '(' , [ args ] , ')' ;
method_name    = 'filter' | 'group_by' | 'count' | 'sum' | 'avg' | 'max' | 'min' ;
args           = arg , { ',' , arg } ;
arg            = literal | identifier | range ;

// Examples:
//   inv.invoices.filter(state="paid", paid_at >= cycle_start).sum(amount_usd)
//   proj.issues.filter(project_id="proj-atlas", state="done").count()
//   hr.members.filter(hired_at >= cycle_start, role_tier="T3").count()
//   learn.mastery.filter(skill="rust", level >= 3).count_distinct(member_id)
//   time.entries.filter(billable=true, period=cycle).sum(hours)

Federated GraphQL subgraph for cascade reads and check-in writes, plus an MCP tool catalogue for natural-language OKR authorship through Genie.

GraphQL subgraph (federated)

extend schema
  @link(url: "https://specs.apollo.dev/federation/v2.5", import: ["@key", "@external", "@shareable", "@requiresScopes"])

type Cycle @key(fields: "id") {
  id: ID!
  code: String!
  startsOn: Date!
  endsOn: Date!
  phase: CyclePhase!
  scope: ScopeLevel!
  objectives: [Objective!]!
}

type Objective @key(fields: "id") {
  id: ID!
  cycle: Cycle!
  owner: Subject!
  scopeLevel: ScopeLevel!
  titleEn: String!
  titleVi: String!
  narrative: String
  keyResults: [KeyResult!]!
  alignmentsUp: [Alignment!]!
  alignmentsDown: [Alignment!]!
}

type KeyResult @key(fields: "id") {
  id: ID!
  objective: Objective!
  titleEn: String!
  titleVi: String!
  krType: KrType!
  baselineValue: Float!
  targetValue: Float!
  currentValue: Float!
  unit: String!
  dueDate: Date!
  state: KrState!
  progressSource: ProgressSource
  checkIns(last: Int): [CheckIn!]!
  confidenceTrend: [ConfidencePoint!]!
}

type ProgressSource {
  sourceModule: String!
  dslExpr: String!
  refreshCadence: RefreshCadence!
  lastRefreshedAt: DateTime
}

type Alignment @key(fields: "id") {
  id: ID!
  parent: Objective!
  child: Objective!
  kind: AlignmentKind!
}

type CheckIn @key(fields: "id") {
  id: ID!
  keyResult: KeyResult!
  subject: Subject!
  isoWeek: Date!
  confidence: Int!
  rationale: String!
  valueAtCheckin: Float!
  ts: DateTime!
}

type ConfidencePoint {
  isoWeek: Date!
  confidence: Int!
}

enum CyclePhase { PLANNING EXECUTION CHECK_INS RETRO CLOSED }
enum ScopeLevel { COMPANY TEAM MEMBER }
enum KrType { HIT_TARGET IMPROVEMENT MILESTONE }
enum KrState { ACTIVE SUPERSEDED ACHIEVED LEARNING }
enum AlignmentKind { CONTRIBUTES_TO SUPPORTS DEPENDS_ON }
enum RefreshCadence { HOURLY DAILY MANUAL }

type Query {
  cycle(code: String!): Cycle
  myObjectives(cycleCode: String!): [Objective!]!
    @requiresScopes(scopes: [["okr.read"]])
  cascade(cycleCode: String!, rootObjectiveId: ID): [Objective!]!
    @requiresScopes(scopes: [["okr.read"]])
  orphans(cycleCode: String!): [Objective!]!
    @requiresScopes(scopes: [["okr.read"]])
}

type Mutation {
  createObjective(input: ObjectiveInput!): Objective!
    @requiresScopes(scopes: [["okr.write"]])
  upsertKeyResult(input: KeyResultInput!): KeyResult!
    @requiresScopes(scopes: [["okr.write"]])
  alignObjectives(parentId: ID!, childId: ID!, kind: AlignmentKind!): Alignment!
    @requiresScopes(scopes: [["okr.write"]])
  submitCheckIn(input: CheckInInput!): CheckIn!
    @requiresScopes(scopes: [["okr.checkin"]])
  closeRetrospective(cycleCode: String!, brainPath: String!): Cycle!
    @requiresScopes(scopes: [["okr.close_cycle"]])
}

REST + scheduled endpoints

MCP tool catalogue

Flow 1 — Quarterly cycle (define → execute → review)

Flow 2 — Weekly confidence check-in

Flow 3 — Cascade alignment (Company → Team → Member)

Flow 4 — Auto-progress sync (PROJ / TIME / INV / HR / LEARN)

Flow 5 — Monday CUO digest to Founder

A Cycle traverses five phases. Each transition is gated; modifying KRs in execution phase requires supersession.

Per-phase rules

OKR NFRs cover cascade-tree UX latency, auto-progress reliability, and append-only data-integrity.

OKR depends on AUTH for RBAC, BRAIN for retros + audit, AI for phrasing + summarisation, and federated subgraphs from five progress-source modules. It is consumed by REW (performance pool reads team-objective achievement), HR (promotion review reads Member OKR history), and the CUO daily flow.

OKR touches employment-context data (performance, promotion inputs). EU AI Act Art. 14 and GDPR Art. 22 apply because OKRs feed REW (compensation) and HR (promotion).

OKR-specific risks in the risk register.

OKR health rolls up into 9 KPIs covering cascade coverage, check-in participation, end-cycle scoring, and digest engagement.

OKR is owned by CEO (strategy) with CSO seat for cycle operations and CLO for AI-Act compliance.

Admin CLI cyberos-okr. Every destructive action writes a chained BRAIN audit row before exit.

1. Open a new quarterly cycle

$ cyberos-okr cycle open --code 2026-Q3 --starts 2026-07-01 --ends 2026-09-30

[cycle opened]
  code:    2026-Q3
  phase:   planning
  ends:    2026-09-30
  audit:   brain seq=11204 chain=…

2. Create an Objective with progress source

$ cyberos-okr objective create \
    --cycle 2026-Q3 \
    --scope company \
    --title-en "Land $1.2M ARR Q3" \
    --title-vi "Đạt 1.2M USD ARR Q3"

[objective created]   id=O-009211

$ cyberos-okr kr add \
    --objective O-009211 \
    --title-en "Closed-won invoices >= $1.2M" \
    --type hit_target \
    --target 1200000 --unit USD --due 2026-09-30 \
    --source 'inv.invoices.filter(state="paid", paid_at >= cycle_start).sum(amount_usd)'

[kr created]   id=KR-018432  baseline=0 target=$1,200,000
[progress]     auto-pull configured · cadence=hourly

3. Submit weekly check-in

$ cyberos-okr checkin submit \
    --kr KR-018432 --confidence 7 \
    --rationale "MRR run-rate $89k; need 3 deals to close in Aug"

[check-in submitted]  iso_week=2026-W30 confidence=7 (trend ↓1 from W29)
[audit]               brain seq=11283 chain=…

4. View cascade

$ cyberos-okr cascade --cycle 2026-Q3

[COMPANY]
  O-009211  Land $1.2M ARR Q3                            score 0.74
  ├─ KR-018432  Closed-won invoices >= $1.2M  cur=$890k  conf=7
  ├─ KR-018433  Logo count: 22 → 32           cur=24      conf=8
  └─ KR-018434  Pipeline >= $4.8M             cur=$5.1M   conf=9

  [TEAM · Sales]
    O-009220  Source 60 SQLs                            score 0.62
    ├─ KR-018440  SQLs: 60                  cur=37       conf=5
    └─ KR-018441  Outbound emails / wk: 600 cur=420      conf=6
      [MEMBER · Linh]
        O-009245  Convert 10 SQLs to closed-won         score —
        ├─ KR-018470  Closed-won: 10        cur=4         conf=7

[orphans]  0
[avg confidence]  7.1

5. Run Monday digest

$ cyberos-okr digest --cycle 2026-Q3

[Founder digest · 2026-W30]
  3 KRs dropped 2+ confidence points this week:
    · KR-018432 Closed-won ARR — conf 9→7 — "August deals stalled"
    · KR-018440 SQLs — conf 7→5  — "Outbound capacity short"
    · KR-018470 Linh closed-won — conf 8→7 — "lost 2 deals in proposal"

  Suggested founder questions:
    1. "What would help unblock the 3 stalled August deals?"
    2. "Should we move someone temporarily to outbound?"

  [audit]  brain seq=11401 chain=…

6. Close cycle with retrospective

$ cyberos-okr cycle close --code 2026-Q3 --retro-from retro-draft.md

[retro accepted]
  cycle:         2026-Q3
  brain path:    memories/module/okr/cycle-2026-Q3/retro.md
  final scores:  achieved=14  learning=8  superseded=2
  duration:      90d
  audit:         brain seq=11502 chain=…

7. DSAR export for a Member

$ cyberos-okr dsar-export --subject linh@cyberskill.com --output dsar.zip

[dsar] objectives:  12 rows (4 cycles)
[dsar] key_results: 38 rows
[dsar] check_ins:   148 rows
[dsar] retros:      4 brain memories
[dsar] written:     dsar.zip (88 KB)