documentation/docs/strategy/target-operating-model.mdx

---
id: target-operating-model
title: First six months as AI Architect
sidebar_label: Six-month strategy
description: Improve real engineering output through a solo, CTO-sponsored, team-partnered six-month learning plan.
hide_table_of_contents: true
---

import ArchifyDiagram from '@site/src/components/ArchifyDiagram';

<div className="strategy-content">

**Proposed strategy · No company results or organizational commitments are claimed.**

## Improve the work, not the AI usage

<ArchifyDiagram name="strategy-six-months" title="Proposed six months: discover with teams, test one bottleneck, retain only supported value" story />

The assignment describes close to **80 engineers, growing to around 100 by year end, across more than 10 teams**. Every developer already uses AI, unevenly. I start **solo, reporting to the CTO, with no formal authority over teams**. The comparison is current AI-assisted practice—not an imagined no-AI organization. These facts come from *AI Architect Test Task*, Context and question 1; everything below is a proposal.

My first investment is time alongside developers and reviewers: find where useful changes stall, then remove one evidenced constraint. Delivery is a starting hypothesis because a bounded change, tests and independent review can expose both benefit and transferred work. Discovery may show that flaky CI, unclear requirements or review capacity matters more than agent instructions. Fix that bottleneck instead.

The [month-by-month plan](./roadmap.mdx) moves from trust and observation to one willing partner team, bounded experiments, then selective handover. I offer pairing and show verified examples rather than mandate tools. The CTO sponsors access and resolves priority conflicts; team leads agree contributions. Neither sponsorship nor this document conscripts a team.

## Choose the smallest intervention that fits

Missing repository knowledge suggests better context; inconsistent checking suggests coaching or a review checklist; repeatable mechanical work suggests deterministic automation; unreliable tests suggest test/CI repair. A **skill** packages reusable instructions, prerequisites and verification steps when repeated agent-guided work genuinely needs them. It is one option, not permission and not proof of correctness. Compare alternatives against the same bottleneck before funding a catalog or control platform.

Use the [worked experiment](./stage-01-skills-adoption.mdx) to connect a hypothesis, small initial measures, safety checks and a retain/change/stop decision. Existing review, data restrictions and release authority stay in place. The [16 metric contracts](./measurement/index.mdx) and skills references are optional depth, not startup bureaucracy.

## A credible month-six result

**Activities I commit to propose and drive:** a validated workflow map, agreed comparison design, hands-on experiment support, monthly CTO evidence reviews and an explicit handover or stop recommendation. Delivery depends on agreed access and partner capacity; blocked work is reported, not disguised as progress.

**Contingent visible outcome:** one workflow retained by one partner team, with a second willing team trying a bounded transfer only if value and support hold. Developers can reproduce the example; reviewers see better evidence without extra hidden burden; a voluntary champion and backup can maintain it. Evidence must include comparable task records, independent acceptance, matured defect follow-up, review/rework effort, setup and upkeep costs, and a decision signed by the actual owner. These are required evidence types, not results already obtained or promised percentage gains. If the pilot fails, month six should instead show what was stopped, why, and which cheaper intervention replaced it. Neither scenario means rollout to all 80–100 engineers.

## Present the four answers in 50 minutes

Proposed live narrative: **0–5 minutes:** context, assumptions and output goal; **5–17:** what I do month by month and how I influence without authority; **17–27:** the experiment, balanced measures and misleading signals; **27–32:** realistic month-six outcomes and evidence; **32–35:** evidence-led next investment; **35–50:** Q&A. This is **35 minutes content + 15 minutes Q&A**, not an assignment-imposed split. Content matters more than visual polish. Walk the main story, then open references only for questions.

Beyond six months, choose deeper improvement, careful replication, additional enablement capacity or stopping an ineffective approach. The [future options](./stage-02-autonomous-agent.mdx) include bounded autonomy only where a new business case and readiness justify it; autonomous SDLC is not the destination promised by this plan.

<details>
<summary>Assumptions register — validate before depending on them</summary>

| Status / assumption | Validate when and with whom | If false |
| --- | --- | --- |
| PDF fact: scale, growth, uneven existing AI use; solo CTO-reporting role without team authority | Restate with CTO in month 1; do not substitute the portal organization model for company evidence | Replan capacity and influence approach if the brief changes |
| Unknown: repositories, languages, tools, providers and data restrictions | Month 1, developers plus actual security/platform contacts | Use approved sanitized material; do not choose a client or send restricted code before clearance |
| Hypothesis: regression-evidence rework is an important Delivery bottleneck | Month 1, trace recent changes with developers and reviewers | Choose the observed bottleneck; do not force a skills pilot |
| Unknown: at least one team can volunteer review and pairing time | Month 1–2, team lead and CTO | Reduce scope to discovery/demonstration; ask CTO to resolve priorities, not impose uptake |
| Unknown: tasks, PRs, CI and defects can be linked lawfully | Month 1–2, evidence owner and privacy/security contact | Use a minimal approved worksheet; label missing outcomes and limit claims |
| Unknown: enough comparable tasks mature in the pilot window | Month 2, prospective baseline | Narrow the question or run feasibility-only work; no unsupported benefit claim |
| Unknown: a champion can own upkeep without the architect | Month 5, willing team and lead | Retain only within funded support capacity or retire; do not expand |

The portal's departmental model is not confirmation of Eldorado's actual reporting lines. Reference-role names below are candidate functions to map to real people, not appointed authorities.

</details>

<details>
<summary>Conditional long-term Target operating model — not the six-month promise</summary>

<ArchifyDiagram name="strategy-target" title="Conditional proposed target: autonomous SDLC under human direction" story />

Only if separately justified, an autonomous agent could execute and coordinate the SDLC under human direction, guidance and review, with separate human-controlled AI Agent contributions. **Solid arrows:** lifecycle · **Dotted spokes:** execution and governance · **Dashed arrows:** contributions. Scope → Architecture → UI/UX → Planning → Delivery → UAT → Security → Releases → Scope. This topology is retained as an option, not an inevitable next stage.

</details>

<details>
<summary>Supporting implementation options: trust boundaries and recovery</summary>

## Controls that support autonomous execution

The earlier control design below is a conditional implementation option, not the six-month strategy, an agreed assignment of approval roles or a claim of installed controls. Detailed approval policy and responsibilities remain to be defined with humans.

1. Humans direct, guide and review; the autonomous agent executes and governs work across the lifecycle.
2. The reviewed registry supplies pinned skills and qualified adapters to coordinator and local clients.
3. Laptop contributors can participate alongside the agent; independent repository and CI checks verify the exact revision.
4. A separate release service and artifact-scoped approval are possible controls, subject to the policy humans define.
5. Restricted audit and measurement evidence supports human review and the next Scope iteration.

<ArchifyDiagram name="ai-adoption-target" title="Supporting control option, not agreed approval policy: isolated release authority" />

**TO-BE · Target operating model.** The [Roadmap](./roadmap.mdx) separates skills adoption from the future authority decision; these pages do not describe installed controls or measured company results.

### One coordination function, distributed contributions

The autonomous agent is more than a task router: it executes and governs the repeating SDLC under human direction, guidance and review. A coordinating function maintains work records, dependencies, evidence requests, bounded retries and escalation. Data & AI and the existing AI Architect function are possible implementation contributors, not newly assigned approval authorities. Autonomous execution does not remove human involvement or allow the agent to redefine its own controls.

One logical coordinator does not mean one fragile process. A durable task ledger, explicit state transitions, leases and idempotency keys allow recovery or multiple replicas without duplicate delivery. Inference outages stop new agent decisions, not the organization's ability to take over. People can resume work through the normal deterministic workflow. Evidence and authorization services fail closed for privileged actions; missing evidence never becomes permission.

These controls support the sequence Scope → Architecture → UI/UX → Planning → Delivery → UAT → Security → Releases → Scope; they do not replace it with a separate lifecycle. Product, engineering, design, quality, security and platform expertise inform human direction and review. Specific approval assignments and release permissions are implementation decisions still to be defined.

### Trust and authority boundaries

People authenticate to the work system; the coordinator receives only the project context it needs. Untrusted issue text, repository content, web pages and tool output are task data, never an authorization source. Local clients operate under device controls and project-scoped access. Hard containment requires OS/container isolation, filesystem and network restrictions and separate short-lived identities; a skill folder, prompt or working directory is not a sandbox.

The registry distributes reviewed immutable content and adapters, not ambient credentials. Executable scripts, plugins, MCP servers and dependencies are separately reviewed and pinned. Model-provider routing is allowlisted for the data classification, with approved retention and training-use terms before sensitive data crosses that boundary. Fallback to another provider must not silently change the data policy.

Central controls verify protected-branch review, actual artifact identity, exact commit and policy revision, required checks and a scoped human approval. Candidate changes cannot edit their own authoritative gate or reuse approval for a different artifact. Deployment credentials belong to the release service, not the local agent. Approval expires or is invalidated by changed content. Emergency stop revokes mutation credentials and stops scheduling independently of the model, preserves evidence and enables human takeover.

</details>

<details>
<summary>Candidate contributions and first workflows for all eleven teams</summary>

### Department contributions

The existing team structure provides a starting point. The contributions below are implementation proposals, not settled approval roles or lifecycle gates.

### Product / Product Management

**Contribution and retained human decision** — Own pilot priorities, acceptance criteria and outcome hypotheses; decide product value.

**First bounded workflow and evidence** — Draft acceptance criteria from sanitized discovery notes; independent completeness review and accepted-task success.

### Product / Product Design

**Contribution and retained human decision** — Own design quality, accessibility and research handling.

**First bounded workflow and evidence** — Review a proposed flow against an accessibility checklist; verify findings against the interface.

### Technology / Product Engineering

**Contribution and retained human decision** — Own skill authoring, code review and maintainability; remain accountable for generated code.

**First bounded workflow and evidence** — Test scaffolding and change summaries in a disposable branch; independent tests and escaped-quality follow-up.

### Technology / Platform & IT

**Contribution and retained human decision** — Own supported client inventory, distribution, identity, isolation, CI/release integration, transport and emergency revocation.

**First bounded workflow and evidence** — Qualify a pinned bundle and exercise rollback; inventory and exact-revision gate evidence.

### Technology / Architecture & Security

**Contribution and retained human decision** — Own risk classification, data boundaries, security review and bounded exceptions.

**First bounded workflow and evidence** — Review injected-input and unauthorized-tool cases; independent control evidence and policy-effect counts.

### Technology / Quality Engineering

**Contribution and retained human decision** — Own regression/adversarial suites, rubric calibration and acceptance evidence.

**First bounded workflow and evidence** — Evaluate candidate versus approved skills on repeated representative tasks; retain all failures.

### Technology / Data & AI

**Contribution and retained human decision** — Own catalog coordination, coordinator evaluation and measurement design, through existing AI enablement responsibilities.

**First bounded workflow and evidence** — Curate a small skill set and analyze a prospective pilot; no new AI department.

### Operations / Operations Squad

**Contribution and retained human decision** — Own service acceptance, disputes, fraud, refunds and customer communications.

**First bounded workflow and evidence** — Draft an answer from sanitized resolved cases; Operational Quality workstream checks correctness before any send. No automated dispute/refund decision.

### Marketing / Marketing Squad

**Contribution and retained human decision** — Own brand, factual claims, content rights, publication and spend approvals.

**First bounded workflow and evidence** — Draft a campaign brief against approved brand material; human claim/rights review before publication.

### Finance & Accounting / Finance & Accounting Squad

**Contribution and retained human decision** — Own allocation of total costs, financial evidence and segregation of approvals.

**First bounded workflow and evidence** — Explain a sanitized reconciliation exception; no posting, payout or payment authority.

### HR & Administration / People & Administration Squad

**Contribution and retained human decision** — Own coaching, acceptable use, feedback privacy and people decisions; partner with Platform & IT on access lifecycle.

**First bounded workflow and evidence** — Draft onboarding guidance from approved policy; human accuracy review. No hiring or performance decision automation.

Product keeps two teams; Technology keeps five; the other four departments keep one squad each. Coordination, skill ownership, approval and cover are assignments inside these teams, not new standing departments, roles or headcount. Department leaders retain accountability and designate real approvers before a pilot starts.

See the existing [organization structure](/organization/structure/), [department collaboration](/organization/collaboration/) and [SDLC responsibilities](/organization/sdlc/).

</details>

<details>
<summary>Strategy rationale and reading map</summary>

### References support the chosen intervention

The first investment is learning where current AI-assisted work can improve. Use skills governance only if a skills intervention is selected; it is not a prerequisite for discovery, coaching or fixing deterministic tooling.

The conditional target combines an autonomous agent with human direction and review. Actual client support requires qualification; names such as Copilot, Claude Code and Cline are examples, not known company tools. Repository, CI and release controls remain authoritative.

This strategy does not establish that controls are installed or that AI has improved Eldorado's performance. Validate actual clients, responsibilities, data boundaries and available evidence; the documented six-department model is not source evidence for this assignment.

Success means accepted outcomes with maintained quality, controlled risk and understood total cost. Faster activity without reliable outcomes is not success. More skill invocations, generated lines or tool subscriptions are not productivity targets. People remain accountable for product, customer, financial and personnel decisions.

### Navigate the strategy

- [Roadmap](./roadmap.mdx) — Proposed six-month priorities, capacity, dependencies and decisions.
- [Stage 01](./stage-01-skills-adoption.mdx) — Follow one workflow through evidence, decisions and feedback.
- [Baseline](./baseline.mdx) — Understand current work and record the starting position before changing it.
- [Skills governance](./skills-governance.mdx) — Contract, lifecycle, decision rights, adapters, locking, exceptions.
- [Skills quality](./skills-quality.mdx) — Risk tiers, independent evaluation, repeated trials, adversarial conformance.
- [Skills adoption](./skills-adoption.mdx) — Workflow-led coaching, client choice, feedback, manual path.
- [Measurement](./measurement/index.mdx) — Full KPI contracts, minimal events, illustrative calculations, privacy and limits.
- [Skills maintenance](./skills-maintenance.mdx) — Review, drift, deprecation, rollback and incident handling.
- [Stage 02](./stage-02-autonomous-agent.mdx) — Decide whether bounded autonomous authority is justified and recoverable.

</details>

**Next:** [Follow the six-month plan →](./roadmap.mdx)

</div>