The Optimus Operating System — Goal-Driven Agent Teams

Date: 2026-08-05 · Status: Research complete, design proposal Companion docs: agent-architecture-research.md (runtime & control plane) · primedocs-agent-architecture.md (first team) Inputs: research into how elite startup teams operate (OKRs, Amazon WBR/Working Backwards, Lean Startup, high-tempo testing, Shape Up, EOS, The Cadence, Rumelt) + goal/experiment/learning primitives across the reference repos (mastra, yalc, eve, gtm synthesis) + evidence from AI-agents-running-businesses (Anthropic Project Vend, TheAgentCompany benchmark).

Table of contents

1. The thesis
2. How elite startup teams actually operate
3. What the reference repos validate (and what nobody has built)
4. The Optimus data model: eight objects
5. The operating cadence
6. The bootstrap: goal + URL → a working company
7. Honest measurement: keeping a self-improving system truthful
8. The interface: a startup cockpit, not an agent dashboard
9. How this layers onto the existing architecture
10. What transfers from human teams — and what deliberately doesn't
11. Build implications & sequencing
12. Source index

1. The thesis

Every agent product on the market models work (tasks, sessions, runs). Optimus models purpose — the reason work exists:

This mirrors the actual mechanism behind elite startups. The research is unambiguous: what separates the best teams is not talent but iteration velocity against an explicit goal tree with honest measurement — YC measures startups by weekly growth rate (Startup = Growth); David Sacks argues the operating cadence itself is the moat ("you will ship four great quarters per year" — The Cadence); Amazon runs the whole company as a weekly input-metrics review (WBR).

Agents change the economics of this loop in two ways:

1. Iteration is nearly free — an agent team can run the weekly startup cadence at 5–10× compression (daily experiment cycles, weekly human review).
2. Memory is perfect — a learn library that humans maintain badly is an append-only table agents maintain flawlessly. Anthropic's Project Vend found exactly this: structured business scaffolding (CRM, cost-visible inventory, enforced verification steps) was the single biggest performance unlock, taking the shop from comic failure to 208% of revenue target (Project Vend 2).

So Optimus's differentiator is not "manage agents" — it's "run the elite-startup operating system, staffed by agents, supervised by you." The interface is a founder's cockpit: goal tree, metrics deck, experiment board, decision log — with the team view and inbox we already designed underneath it.

One design tension governs everything below: the "surprise me" requirement (goal + URL in → working system out) pulls against the "manager control" requirement. The resolution: the system always plans in the open. It drafts strategy, goals, metrics, team, and first bets as reviewable artifacts; you edit and approve; it then runs autonomously within the approved frame; every structural change flows back through the same propose → review loop. The magic moment is not the system acting mysteriously — it's watching it produce a plan good enough that you barely edit it.

2. How elite startup teams actually operate

The frameworks converge far more than their branding suggests. The operationalizable mechanics:

2.1 Goals: OKR mechanics + the driver tree

• OKRs as practiced: 3–5 qualitative Objectives per level, each with 3–5 quantitative Key Results tagged committed (expect 1.0) vs aspirational (expect ~0.7); scored 0–1 at cycle end; weekly check-ins flag green/yellow/red. Failure modes to design against: business-as-usual OKRs, KRs that don't actually add up to the objective, set-and-forget (WhatMatters: grading, common mistakes).
• North Star framework: one metric expressing realized customer value, decomposed into 3–5 controllable input metrics (breadth/depth/frequency/efficiency) — a driver tree where every experiment links to the input it should move (Amplitude, playbook).
• Amazon's input/output distinction is the same idea sharpened: output metrics (revenue) can only be influenced; controllable input metrics ("add 500 products", "publish 3 guides") can be moved. Teams work on inputs, review outputs (Commoncog WBR).
• Above goals sits strategy — Rumelt's kernel: diagnosis → guiding policy → coherent actions. Goals without a diagnosis is his #1 bad-strategy anti-pattern (Good Strategy Bad Strategy notes). This matters for Optimus: "hit $10k MRR" alone is not enough for the system to plan against; it needs the diagnosis ("distribution is the bottleneck; the catalog converts fine") to generate coherent bets.

2.2 The experiment loop: hypothesis → test → learning

• Lean Startup's innovation accounting: establish a baseline → every initiative must move a driver from that baseline → periodic pivot-or-persevere decision. Unit of progress = validated learning, vanity metrics banned (leanstartup principles).
• High-tempo testing (Sean Ellis): a shared ideas backlog anyone can submit to → ICE scoring (Impact/Confidence/Ease) → weekly growth meeting picks tests → every result lands in a learn library. Test tempo is itself a tracked meta-metric (high-tempo testing, ICE).
• The canonical hypothesis card (First Round growth sprints):

  "We believe [assumption, backed by evidence]. To test this we will [action]. We predict [metric] moves by [amount]. If right we will [double down]; if wrong we will [alternative]." plus a falsifier, minimum sample / stop rule, and a link to the driver-tree node it serves.

• Experiment-platform hygiene (GrowthBook): primary metric (the decision criterion) vs secondary metrics (learning) vs guardrail metrics (protect from harm); minimum runtime + minimum sample to prevent peeking; stop early only if a guardrail goes statistically negative; every finish records a decision + observations.
• Growth loops, not funnels (Reforge): model the business as closed loops (content → traffic → buyers → reviews/data → better content) and aim experiments at the loop's rate-limiting step.

2.3 Cadence: the heartbeat

• Amazon WBR: metrics auto-generate Sunday night → owners annotate anomalies → Wednesday review that is exception-driven (seconds on green, all time on variance); charts show 6-week and 12-month trails side-by-side with target lines (Commoncog).
• EOS Level 10 meeting — the small-company version, 90 minutes, fixed agenda: scorecard (on/off-track only) → quarterly rocks (on/off-track only) → to-dos (~90% weekly completion expected) → IDS: rank issues, root-cause the top one, solve = a to-do with an owner (EOS).
• Shape Up: appetite (how much time a problem is worth — fixed time, variable scope), the betting table (unchosen pitches expire — no standing backlog rot), and the circuit breaker (work that doesn't ship in its cycle doesn't auto-renew; it must re-earn its bet) (Shape Up).
• YC discipline: one primary metric, tracked weekly, never switched when it looks bad; the growth rate is the number (PG). Lean Analytics adds: the One Metric That Matters changes by stage — draw a line in the sand, move on when the stage changes (OMTM).

2.4 Decisions & accountability

• DRI / single-threaded owner: exactly one named owner per goal, metric, project (Apple's DRI, Amazon STL).
• One-way vs two-way doors + 70% rule: reversible decisions get made fast by individuals at ~70% of desired information; irreversible ones get deliberation. Disagree-and-commit with recorded dissent (Bezos 2016 letter).
• Written narratives for big bets: Amazon PR/FAQ — write the press release before building; five gate questions; "most PR/FAQs don't get approved is a feature, not a bug" (Commoncog PR/FAQ). Pre-mortems improve risk identification ~30% for 20 minutes of work (HBR).
• Opportunity Solution Trees (Teresa Torres): outcome → evidence-backed opportunities → always ≥3 candidate solutions → assumption tests. Her #1 failure mode: inventing opportunities without evidence — a known LLM weakness, so Optimus must require evidence links on every opportunity (Product Talk).

2.5 The agent-specific evidence

• Project Vend (Claude running a real business): structured records + procedurally enforced verification transformed performance; role specialization beat a unified agent; a "CEO agent" on the same model shared the same deficiencies (hierarchy doesn't fix model weaknesses); persistent failure modes were sycophancy, discount manipulation, contract naivete → human oversight of one-way doors remains essential (Project Vend 2).
• TheAgentCompany benchmark: best agents complete only ~30% of long-horizon company tasks; they abandon tedious multi-step chains → decompose work into short, verifiable, checkpointed units (arXiv 2412.14161). This independently confirms Shape Up's circuit-breaker logic for agents.

3. What the reference repos validate (and what nobody has built)

The corpus contains every piece of the goal-driven loop, shipped and tested — but scattered across different repos, never unified.

Validated, with working reference implementations

Explicitly missing everywhere (Optimus's invention list)

1. Goal hierarchy. Mastra's objective is flat and single. No parent/child, no milestone rollup, no "sub-goal done ⇒ advance parent" — anywhere.
2. Hypothesis as a first-class entity with a lifecycle. yalc's hypothesis is a text column. proposed → evaluated → approved → running → won/lost/killed exists nowhere; the pieces (Nudge = proposal, Plan = frozen approval, Verdict = terminal state) live in three different repos.
3. Delayed-outcome attribution. The gtm synthesis lists it under "required before production" — future tense. The known open question: which outcome joins belong in operational events vs an analytics ledger.
4. Learning → versioned behavior change. Universally prescribed (invariant #10: "Learning proposes a new version; it does not silently mutate live prompts, guards, or provider order"), universally unimplemented. Nobody evaluates a proposed change against historical runs before promoting it.
5. Goal-level scoring across horizons — rolling run-level scorecards up to the goal that motivated them.

Two warnings the corpus repeats: every metric needs a named consumer at design time (yalc collected provider-quality scores nothing ever read), and never overwrite history (gtm-pipeline overwrites stage state and therefore can't attribute anything — append-only from day one).

4. The Optimus data model: eight objects

The startup frameworks and the repo primitives converge on the same canonical objects. These become new storage domains in the control plane (see architecture doc §4), and — like agents and skills — their definitions live as reviewable files in the project directory, with SQLite owning execution state.

4.1 Strategy (per project; singleton; revised rarely)

Rumelt's kernel + Working Backwards, as a living document the whole team reads:

Every goal must trace to the strategy; every hypothesis must name the action theme it serves. This is what makes the system's behavior legible — the "perfect clarity on why it's doing what it's doing" you asked for starts here, not in run logs.

4.2 Goal (tree)

OKR-shaped, hierarchy added (the thing no reference implements):

Mechanics from the references: judged like Mastra goals (an independent judge evaluates progress in-loop, with maxRuns-style budgets so pursuit can't spin forever); scored like OKRs (expect ~0.7 on aspirational; consistent 1.0 = the system is sandbagging its own targets — recalibrate).

4.3 Metric (the driver tree — the spine of the whole system)

Amazon's taxonomy + Amplitude's tree + EOS's scorecard row, one object:

PrimeDocs example tree: revenue/1k sessions (north star) ← sessions × conversion × AOV (outputs) ← products live, guides published, pins scheduled, email list size, bundle attach rate (controllable inputs, each owned by the agent who moves it). Rule: agents work on inputs; outputs are reviewed, not assigned — this single distinction prevents most goal-gaming.

4.4 Hypothesis (the idea card — the unit of team intelligence)

The First Round card + yalc's Nudge + ICE + Shape Up appetite, unified with a real lifecycle:

Lifecycle rules from the research: the backlog is ICE-ranked and expiring (Shape Up: unchosen pitches die — no backlog rot; declined ideas archive with a reason, teaching proposers); big bets require a written narrative and pre-mortem before approval — cheap for an LLM, and "most PR/FAQs die" is precisely the filter needed against agent idea-spam; two-way-door hypotheses within appetite can auto-approve at higher autonomy tiers, one-way doors always queue for you.

4.5 Experiment (execution record of an approved hypothesis)

GrowthBook-shaped, run by the existing run machinery:

Kill/promote follows yalc's discipline: significance requires p < 0.05 and minimum sample; below sample, the honest state is "keep running — need N more," never a verdict. The Analyst-role agent, not the proposer, computes results (see §7).

4.6 Learning (append-only learn library — the compounding asset)

yalc's Intelligence shape, with its known epistemic bugs fixed:

Promotion rules (fixing yalc's shortcuts, per its own postmortem): promotion requires independent evidence with adequate samples — never "2 entries ⇒ validated," and never access-frequency-as-truth. Only validated+proven learnings are injected into agent context (via the scoped memory system already designed), tagged with the standing trust boundary: facts, never instructions.

4.7 Decision (the decision log)

This is what gives you "perfect clarity why the system did what it did" months later — and it's training data for improving the team's judgment.

4.8 Owner (DRI binding)

Not a new table — a constraint: every goal, metric, hypothesis, and experiment carries exactly one owner_agent. Project Vend's evidence says specialization beats generalists; the DRI rule is how specialization stays crisp. Some ownership is reserved to you (strategy approval, one-way doors, brand) — same as PrimeDocs Tier 3.

How the objects wire together

5. The operating cadence

The heartbeat that makes the objects live. Human frameworks compress well because agent iteration is cheap — but the human ritual stays weekly (your attention is the scarce resource, and most business metrics need days of data anyway).

Daily (automated — the system's pulse)

• Metrics refresh from connectors; owners annotate variances (Amazon's "owners investigate before the review").
• Experiment monitors check stop rules and guardrails; anything tripping a guardrail pauses and files to your inbox.
• Agents work their approved experiments and standing duties (support, QA, publishing) through the normal run/trigger machinery.

Weekly (the review — your one ritual, ≤30 minutes)

This is Amazon's WBR + EOS L10 + the growth meeting fused into one generated document + one approval session — it replaces the generic "digest" from the UX design with something far stronger:

1. Scorecard pass — driver tree with on/off-track flags only; exceptions get one-line owner annotations. (Seconds on green. All attention on variance.)
2. Goal pass — each active goal: on/off-track, KR progress bars.
3. Experiment results — every finished experiment: verdict + proposed decision (double-down / iterate / kill) + the learning it minted.
4. Betting table — the top of the ICE-ranked hypothesis backlog sized against available capacity/budget; you approve/decline/edit next week's bets. Unchosen ideas age toward expiry.
5. Issues (IDS) — the top off-track items root-caused, each resolving to an owned action.
6. Decisions needed — the one-way doors, with memos.

Most of this document is pre-decided — you're reviewing exceptions and placing bets, not reading logs. Target: the whole weekly review is 15–30 minutes of your time, exactly like the PrimeDocs "Operator brief" but rigorously structured.

Cycle (6 weeks, aligned to Shape Up rather than quarters — agent-speed)

• Grade goal KRs 0–1; calibrate (consistent 1.0 = targets too soft).
• Pivot-or-persevere per goal: the innovation-accounting question — are experiments moving the drivers from baseline? If not, the strategy diagnosis is wrong, and that's a strategy-revision proposal, not another experiment.
• Circuit breaker: workstreams that didn't ship don't auto-renew; they re-earn a bet.
• Set next cycle's goals (agents draft from learnings + backlog; you approve).

The stage-awareness rule

Lean Analytics: the One Metric That Matters changes by stage. Pre-launch PrimeDocs's NSM is not revenue — it's "QA-passed products live" (supply). Post-launch it becomes revenue/1k sessions. Optimus should model stage explicitly on the project and let the system propose the NSM transition — a strategy-level, you-approve decision.

6. The bootstrap: goal + URL → a working company

The "surprise me" flow, structured as Working Backwards so it's magical and controllable. Input: a goal, plus a URL / repo / description. Output: a fully drafted operating system, presented for review before anything runs.

Phase 1 — Diagnose (system works, you wait ~minutes). Deep analysis of the asset: crawl the site, read the repo, pull whatever connectors exist (Stripe, analytics, Supabase). Competitive scan. Output: a Diagnosis memo — where the business is, what the constraint is, what the data says. (This is Rumelt's kernel step one, and it's exactly what Claude with web + MCP access is spectacular at.)

Phase 2 — Propose (the reveal moment). The system presents, as one reviewable package:

• Strategy kernel (diagnosis → guiding policy → action themes → recommended moat)
• Goal tree with KRs ("$10k MRR by Dec" decomposed into staged sub-goals)
• Metric driver tree, with which connectors it will measure each node from
• The team: agent roster with charters, mapped to metric ownership (this is where the PrimeDocs 11-agent architecture gets generated rather than hand-designed)
• The first betting table: 5–10 ICE-scored hypotheses with appetites
• The autonomy proposal: which action types start at which tier

Phase 3 — Review & edit (you, ~20 minutes). Everything editable — rename agents, delete goals, tighten budgets, veto bets. Approval freezes v1 of strategy/goals/team (immutable-once-approved; changes are new versions).

Phase 4 — Run. Team instantiates (project directory, agents, triggers, memory), first experiments launch, the weekly cadence begins.

Two rules keep the surprise honest: every claim in the diagnosis carries evidence links (Torres's rule, enforced structurally — no invented opportunities), and the system proposes less autonomy than it could (progressive delegation: tiers loosen with your approval history, per PrimeDocs §5 and the UX research on trust adoption).

7. Honest measurement: keeping a self-improving system truthful

The failure mode that kills this product is not agents doing too little — it's the system manufacturing false progress. An agent that grades its own experiments will produce a beautiful dashboard of fictional wins. Structural defenses, all validated by the research:

1. Metrics come from connectors, never from agent self-report. Revenue from Stripe MCP, traffic from analytics, catalog counts from Supabase queries. Amazon's equivalent: finance independently audits WBR metrics. An agent may annotate a metric; it may never write one.
2. Proposer ≠ judge, structurally. The agent that proposed a hypothesis never computes its result; the Analyst role owns verdicts (same separation as Maker/Auditor). Mastra's goal judge runs as its own forked context with its own tools — copy that shape.
3. Statistical gates are code, not prompts. yalc's p<0.05 && n≥30 + minSampleNeeded; below sample, the only legal verdict is inconclusive — keep running. PrimeDocs already demands this ("no directional claims below 100 conversions/arm"); it lives in the experiment engine, not in the Analyst's charter.
4. Guardrail metrics on every experiment — the agent optimizing pin volume must be stopped by the refund-rate guardrail, automatically.
5. Learnings expire and are scoped. Confidence is a lifecycle earned through independent evidence; stale truths age out (yalc's expiresAt), and a learning about wedding templates doesn't leak into the resume category (scope field).
6. Learning proposes versioned change, never silent mutation — invariant #10, the corpus's most-repeated rule. When a learning implies "change the pricing skill," that's a diff on a file in the project repo, reviewed like any PR. Version history + regression against historical runs = the path to safe self-improvement, and it's ahead of every reference repo.
7. Anti-sycophancy in the weekly review. Project Vend's core failure was the agent telling people what they wanted to hear. The agent equivalent of gaming the scorecard is flattering the founder. Defenses: the review template requires a "what's off-track / what I'd kill" section; output metrics are computed, not narrated; and the review generator's charter explicitly rewards surfacing bad news early (with your consistent behavior backing it — don't shoot messengers).

8. The interface: a startup cockpit, not an agent dashboard

This extends the decided IA (inbox-first home, professional-team metaphor, agent-centric objects — see memory/UX decisions). The goal layer adds the missing "why" above the team layer. Revised screen map:

Mission (new home for an active project) — goal progress, driver tree with sparklines and on/off-track flags (the WBR deck rendered live), running experiments with sample/duration progress, top of the betting backlog. This answers "how's the business?" in five seconds — the founder-cockpit view. The timeline lives here too: cycles, milestones, experiments, and decisions on one horizontal track (the PM-style view you described).

Experiments — the board: backlog (ICE-ranked, expiring) → running (with stop-rule progress) → verdicts → learn library. Each card is the full hypothesis card; each verdict links its learning; the learn library is browsable/searchable (your compounding asset made visible).

Inbox — unchanged grammar (notify/question/review), but the weekly review becomes its anchor artifact: one generated document, sections pre-structured (scorecard exceptions → experiment verdicts → betting table → one-way doors), each item actionable inline. Daily inbox handles the trickle; the weekly review handles the batch.

Team — as designed, with one addition per agent card: what it owns (metrics + goals), because ownership is now the organizing principle.

Why this wins: management interfaces for agents all answer "what is the system doing?" Optimus answers "is the business working, why, and what are we betting on next?" — with the agent machinery one drill-down below. That's the difference between a thousand agent dashboards and a company cockpit.

9. How this layers onto the existing architecture

No revisions to the runtime/control-plane decisions — this is a layer above it:

• New storage domains: strategy, goals, metrics (+series), hypotheses, experiments, learnings, decisions — same domain-decomposed SQLite pattern.
• Definitions as files, state in SQLite (same rule as agents/skills): strategy kernel, goal definitions, hypothesis narratives live in the project repo (reviewable, diffable, versioned — which is what makes "learning proposes versioned change" natural); series data, run links, verdicts live in the DB.
• The Optimus MCP server grows goal-layer tools: propose_hypothesis, record_evidence, get_driver_tree, get_learnings(scope), log_decision, request_metric_annotation. Agents interact with the operating system the same way they interact with memory — through control-plane tools with policy gates.
• Metric connectors are scheduled runs against MCP servers (Stripe, Supabase, analytics) writing to the append-only series — built on the existing trigger/run machinery, no new execution paths.
• The experiment engine is code, not an agent: stop rules, significance, guardrail checks run in the control plane (the "daemon owns transitions" rule from the architecture doc, applied to science).
• Autonomy tiers gain the door dimension: two-way-door actions within an approved experiment's appetite auto-execute at Tier 1+; one-way doors are Tier 2+ regardless of agent. This refines PrimeDocs §5 rather than replacing it.
• The weekly review generator is itself an agent (Operator/Analyst role) — but it can only assemble and annotate computed facts, never originate numbers.

Revised build note: the original Phase 4 ("first real team") now becomes Phase 4: goal layer MVP — goals + metrics + hypothesis backlog + weekly review — because the PrimeDocs team should be born from the bootstrap flow, not hand-assembled. A pragmatic MVP slice: one goal, a 5-node driver tree with 2 connectors (Stripe + analytics), the hypothesis board, and the generated weekly review. That alone is differentiated.

10. What transfers from human teams — and what deliberately doesn't

Transfers directly (they're basically software specs): the WBR metrics engine (input/output taxonomy, dual-window charts, exception-driven review); ICE-scored expiring backlogs; the hypothesis card with falsifier + stop rule; guardrail metrics; the learn library; DRI ownership; one-way/two-way doors + decide-at-70%; appetite + circuit breaker (the direct countermeasure to agents abandoning long-horizon work); PR/FAQ + pre-mortem for big bets; one primary metric never switched when it looks bad.

Deliberately does not transfer: motivation psychology (stretch-goal 0.7 scoring rationale, compensation decoupling — keep the scoring math only, for calibration); meeting theater (silent reading, segues, meeting ratings — keep the artifacts the rituals produce: the memo, the log, the review doc); trusting self-report as accountability (humans feel accountable; agents need independent verification — §7); emotional delegation dynamics ("give away your legos" — Optimus's version is the autonomy-tier promotion rule, which is mechanical).

Transfers with modification: continuous discovery — weekly customer-evidence collection (reviews, support tickets, refund reasons, analytics anomalies) still gates the opportunity space, but every opportunity node requires evidence links because inventing customer needs is both Torres's #1 human failure mode and a known LLM weakness. Concierge and Analyst (support + data roles) are the natural evidence collectors.

11. Build implications & sequencing

Updated phase plan (extends architecture doc §11):

• Phases 0–3 unchanged (runtime, control plane, projects/agents, safety) — the goal layer depends on runs, triggers, approvals, and memory existing.
• Phase 4 — Goal layer MVP: goal + metric domains, 2 connectors, driver tree UI, hypothesis board with ICE + lifecycle, experiment engine (stop rules + significance in code), learn library, generated weekly review. Exit test: a full loop closes — a hypothesis proposed by an agent is approved by you, runs as an experiment, produces a statistically honest verdict and a learning, and that learning appears as evidence in a new proposal.
• Phase 5 — Bootstrap flow: diagnose → propose → review → instantiate. Exit test: point Optimus at primedocs.co + "$10k MRR by Dec"; it drafts strategy, goals, driver tree, team, and first bets; you edit approve; the team starts running. (PrimeDocs becomes the first customer of the bootstrap rather than a hand-built config.)
• Phase 6 — Compounding: delayed-outcome attribution (append business outcomes to run lineage — the unbuilt frontier from the gtm synthesis), learning-proposed versioned changes to skills/policies with regression review, stage-transition proposals, cycle grading & calibration.

Open design questions to settle before Phase 4 (worth a conversation each):

1. Cycle length — 6-week Shape Up cycles, calendar months, or goal-defined milestones? (Recommendation: 6-week cycles with weekly reviews; agents get daily micro-cycles inside experiments.)
2. How prescriptive is the weekly review ritual? A generated doc you read anytime, or a scheduled "session" the app structures (L10-style, timeboxed sections)? (Recommendation: generated doc, always current, with a "review mode" that walks the sections and collects your decisions — ritual as affordance, not obligation.)
3. Can agents propose goals, or only hypotheses, at v1? (Recommendation: v1 agents propose sub-goals only under your goals; company-level goals stay yours. Loosen later like any tier.)
4. Where does the timeline visualization sit on the build priority list? It's the most PM-feeling surface but the least mechanically necessary — cockpit + board may be enough for v1.

12. Source index

Startup operating systems (primary frameworks)

AI agents running businesses

Reference repo primitives (local paths)

(All local paths relative to /Users/stansedberry/Documents/Agent Reference/agentic-gtm-reference/.)