← Commissionable work

The situation we can help hold and understand

“We know what is not working, but every fix to one part seems to damage another.”

This is a place to begin, not a conclusion made for you. We do not decide where the problem sits until the evidence supports it.

The work you are commissioning

System Architecture

The concrete design of the justified system change: decision rights, roles, workflow, ownership, escalation, and—when commissioned to implementation-ready depth—requirements and acceptance criteria.

Participants
Decision owner, internal sponsor, and relevant system owners
Duration
4–8 weeks
Price
USD 10,000–25,000
Stopping point
Stop at the commissioned point: when leaders can decide whether to proceed, or when accountable implementers can carry the design forward with clear requirements, boundaries, and acceptance criteria.

This work is useful when

  • A credible diagnosis or equivalent internal evidence already exists
  • The change crosses roles, workflow, authority, information, or technology
  • Leaders need a decision-ready design, or accountable builders need an implementation-ready design

This should not become a shortcut when

  • A problem that is still disputed or weakly evidenced
  • Generic best practices or SOP writing
  • A request for SE Ocean to become the delivery owner

What you will hold when the work ends

One coherent delivery package composed for the real problem.

You leave with enough design to approve, defer, or reject the change—or, when implementation readiness is commissioned, a package internal teams and specialists can carry forward without inventing its logic as they go.

Primary delivery

System design and decision package

The package contains only the design components required by the agreed stopping point. It is not a fixed catalogue of diagrams or templates.

What it is
One coherent design package composed for the decision the client needs to make. It can stop at a decision-ready design or extend to implementation-ready requirements, owners, sequence, and acceptance criteria.
How to use it
Use it to approve, defer, or reject the change; or, when implementation readiness is commissioned, to brief internal teams and specialists and inspect what they deliver.
What it changes
It keeps the decision logic, operating design, and implementation conditions connected, while leaving the client free to stop before implementation.

We do not make the executive decision for you. We do complete the work to the agreed decision point, so you can see the options, consequences, risks, and remaining unknowns before choosing. Preserving client authority is not an excuse for incomplete delivery.

Components selected when needed

Nothing is included merely to make the report look complete.

We include only what explains the problem, supports the decision, or lets the team carry the agreed scope forward.

As required

Target system design

What this component does
A connected design of decision rights, roles, workflow, handoffs, escalation, information ownership, and human–AI boundaries where relevant.
How to use it
Use it as the shared reference for leaders, internal owners, and specialists before anyone changes process, tools, or structure.
What it changes
It shows how the parts must work together, so one local fix does not damage another part of the system.
As required

Implementation requirements and sequence

What this component does
A practical sequence of changes, dependencies, ownership, constraints, and decisions that must be resolved before each stage begins.
How to use it
Use it to plan internal work, request proposals, compare specialist approaches, and prevent premature build decisions.
What it changes
It translates strategy into work that can be assigned, sequenced, and governed.
As required

Acceptance criteria and specialist brief

What this component does
A brief stating what must be preserved, what successful delivery looks like, what evidence is required, and who accepts the work.
How to use it
Attach it to internal work orders or specialist scopes and use it at review and acceptance points.
What it changes
It reduces the risk that technically complete delivery solves a different problem from the one the organization intended to address.

Choose the stopping point before work begins

Stop with a decision-ready design, or extend it until another team can carry it forward.

01

Decision-ready design

For leaders who need to compare the proposed change, consequences, dependencies, and conditions before committing to implementation.

Price Priced as a distinct stopping point in the proposal, within the published architecture range.

  • Target design and decision logic
  • Consequences, dependencies, and unresolved choices
  • Conditions that must be true before implementation
02

Implementation-ready design

For an approved change that internal teams or specialists must be able to sequence, own, build, and accept without recreating the design logic.

Price Priced separately for the deeper implementation-ready scope in the proposal, within the published architecture range.

  • Implementation sequence and dependencies
  • Named responsibility and required team understanding
  • Acceptance criteria, review points, and escalation conditions
Included in architecture

The accountable owner receives the design logic, boundaries, decision conditions, and acceptance criteria needed to understand what must be preserved.

Separate capability work when required

If the delivery team cannot yet apply, review, or escalate the design safely, practical training and capability building with that team is scoped and priced as separate work.

01

Information and access required

  • Credible problem definition
  • Decision owner and internal sponsor
  • Implementation constraints
  • Systems, roles, and information affected
02

What the work does not include

  • The client retains executive authority
  • Specialists retain technical responsibility
  • Design does not silently include implementation delivery

Specialist applications

AI, workflow, KPI, and governance are applications of the work—not competing service pillars.

  • Operating model and workflow architecture
  • Human-AI workflow and adoption architecture
  • AI transformation readiness and operating-system design
  • Search and discovery architecture
  • Decision rights and governance
  • Performance and KPI systems

The decision this work enables

Implement internally, commission specialists, or add stewardship where design drift would create material risk.

Later work is not automatically credited or opened. Every additional depth requires its own justification and boundary.

Share the problem for fit review →Return to what’s happening →