Contracts.
What each capability promises, written down and versioned.
Every capability under contract.
Every demand answered against it.
AugIQ holds a written, versioned model of what each capability promises — then answers every new demand against it. Already covered. Covered by configuration. Or here is exactly what it would take.
See AugIQCan we support a partner who funds their own promotions?
Strategy docsRoadmapJiraConfluenceCRMDelivery history
Initial assessment
Pricing & promotion
Partner funding
Settlement
1 contract break2 viable options
Demand arrives weekly. Capability changes quarterly.
Nobody is measuring the gap.
Context.
Strategy, roadmap, delivery history and customer demand in one model.
Deltas.
The exact difference between what’s being asked and what’s been promised.
Proof.
Evidence the capability works, not evidence the work shipped.
AugIQ turns incoming demand into scoped decisions, before it becomes bespoke work.
Nothing is built twice.
Repeat demand is recognised as repeat demand, across markets and teams.
Nothing arrives as a surprise.
Every request lands somewhere specific in a promise that’s already written.
Nothing commits without a trade-off on the table.
What moves, what waits, what it depends on — before the meeting, not after.
Open sensing. Governed commitment.
Anyone can ask what something would take. Reality reaches the people closest to customers first, and making them file a form is how organisations stay ignorant.
Spending the quarter is a different act. Committing resources, changing a customer promise, moving architectural direction — those stay explicit, owned and auditable.
01
Ask
Open
02
Raise a signal
Open
03
Draft a demand
Open
04
Sponsor it
Sponsored
05
Mark it decision-ready
Sponsored
06
Commit resources
Restricted
07
Change the contract
Restricted
Every answer carries its sources, its assumptions, its confidence and the contract version it reasoned from. You can disagree with it and see precisely where to disagree.
AugIQ prepares judgment. It doesn’t replace authority.
Four numbers, named before we start.
We don’t have a decade of benchmarks. We have a scoreboard we’re willing to publish in advance, which is the part most firms avoid.
- 01Share of incoming demand served without new product development.
- 02Time from signal to decision.
- 03Duplicate requests identified before they were built twice.
- 04Time to onboard a new partner or market, first one against the next.
Measured from the first engagement, reported whether or not they flatter us.
One capability, shown properly.
A contract for a pricing and promotion capability: what it promises, the situations it handles, the standard it holds to, and the line where it stops. Then a demand that lands exactly on that line, and the delta that follows — across rules, operating model, product, data and people.
Capability contract · v1.4
Pricing & promotion
Commercial Platforms
Decision latency · 4 days
Promise
Support manufacturer-funded promotions across partners, with explicit eligibility, approval and settlement rules.
Boundary
Stops where a partner requires funding logic that cannot be expressed through the governed rule set.
Demand on the boundary
Support a partner funding its own promotions with market-specific settlement windows.
Rules · add funder hierarchyOperating model · assign settlement ownerProduct · extend configurationData · evidence source of fundsPeople · approve exception path
Four of those five have nothing to do with software, which is why the version that shipped as a feature was never going to hold.
See the worked exampleWhat AugIQ does with a demand.
01 / Product surface
Connect.
Strategy, roadmap, delivery and customer signals in one capability model.
02 / Product surface
Stress.
Run any demand against what the capability currently promises.
03 / Product surface
Decide.
Options, dependencies, trade-offs, and what moves if you commit.
04 / Product surface
Prove.
Scenarios that show the capability holds under real conditions.
The model doesn’t build itself.
Cinquelli architects the capability system: what the organisation must be able to promise, how those capabilities are structured, what has to come together for each to hold. AugIQ keeps it true as demand keeps arriving.
Most engagements begin with one capability — usually the one everything else has started to depend on.
The methodThe Capability Contract Standard
An open specification for writing down what a capability promises. Free, citable, and usable without us.
The field definitions. The rules for versioning a promise. How to write a situation so it can be tested rather than argued about. Three worked contracts across different kinds of capability. And the mistakes that make a contract useless — including the ones we’ve made.
Organisations are already doing a version of this badly, in architecture decision records, in acceptance criteria, in the heads of two senior people. The standard gives it a form.
Read the standardBring a decision you’re about to make.
Something your team is close to committing to — a partner, a market, a large customer, a regulatory change. We’ll put the capability it lands on under contract, and show you what it would actually take.
See AugIQThe model that keeps itself honest.
Every capability model your organisation has built was accurate on the day it was finished. AugIQ's is maintained by the flow of real demand, so every question asked against it leaves it more accurate than before.
One graph, not eleven documents.
Strategy and its priorities. Capabilities and what each one promises. The domains and components each is made of. The business rules, operating model, systems, data and people each depends on. Who owns what.
What's committed, what shipped, what it cost, and whether it worked.
Held as relationships rather than pages, so a question about one part can be traced through all of it.
One question, traced
Can we support a partner who funds their own promotions?
- 01Funding attribution
- 02Principal model
- 03Promotion rules
- 04Finance integration
- 05Settlement data
- 06Owning team
- 07Two roadmap items move
Five answers, each with its reasoning attached.
Already supported.
The contract covers it. Go.
Supported through configuration.
No build, and here is who does it.
Partly supported.
This part you already promised. This part you didn't.
Not supported.
Here is the delta: what the promise must become, what changes in architecture and stack, who owns it, what it depends on, and what currently committed work moves.
In conflict.
This contradicts a rule, an architectural principle, or a decision already on the record.
Every answer carries its sources, its assumptions, its confidence, and the contract version it reasoned from. You can disagree with it and see exactly where to disagree.
The fourth market to report a problem shouldn't be the first to be believed.
Anyone can raise what they're seeing — a customer conversation, a lost deal, a support pattern, a regulator's letter. AugIQ compares it against everything already in the model: previous requests, other markets, existing contracts, delivery history.
A local complaint becomes a structural finding. Four markets reporting the same registration problem stops being four tickets and becomes one capability question, before it becomes four builds.
Readiness
Observed
Contextualised
Qualified
Decision-ready
Committed
Signals move through readiness, so the backlog stops being where ideas go to be forgotten.
A valid problem is not automatically a priority.
A real capability gap still has to earn the quarter against every other real capability gap. AugIQ lays out what each option is worth, what it reuses, what it blocks, what it costs, what it risks, how reversible it is, and how confident any of that is.
One decision, on the record, with its reasoning
CommitRun a discoveryBundleHandle in configurationDeliberate one-offDefer or decline
Customer request does not automatically mean feature requirement.
Coherent increments, and evidence they held.
Committed work leaves AugIQ as a capability increment — a usable expansion of the promise, with its dependencies, owners and sequence — rather than as a scattering of tickets that happen to share a label.
And each increment carries the scenarios that would prove it, written before the work starts. When they pass, the contract moves to its next version with an owner and a date. When they don't, that's visible too.
Open sensing. Governed commitment.
Access widens at the bottom and narrows at the top: anyone can ask and raise, fewer can sponsor, fewer still can mark something decision-ready, and only the right authority can commit resources or change what a capability promises.
01
Ask
Open
02
Raise a signal
Open
03
Draft a demand
Open
04
Sponsor it
Sponsored
05
Mark it decision-ready
Sponsored
06
Commit resources
Restricted
07
Change the contract
Restricted
Every consequential conclusion keeps its evidence, its assumptions, its owner and its confidence. AugIQ prepares judgment; it doesn't replace authority.
Adjacent to several things. The same as none of them.
Not an architecture repository.
Those hold an inventory that someone has to maintain. This holds promises that demand tests continuously.
Not a roadmap tool.
Roadmaps sequence work. This decides what the work should be, and why that rather than something else.
Not a portfolio or OKR system.
Those track whether you did what you said. This answers whether you can do what you're about to say.
Not a knowledge assistant.
Those retrieve what's written. Most of what matters here was never written, which is why the model has to be built before it can be queried.
The model doesn't build itself.
Cinquelli architects the capability system. AugIQ keeps it true as demand keeps arriving.
The methodThe Capability Contract Standard
An open specification for writing down what a capability promises. Version 1.0. Free to use, adapt and cite, including by our competitors.
Every organisation already does a version of this, badly — in architecture decision records, in acceptance criteria, in the heads of two senior people who are always in the room. The standard gives it a form.
What a capability contract is.
A capability contract is the explicit, versioned specification of what a capability is expected to handle, under which conditions, to what standard, with what guarantees and constraints. It is written for a capability, not for a system, and it is independent of whatever technology currently implements it.
It is not a requirements document, because it describes what must remain true rather than what is to be built. It is not an architecture diagram, because it says nothing about how. It is closest in spirit to an interface contract in software, raised to the level at which a business makes commitments.
What every contract must say.
Why does it exist?
Purpose and outcomes
What the capability is for, and which business outcomes depend on it. One or two sentences. If it takes a paragraph, the capability is probably two capabilities.
Who is relying on this?
Consumers
The people, teams, systems and other capabilities that depend on this promise. Named. A consumer who doesn't know they're on this list is an outage waiting to happen.
Where does it show itself?
Situations
Real or realistic situations the capability must handle, preserving the decisions, constraints, stakeholders, timing and consequences that make them hard. Not user stories. Not abstractions.
What must it do?
Required behaviour and outputs
What the capability does with those situations and what it must produce. Stated so that someone outside the team could tell whether it happened.
What can never break?
Invariants
What must remain true across every variation the capability supports. These are the constraints that turn a flexible capability into a trustworthy one.
How well, and when?
Standards and conditions
The required accuracy, speed, quality, cost or outcome — and the circumstances under which it must still hold: load, ambiguity, incomplete information, time pressure, conflicting stakeholders.
Where does it end?
Exclusions
What the capability deliberately does not support. Mandatory. A contract without exclusions is a wish.
How would we know?
Proof
The situations that would demonstrate the capability holds, and the evidence standard required. Written before the work, not after.
The rules that keep a promise honest.
- 01
A situation is not a requirement.
It is something that happened or could happen, with actors, constraints and consequences intact. If it could be satisfied by a screen, it isn't a situation.
- 02
Exclusions are mandatory.
The value of a contract is concentrated almost entirely in what it refuses. A contract nothing can fall outside of is too vague to be tested.
- 03
Conditions are part of the promise.
A standard without conditions is a claim about a good day.
- 04
Ownership is a person.
Not a team, not a function. Someone has to be able to say yes to a change in what is promised.
- 05
Version the promise, not the software.
A release that changes nothing about what is promised does not change the contract version. A configuration change that broadens the promise does.
- 06
Three kinds of change.
A clarification leaves the promise unchanged. An extension adds situations without altering existing ones. A break narrows, removes or alters something already promised — and requires every named consumer to be told.
- 07
Proof precedes commitment.
If the evidence that would satisfy you is written after the work, it will be written to fit the work.
What a written promise looks like.
One commercial capability where the promise is about rules and money. One operational capability where the promise is about throughput under load. One judgment capability — the hardest kind to contract, and the one most organisations pretend they don't have.
Commercial
Pricing and promotion
- Version
- v1.4
- Owner
- Director, Commercial Platforms
- Effective
- 2026-03-12
- Purpose and outcomes
- Allow commercial teams to run governed price and promotion mechanics across partners and markets without bespoke development. Revenue predictability, margin control and partner satisfaction depend on it.
- Consumers
- Market commercial teams
- Partner operations
- Finance settlement
- Customer-facing storefront
- Revenue reporting
- Situations
- 01A manufacturer funds a promotion for one partner in two markets with different settlement windows, and finance must attribute the funding to the correct source in each.
- 02A partner requests an exclusive discount that overlaps an existing campaign, three days before launch, with no engineering capacity available.
- 03A regulator restricts a promotion type in one market while the same mechanic remains valid in four others.
- Required behaviour and outputs
- Configure, approve, publish, monitor and settle a promotion, producing an auditable record of who funded it, who approved it, which customers were eligible and what it cost.
- Invariants
- — Every promotion has an attributable funding source.
- — No customer sees a price that was never approved.
- — Settlement figures reconcile to the approved mechanic.
- Standards and conditions
- A new promotion of a supported mechanic is live within two business days, including approval, and holds under end-of-quarter volume and overlapping campaigns.
- Exclusions
- — Funding logic that cannot be expressed in the governed rule set.
- — Market-specific code branches.
- — Retroactive repricing of settled transactions.
- Proof
- The three named situations executed end to end in a production-like environment, with settlement reconciled and the audit record complete.
Operational
Partner onboarding
- Version
- v2.1
- Owner
- Head of Partner Operations
- Effective
- 2026-02-04
- Purpose and outcomes
- Take an approved partner from signature to first valid transaction through a repeatable path. Time-to-revenue and the cost of expansion depend on it.
- Consumers
- Commercial teams
- Legal and compliance
- Integration engineering
- Support
- Market general managers
- Situations
- 01Eleven partners are onboarding simultaneously at quarter end while two integration specialists are on leave.
- 02A regulated partner enters with additional verification and data-residency requirements not present in any previous onboarding.
- 03A partner supplies incomplete master data and wants to launch in nine days for a seasonal peak.
- Required behaviour and outputs
- Verify, configure, integrate, test and activate a partner, producing a signed readiness record naming the exceptions granted and who granted them.
- Invariants
- — No activation without verified identity and tax status.
- — Every exception has a named approver.
- — Data residency constraints are enforced before any transaction.
- Standards and conditions
- Median twenty working days from signature to first valid transaction, holding at up to fifteen concurrent onboardings and with up to thirty per cent of master data arriving incomplete.
- Exclusions
- — Partners requiring a bespoke integration protocol.
- — Activation before evidence owners and exception authority are named.
- — Migration of a partner's historical transaction data.
- Proof
- Three consecutive onboardings completed within standard under concurrent load, including one regulated partner, with readiness records complete.
Judgment
Portfolio commitment
- Version
- v1.0
- Owner
- Chief Operating Officer
- Effective
- 2026-01-20
- Purpose and outcomes
- Turn qualified demand into resourced commitments that the organisation can defend three quarters later. Strategic coherence and credibility of the plan depend on it.
- Consumers
- Executive committee
- Product and engineering leadership
- Market leadership
- Finance planning
- The teams whose work is displaced
- Situations
- 01Three markets sponsor the same demand in different words, while a committed regulatory change already consumes a fifth of capacity.
- 02The largest customer escalates a requirement that duplicates a bespoke build delivered for another customer eighteen months earlier.
- 03A decision must be made with a materially incomplete cost estimate and a hard external deadline.
- Required behaviour and outputs
- Produce a decision of record — commit, discover, bundle, configure, one-off, defer or decline — with options, displacement, dependencies, reversibility, confidence and named authority attached.
- Invariants
- — No commitment without stated displacement.
- — Every decision records its confidence and its assumptions.
- — Duplicate demand is recognised before resourcing, not after.
- Standards and conditions
- A decision-ready demand reaches a recorded decision within ten working days, holding when estimates are incomplete and when sponsors disagree.
- Exclusions
- — Deciding without a named accountable authority.
- — Commitments whose displacement is unknown.
- — Re-deciding a live commitment outside the agreed review point.
- Proof
- A quarter of decisions reviewed against outcome: displacement as stated, no duplicate builds, and confidence levels that matched what actually happened.
Every example is generic. No company, partner or employer is named.
Where contracts quietly fail.
A feature list wearing a contract's clothes.
If every line describes something built rather than something promised, nothing has changed except the filename.
No exclusions.
Usually because naming them felt like admitting weakness. It is the opposite: a capability that promises everything guarantees nothing.
Adjectives instead of standards.
Fast. Accurate. Seamless. None of these can fail a test.
Situations written from the inside.
If the situation only makes sense to someone who already knows the system, it will only be tested by people who already know the answer.
Versioning that tracks releases.
The contract then describes the software's history rather than the organisation's commitments.
A contract nobody maintains.
The most common failure by far, and the reason this is a standard rather than a template. A promise that isn't tested by incoming demand reverts to a document within two quarters.
Take it and use it.
Take one capability that several teams depend on and that has surprised you recently. Write its contract as it is today, not as you wish it were. Then take the last three requests your team committed to and read them against it.
If all three fall inside the contract, it's too vague. If all three fall outside, the capability was never really defined. Somewhere in between is where the useful conversation starts.
The template, the field definitions and the three worked examples are here. Attribution appreciated, not required.