Octo for architecture and planning · architect arm

First the plan. Then the code.

Architecture became its own knowledge area in SWEBOK v4. In Octo, the architect arm plans before any line of code: it locates the affected area, measures impact and risk, raises the questions, identifies the threats and proposes a plan with branch, files, migration, rollback, tests and an estimate with slack. The architecture decision and plan approval belong to the tech lead.

Request an assessment See what it does

ArmArchitectworks at this step

Threat modeling4 questionsOWASP

Sources5listed at the end of the page

What Octo does in planning.

Four possible deliverables. The plan only stands once the tech lead approves it.

Task plan

Branch, files that change, migration with rollback, tests that prove the delivery and the execution order, for the tech lead to read before any edit.

Deliverable: plan for approval

Threats through the four questions

What are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job: the OWASP questions, answered in the design.

Deliverable: list of threats with the proposed response

Impact and estimate

What else the request touches in the system, the risk at each point and an estimate with slack, later measured against the time spent.

Deliverable: impact, risk and estimate

Reuse before writing

Points out the existing, well-secured component that already handles the function, instead of duplicating it, for the team to choose.

Deliverable: options with what each one implies

Eight arms, one plan.

The same Octo cycle, applied to this step. Each arm has a narrow role; your company's tech lead is in charge and approves.

Discovery
Locates the area

Where the request touches the system and what depends on it.
Data
Measures the database

Tables, relationships and volume the change reaches, before proposing a migration.
Security
Identifies the threats

What can go wrong in the design, through the four questions.
Architecture
Proposes the plan

Branch, files, migration, rollback, tests and an estimate with slack.
Development
Waits for approval

The development arm only starts after the plan is approved.
Review
Prepares the check

The plan already says how the reviewer will prove each requirement.
Release
Plans the release

Migration order and rollback path are part of the plan.
Documentation
Records the decision

The architecture decision goes into the project's decisions, with its date.

Octo proposes; the tech lead decides the architecture, approves the plan and accepts the risk of relaxing a security requirement.

Who does what in planning.

What the architect delivers and what remains your team's decision.

Step	Octo arm	Stays with the tech lead
Design and plan	Architect	Architecture decision and plan approval
Threat modeling	Architect and security	Risk acceptance when a requirement is relaxed
Third-party component	Architect	Choice of component
Estimate	Architect	Deadline agreed with the requester

From request to routine.

Three steps. Each one only makes sense once the previous one has shown results on your team.

A proposal, not a promise

1 Today

Plan before code

Every task now has a written plan that the tech lead approves.

Branch, files and tests
Migration with rollback
Estimate with slack

Benefit: surprises show up on paper, not in production

2 Next

Threats in the design

Threat modeling is part of every plan that touches access or data.

Four questions answered
Risk accepted in writing

Benefit: security starts at the design stage

3 Later

Calibrated estimates

The estimate is measured against actual time on every delivery.

Estimate history
Slack adjusted with the tech lead

Benefit: the second estimate is better than the first

Confirmed by source.

Each point below has a source published by the organization responsible for the standard, the specification or the tool, or in Brazilian federal law. The sources are in the next section.

points with a published source, each with its reference alongside.

ConfirmedArchitecture in SWEBOK: SWEBOK v4 added three knowledge areas: software architecture, software engineering operations and software security.Source: IEEE Computer Society, SWEBOK
ConfirmedThe four questions: OWASP threat modeling is organized around four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job.Source: OWASP, Threat Modeling Cheat Sheet
ConfirmedEarly, in the design: Threat modeling is ideally done early in the lifecycle, for example in the design phase.Source: OWASP, Threat Modeling Cheat Sheet
ConfirmedRisk modeling: NIST SSDF task PW.1.1 calls for forms of risk modeling, such as threat modeling, attack modeling or attack surface mapping, to assess the software's security risk.Source: NIST, SP 800-218 (SSDF 1.1), PW.1.1
ConfirmedJustify the relaxation: Practice PW.1 calls for justifying cases where the risk analysis indicates that security requirements should be relaxed or waived.Source: NIST, SP 800-218 (SSDF 1.1), PW.1
ConfirmedInsecure Design: The 2025 OWASP Top 10 keeps insecure design as a category: A06:2025, Insecure Design.Source: OWASP, Top 10 2025
ConfirmedPlan mode: In Claude Code's plan mode, the tool reads files, runs commands to explore and writes a plan, but does not edit the code. The documentation itself notes an exception in sessions that allow bypassing permissions.Source: Claude Code, permission modes
ConfirmedReuse: SSDF practice PW.4 calls for reusing existing, well-secured software when possible instead of duplicating functionality.Source: NIST, SP 800-218 (SSDF 1.1), PW.4

What Octo does and what stays with you.

Octo prepares everything, but does not sign. The document of record stays with whoever is accountable for it.

Octo prepares

Maps, plans, codes on the task branch, reviews with evidence and prepares the release: plans, code, reviews, security reports and the system dossier.

Deliverable: material ready for review

Your team reviews

Whoever is in charge is the company's tech lead or senior developer: they approve the plan, review the PR and merge it. Nothing goes to production without their approval.

Step: approval by whoever is in charge

Who signs and is accountable

Octo does not sign and is not accountable for the system. The tech lead accepts the risk and is accountable for the system in production; a security report or opinion is signed by a professional at the company.

Accountable: the company's tech lead

Sources.

SWEBOK from the IEEE Computer Society, OWASP, NIST and the Claude Code documentation. Accessed October 31, 2026.

IEEE Computer Society: SWEBOK v4.0aThe 18 knowledge areas of software engineering
OWASP: Threat Modeling Cheat SheetThe four questions and when to model
NIST: SP 800-218, SSDF 1.1 (February 2022)PW.1, PW.1.1 and PW.4
OWASP: Top 10, 2025 editionThe ten web application risks
Claude Code: permission modesPlan mode and its exception

Every task with an approved plan.

The assessment starts with your team's next request, without changing anything. You get the proposed plan and decide with it in hand.

Request an assessment