Customer Renewal Intelligence
One engineering scenario, built properly and running in front of you. A real relational database, six versioned rules, a permission boundary, an evidence chain and an approval gate that records who decided what. Every figure on this page is computed at runtime — the synthetic-data label is not decoration.
Identify renewal opportunities that require attention and explain the supporting evidence.
This is the instruction. Everything the demonstration does follows from it — the records it reads, the rules it applies, the evidence it cites, and the action it refuses to take on its own.
Data served by /api/demo/task, /api/demo/comparison,
/api/demo/schema and /api/demo/records on this origin.
No content on this page is hard-coded result text.
Twelve tables, three views, and the relationships the agent depends on
This is not a diagram drawn to explain a concept. It is the schema of the database the demonstration is running against, read live, with the row counts it currently holds. The relational design is what makes reconciliation possible at all.
customer 60 rows
- customer_idTEXT PK
- customer_nameTEXT
- segmentTEXT
- regionTEXT
- countryTEXT
- since_yearINTEGER
- account_manager_idTEXT FK
- + 2 more
contract 60 rows
- contract_idTEXT PK
- customer_idTEXT FK
- start_dateTEXT
- end_dateTEXT
- contract_value_usdINTEGER
- auto_renewINTEGER
- renewal_notice_daysINTEGER
- + 1 more
subscription 104 rows
- subscription_idTEXT PK
- customer_idTEXT FK
- product_idTEXT FK
- seatsINTEGER
- unit_price_usdINTEGER
- started_onTEXT
- ends_onTEXT
- + 1 more
usage_monthly 384 rows
- usage_idINTEGER PK
- customer_idTEXT FK
- product_idTEXT FK
- monthTEXT
- active_usersINTEGER
- api_callsINTEGER
- avg_session_minREAL
- + 1 more
support_ticket 181 rows
- ticket_idTEXT PK
- customer_idTEXT FK
- raised_onTEXT
- closed_onTEXT
- priorityTEXT
- categoryTEXT
- statusTEXT
- + 1 more
renewal_opportunity 22 rows
- opp_idTEXT PK
- customer_idTEXT FK
- contract_idTEXT FK
- opened_onTEXT
- stageTEXT
- proposed_value_usdINTEGER
- currencyTEXT
- + 3 more
Views the agent reads through
v_engagement_trend
CREATE VIEW v_engagement_trend AS SELECT u.customer_id, u.product_id, u.month, u.active_users, u.api_calls, u.support_tickets, LAG(u.active_users) OVER (PARTITION BY u.customer_id, u.product_id ORDER BY u.month) AS p…
v_open_signals
CREATE VIEW v_open_signals AS SELECT t.customer_id, COUNT(*) AS open_tickets, SUM(CASE WHEN t.priority IN ('P1','P2') THEN 1 ELSE 0 END) AS high_priority_open, MIN(t.raised_on) AS oldest_open_date FROM support_ticket t WHE…
v_renewal_watchlist
CREATE VIEW v_renewal_watchlist AS SELECT c.customer_id, c.customer_name, c.segment, c.region, ct.contract_id, ct.end_date, ct.contract_value_usd, ct.renewal_notice_days, CAST(julianday(ct.end_date) - julianday('…
Rules as data, versioned and weighted
A rule that lives in a prompt is a suggestion. A rule that lives in a table, has an owner and a version, and returns a source reference for everything it claims, is a control. These six are the control set for this scenario.
| Rule | Version | Statement | Severity | Weight | Reads |
|---|---|---|---|---|---|
| BR-01 | v1.2 | Contract inside the renewal notice window | Critical | 30 | contract |
| BR-02 | v1.1 | Unresolved high-priority support tickets | Warn | 20 | support_ticket |
| BR-03 | v1.0 | Contract value above the review threshold | Info | 10 | contract |
| BR-04 | v1.3 | Missing or inconsistent customer data | Critical | 25 | customer, contract, renewal_opportunity |
| BR-05 | v1.4 | Declining product engagement | Warn | 15 | usage_monthly |
| BR-06 | v1.5 | Contractor action requires authorised approval | Critical | 5 | renewal_opportunity |
What a rule must return to be auditable
- An outcome: Pass, Fail, Flagged or NotApplicable.
- A human-readable message stating what was found.
- The source references it read to reach that conclusion.
- Structured detail, so a reader can verify the arithmetic.
- A version, an owner and a severity with a weight.
Permission boundary in force
| Role | Resource | Scope | Conditions |
|---|---|---|---|
| AccountManager | approval_request | Read | — |
| AccountManager | contract | Read | — |
| AccountManager | renewal_opportunity | Read | — |
| AccountManager | renewal_opportunity | Write | — |
| AccountManager | support_ticket | Read | — |
| AccountManager | usage_monthly | Read | — |
| AgentService | approval_request | Write | {"subject":"on_behalf_of"} |
| AgentService | contract | Read | {"subject":"on_behalf_of"} |
| AgentService | customer | Read | {"subject":"on_behalf_of"} |
| AgentService | renewal_opportunity | Read | {"subject":"on_behalf_of"} |
| AgentService | support_ticket | Read | {"subject":"on_behalf_of"} |
| AgentService | usage_monthly | Read | {"subject":"on_behalf_of"} |
| CommercialDirector | approval_request | Approve | — |
| CommercialDirector | approval_request | Read | — |
| CommercialDirector | contract | Read | — |
| CommercialDirector | customer | Read | — |
| CommercialDirector | renewal_opportunity | Read | — |
| CommercialDirector | renewal_opportunity | Write | — |
| CommercialDirector | support_ticket | Read | — |
| CommercialDirector | usage_monthly | Read | — |
The same question at three levels of engineering
One scenario, three configurations, side by side. No accuracy percentages — we have not measured any, and inventing one would be the least credible thing on this page. What you can compare is capability: what each configuration can and cannot do.
It shows that capability follows engineering, not model size or cleverness. It is not a benchmark, and the three configurations are not equally expensive to build — Mode C costs considerably more and takes longer. That trade is the whole subject of this site.
What is running here, and what is only designed
The chain below is the reference architecture. Colour marks what this demonstration actually executes: solid is implemented in this codebase, muted is designed but not built here.
Business Data
Synthetic customers, contracts, subscriptions, tickets, usage.
Context & Relationships
Reconciled views, joins and definitions.
Rules & Permissions
Six versioned rules and a role boundary.
Agent & Tools
The agent task, evaluated against those records.
Validation & Human Oversight
Reconciliation and an approval gate.
Business Action
Scheduled, held or escalated — with evidence retained.
| Layer | State | In this demonstration |
|---|---|---|
| Business data | Simulated | Seeded SQLite database, 60 synthetic customers, 5 planted defects. |
| Data access & context | Partial | Deterministic joins over three views. No ranking or retrieval model. |
| Business rules | Implemented | Six versioned rules in engine.py, stored in the business_rule table. |
| Agent / task execution | Rule-driven | No language model. The recommendation is computed, not generated. |
| Validation | Implemented | Referential reconciliation, weighted score, evidence assembly. |
| Human approval | Implemented | Named-role gate; decisions written and audited. Try the Approval gate tab. |
| Business action & audit evidence | Local only | Written to the demonstration database. No external system is contacted. |
Exactly what is real, what is simulated, and what is not built
We would rather you read this before you explore than after you had been misled. If anything here is unclear or looks overstated, that is a defect in the page and we would like to know.
| Component | State | What that means here |
|---|---|---|
| Business data | Simulated | 60 customers, 60 contracts, 104 subscriptions, 384 usage rows, 181 tickets and 22 renewal opportunities are generated deterministically by demo/seed.py with a fixed seed. No real customer, contract or ticket is present. Five defects are planted deliberately so the reconciliation rules have something to find. |
| Relational schema | Implemented | 12 tables with foreign keys, 3 views and 20 permission rows, created by demo/schema.sql and read live at /api/demo/schema. The column list you see is read from the database, not transcribed. |
| Business rules | Implemented | Six rules (BR-01 … BR-06) with versions, severities, weights and owners, stored in the business_rule table and evaluated in demo/engine.py. Every claim the agent makes carries the source references it read. |
| Retrieval and context | Simulated | The context assembly is a deterministic join over the reconciled views rather than a production retrieval stack. The design is representative; the ranking layer is not implemented. |
| Language model | Not implemented | There is no model in this loop. The recommendation is computed by the rule engine, which is why the same input always produces the same output. We would rather show you that than a generated sentence with no provenance. |
| Permission boundary | Implemented | The evaluation runs under the identity origin-agent/renewal-watch and reads the role_permission table. Write actions are not available to the agent at all; it can only raise a request. |
| Human approval gate | Implemented | Consequential actions are held for a named role. POST /api/demo/approval requires a person, writes to approval_request and audits the decision into decision_evidence. You can use it on this page; the record persists. |
| Business systems | Not connected | No CRM, ERP, ticketing or email system is connected. The action the agent proposes would in a real deployment be a scheduled review or a message; here it is written only to the demonstration database. |
| Accuracy claims | Deliberately absent | We publish no accuracy percentage, because we have not measured one against your data and a number invented for a marketing page would be worse than no number at all. |
The five statements this demonstration makes about itself
Every record is generated by a seeded script. The structure, relationships and constraints are realistic; the content is not real.
The recommendation is computed by the rule engine. Nothing here demonstrates the quality of a model's reasoning, and we do not claim it does.
The approval you can submit is written to the demonstration database. It does not schedule anything, notify anyone or touch a system of record.
There are no latency, throughput, accuracy or cost numbers on this page, because none have been measured in a way you could rely on.
It is a demonstration built by us, on synthetic data, to show the engineering. We will not present it as a reference, and we would ask you not to cite it as one.
The same engineering, at production scale
Everything above runs in a browser tab with no container, no model endpoint and no network. That is deliberate — you should be able to inspect it without installing anything. It also means it is smaller than the system it represents.
The table below is the honest bridge. For each capability, it states what this page actually shows, what the production platform does beyond it, and how the two relate. The production platform is not named on this site; the engineering is what we are asking you to judge.
| Capability | What this page shows | What the production platform does | Relationship |
|---|---|---|---|
| Source integration | One synthetic SQLite file, seeded by script, read through views. | The production platform connects to enterprise sources in place — relational and distributed engines, commercial and domestic databases — without requiring the business to migrate its data or write a connector first. | Broader |
| Data understanding | A hand-written schema with 12 tables and foreign keys, and rules that name their source tables explicitly. | The platform derives an understanding of a source it has never seen: table purpose, column meaning, enumeration rules, relationships between tables, and which columns are sensitive. Human review corrects it; the business supplies its own dictionary where one exists. | Derived, not hand-written |
| Quality rules | Six versioned rules, stored as data, each returning a pass, fail or flag with the records it read. | The platform runs a general rule library covering validity, uniqueness, consistency, completeness, value ranges and date validity, and lets teams add their own. Findings are traced to source and exported as remediation work, not just as a score. | Broader library, same contract |
| Query and aggregation | Deterministic joins over reconciled views. The engine never issues SQL at runtime. | The platform resolves a business question into executable, read-only SQL across sources, plans multi-step queries, and returns the answer together with the sources and the derivation path that produced it. | Model-driven, source-agnostic |
| Retrieval and context | A deterministic context assembly over the reconciled views. The ranking layer is not implemented. | The platform retrieves across structured and unstructured sources with embedding search and reranking, and maintains the semantic model those queries are answered against. | Full retrieval stack |
| Permission model | 20 role-permission rows read at evaluation time, with write actions unavailable to the agent entirely. | The platform enforces row-level and column-level access with masking, and records every query and operation to an audit trail that a compliance function can read. | Column-level, audited |
| Human approval | A named approver, recorded in approval_request and audited into decision_evidence. You can use it on this page. | The same pattern becomes a configured approval red line: risk-graded actions, thresholds that require a human, and exception handling for anything that falls outside the expected path. | Configurable thresholds |
| Agent and skill boundary | One agent identity with a fixed task, one action type, one output. | The platform binds role-shaped agents to their own data, skills and decision boundary, and packages process steps into skills with defined risk levels and failure handling, connected to external systems through standard interfaces. | Multi-agent, skill-based |
| Deployment | A single process on one port, with the data alongside it. | The platform is self-hosted, so the data plane stays inside the customer's environment: private, offline or isolated deployment, single sign-on, and no dependency on an external service for the data path. | Self-hosted, air-gap capable |
| Delivery model | None. This page is the demonstration. | The same work is delivered by forward-deployed engineers: scenario definition, data facts and knowledge definitions are judgement calls made with your team, and the remaining implementation is generated and iterated domain by domain rather than modelled once in the abstract. | Judgement plus generation |
Why we show a reduced version. A demonstration that needs a container, a model key and a configured data source cannot be inspected by a visitor in the time they will give you. So the demonstration is a working specimen of the engineering, not a scaled-down product: the same rule contract, the same evidence discipline, the same permission boundary and the same approval gate, with the parts that require infrastructure left visible rather than hidden.
Request a technical discussion
Bring an engineer and a question. We will walk through the method on your own constraints rather than pitch a platform.