The two halves

Cisely holds two models of the same business, and most of what makes a change correct lives in the first one.

	What it holds	Outlives
The business context	who you serve, what they are trying to achieve, what you promise them, and how you know the promise was kept	every application you build
The engineering model	the software that answers that intent — the domain, the operations, the interface	one product

The engineering model is the half people expect. This manual is about the other one, and about why it is not a wiki.

Why this is a graph, not a document

Every company already has this material. It is in a strategy deck, a persona PDF, a goals spreadsheet and a backlog, and those four artifacts do not know about each other. So the reason a piece of work exists survives as folklore: someone was in the room, and when they leave, the why leaves with them.

Here it is a graph of linked nodes instead. That single change buys something specific:

"Why are we building this?" becomes answerable by following a link, rather than by asking someone who was there.

Not by convention — by construction. A user story cannot exist without serving at least one expectation; the platform refuses to remove the last one. So the question has an answer for every story in the system, whether or not anybody was disciplined about it.

The shape: a demand ⟷ response loop

Read it in this order and it explains itself.

The demand side — who wants something, and what they are trying to achieve


Persona	the archetypes of who acts in and around the business
Operating context	the situations a persona acts within
Stakeholder	a persona situated in an operating context — the bearer of expectations
Goal	what a stakeholder is ultimately reaching for
Expectation	the measurable proxy for that goal — the promise

The forces, and what it all rests on


Strategic factor	the forces acting on the company that strategy must answer to
Belief	free-standing convictions — the alignment keystone

The response side — what the business intends to do about it


Mission	the singular why
Strategy	the how — the choices that pursue the mission
Sub-strategy	the refinement layer beneath strategies
Initiative	the concrete bets that execute a strategy
Metric	the instruments that close the loop

The product tier — where intent becomes buildable


Product	the durable offering the business builds
Journey	the arc a stakeholder walks through a product
Journey step	the moments that make up an arc
User story	the atom of intended response — the only backlog item that must name its reason

flowchart LR
  P["Persona"] --> S["Stakeholder"]
  OC["Operating context"] --> S
  P --> G["Goal"]
  S --> E["Expectation"]
  G -.proxied by.-> E
  B["Belief"] --> G
  B --> ST["Strategy"]
  M["Mission"] --> ST
  SF["Strategic factor"] --> ST
  ST --> I["Initiative"]
  E --> US["User story"]
  MET["Metric"] -.measures.-> E

The keystone

One link in that diagram is worth more than the rest, and it is the dotted one nobody draws by accident.

A goal sits on the demand side: what a persona is reaching for. A strategy sits on the response side: what the business has decided to do. Both may root in a belief.

When a goal and a strategy root in the same belief, the business and its customers are working from the same conviction — and that coincidence is now a fact in the graph rather than an assertion in a deck. When they root in different beliefs, that is visible too, and it is usually the most interesting thing anyone will learn that quarter.

This is why beliefs are free-standing roots rather than properties of something else. They are the thing both sides can point at.

How it connects to the software

The two halves are linked deliberately, in both directions:

a piece of engineering work can link to any business node, and you can walk it back the other way;
decisions, lessons and session records anchor to the same nodes;
discussions anchor to them too.

So from a piece of the engineering model you can reach the intent it serves, the decisions taken about it, and the conversation that surrounded it — and from a business intent you can reach everything built for it.

What this means for how you work

Start from intent, not from the request. Read the goal or expectation a task traces to before modelling anything. If the task names no reason, find it or ask for it.
Use the business's own nouns. A Shipment in the software and a "delivery" in the strategy is a translation cost paid in every future conversation.
Leave the trail. Link what you build to what it serves. That link is what lets the next person reconstruct your reasoning without you.

This tier is not a tracker

There is no in progress here, and no done. This tier answers three questions and only three:

Has the business committed? Was it discharged? Did it work?

Execution state — who is doing it and how far along — lives elsewhere, on the work items. Keeping them apart is deliberate: a commitment that quietly becomes a status is a commitment nobody is accountable for.