Charge customers for each completed job.
Job count used for:
Capacity planning
Added: Customer billing
The company already has useful activity counts, so the commercial decision appears straightforward.
Every change rewrites more than you can see.
A business decision, requirement, regulation, architectural intervention, supplier update, or pull request can make existing assumptions and decisions no longer valid. Architourge discovers what became untrue, traces what depended on it, and helps determine what should happen next.
- Determine: What became untrue?
- Trace: What depended on it?
- Reveal: What else is affected?
- Respond: What should happen next?
- 01
Each completed job is billed exactly once.
- 02
Retries and failed runs never create a billable job.
- 03
Late corrections are reconciled before an invoice is issued.
- 04
Every invoice line links to the job records behind it.
Fails: Retries are billed as new jobs. Bill each job once, keyed by its job ID.
Passes: Failed runs never create a billable job.
Fails: Late corrections reach invoices before they are reconciled.
Fails: Invoice lines don’t yet link to the job records behind them.
A constructed commercial example
They already counted usage. Then they changed how they charge.
A SaaS company uses activity counts to understand demand and plan capacity. The counts are mature and useful. Then the company adopts usage-based pricing. The software did not become less reliable. The price changed what its numbers needed to prove.
What Architourge finds
- Every job has a unique ID.
- Each job logs its completion.
- Counts refresh every few minutes.
- An approximately correct usage count is good enough.
- Weekly totals feed capacity planning.
- Dashboards show the last 90 days.
Small discrepancies are tolerable for seeing patterns. They are not tolerable when they change a bill.
“completed job”depends onInvoices, contracts, forecasts, revenue reporting, and customer trust.
Each now depends on “completed job” meaning the same thing everywhere.
Make every charge traceable to agreed usage.
- Each completed job is billed exactly once.
- Retries and failed runs never create a billable job.
- Late corrections are reconciled before an invoice is issued.
- Every invoice line links to the job records behind it.
Define what counts, treat failures and retries consistently, and preserve evidence customers can inspect.
A different kind of change intelligence
It doesn’t manage the change. It determines what the change means.
Architourge complements the systems that coordinate delivery. Its role is to establish what a change invalidates, what depended on it, and what must now adapt.
Coordinates the response.
Plans, approvals, releases, communications, training, ownership, and organisational adoption.
Documents known effects.
Reviews a proposed change and records the components, processes, or stakeholders it may affect.
Comprehends the consequence.
Discovers what became untrue, follows technical and justification relationships, and preserves the reasoning as understanding evolves.
Impact assessment finds what a change may affect. Architourge determines what must be reconsidered—and why.
Inside the product—or in the world around it.
Nothing in your code needs to change for yesterday’s sound decision to become today’s risk. Architourge can receive a proposed intervention or detect a relevant change in the systems and context your product relies on.
Intent or objective
Redefine what the product is meant to achieve.
Requirements, priorities, success criteria, architecture, and implementation may all need to be reconsidered.
Business change
Introduce usage-based pricing.
Usage definitions, metering, contracts, invoices, revenue reporting, and customer trust.
Product change
Automate a manual approval.
Exception handling, accountability, controls, support workflows, and audit evidence.
External environment
Customer behaviour, regulation, or geopolitical conditions shift.
Markets, suppliers, dependencies, operating regions, and external systems can change what the product must do—even when its code has not changed.
The source is different. The question is the same: what does this make no longer true?
Beyond technical dependencies
Connections show what is related. Justification shows why a decision is valid.
A code graph may know that one service calls another. Architourge is intended to know that a decision was made because an assumption appeared to hold, based on particular evidence, in order to satisfy a requirement or commitment.
- Evidence18,420 completed jobs were recordedsupports
- AssumptionRecorded activity matches the agreed billable unitjustifies
- DecisionInvoice the customer for 18,420 unitssatisfies
- ObligationsAccurate, consistent, and explainable charging
An inspectable basis for action
Know what the conclusion rests on.
Architourge does not hide disagreement behind a confident answer. It keeps the basis of consequential action explicit, traceable, and governable.
- Evidence
- The material supporting every consequential conclusion remains visible.
- Assumptions
- Conditions on which a decision depends remain explicit and reviewable.
- Uncertainty
- Inference, contradiction, staleness, and missing evidence are kept distinct.
- Evolution
- Changes in the product and its environment can revise what was previously understood.
How it becomes possible
Artificial Apperception and the Appercept.
Artificial Apperception is the process through which Architourge discovers what must be understood, investigates evidence and competing perspectives, and revises its understanding as the product and its environment change.
Explore the underlying approach- Investigate the change
- Discover the questions, perspectives, assumptions, and evidence the situation requires.
- Maintain the Appercept
- Keep an explicit, persistent representation of the product as currently understood.
- Reconsider what depended on it
- When evidence or conditions change, identify the assumptions and decisions that need attention.
The reason it matters
AI makes change easier. Comprehension makes it deliberate.
As agents make increasingly consequential interventions, the hard question becomes less “can we make this change?” and more “do we understand what this change really means before we make it?”
Design partnership