Synthetic charging assurance
Six reproducible tests before launch.
For charging, QA and revenue assurance teams. Synthetic fixtures, explicit tariff rules and expert acceptance checks, not delivered customer case studies.
Precise, revenue-bearing, and spread across systems that were never designed to be read together.
A single offer can touch dozens of rating rules, balances, counters, notification thresholds and lifecycle states. The intent lives in a requirement or an offer specification. The implementation lives in a charging export that only a handful of engineers can read fluently. The proof lives in a test repository and in the usage records that flow through mediation, rating and billing every day.
When those layers disagree, the result is silent. A decimal-versus-binary allowance, a missing threshold notification or an unmapped rating group does not raise an alarm. It shows up weeks later as leakage, overcharge, disputes or a regulatory finding.
ThirdEye agents are built for exactly this kind of work: read many sources, reconcile them against a stated rule, and hand an employee an evidence-backed brief. The employee decides. The agent does the reading, the joining and the first draft.
How these six were selected
- The task recurs every release, every bill cycle or every day.
- The answer depends on evidence from three or more systems.
- A defect has a direct revenue, customer or regulatory cost.
- A baseline exists, so the pilot can measure before and after.
- The employee keeps approval of anything that changes a system.
What ThirdEye brings to each case
- Cited answers from approved documents and exports.
- Analysis across catalogue, charging, billing and test data.
- Required pilot control: team-specific access tested against enterprise SSO and source permissions.
- Drafts and prepared actions that an employee reviews and submits.
- Required pilot evidence: an audit record of the user, sources, tool calls and approver.
Charging engineers, product owners and release approvers
Charging configuration review before go-live
“Check this new prepaid bundle's charging configuration against the offer specification before we promote it to production.”
Today. The offer specification is prose. The configuration is hundreds of parameters across rate plans, counters, balances, thresholds and consumption order. Review is manual, late in the release, and depends on two or three engineers who can read both. Errors surface after launch as leakage, overcharge or customer complaints.
Review the Everyday 20 prepaid bundle configuration (export CFG-2026-0412) against offer specification OS-118 v3 and list anything that would change what a customer is charged or receives.
Charging Configuration Reviewernow
Finding [measured] Synthetic review: verify unit conversion and test two candidate configuration defects before sign-off. [1]
Allowance unit check [measured] OS-118 s2.1 defines decimal units: 1 MB = 1,000,000 bytes and 1 GB = 1,000,000,000 bytes. Counter CTR_EVD20_DATA holds 20,000 MB = 20 GB = 20,000,000,000 bytes (about 18.626 GiB). A 1,024-byte rating unit alone does not prove under-delivery. Verify the byte-to-counter conversion before alleging a defect. [1]
Missing 100% notification [measured] OS-118 s5.2 requires notifications at 80% and 100% of allowance. Threshold set THR_EVD20 defines 80% only. Impact: notification obligation and spend-cap disputes. [2]
Out-of-bundle rounding [measured] OS-118 s3.4 prices excess data per megabyte. Assume $0.10 per decimal MB, proportionate byte charging with one final cent rounding. A configured 10,000-byte round-up block is a candidate mismatch, not proof that every session is overcharged. [3]
Next To confirm: the 28-day validity is configured as 28 calendar days from activation time, not from midnight local time; and the bundle is placed after any promotional balance in consumption order, which matches s4.1.
Sources[1] Offer specification OS-118 v3 (sample)[2] Charging export CFG-2026-0412 (sample)[3] Configuration standard CS-07 (sample)
Proposed workflow
- 1
Read the intent
Extract the business rules from the offer specification: allowances and units, price, validity and renewal, rollover, out-of-bundle rate, notification points, consumption order and lifecycle behaviour on suspend, migrate and expire.
- 2
Compare with the configured objects
Map each rule to the charging export: rate plans, rating groups, balances, counters, thresholds and validity periods. Flag rules with no configuration, configuration with no rule, unit and rounding mismatches, and lifecycle states with no defined behaviour.
- 3
Prepare the review
Produce a findings list that quotes the specification clause and names the configuration object, ranked by revenue impact, with the test scenarios that would prove each fix. The engineer confirms, rejects or reassigns every finding.
Why this is hard
- No formal mapping exists between specification language and configuration objects. The agent must reason about semantics, not match keys.
- Units, rounding and time-zone conventions vary by vendor and by team, so the agent works from an agreed configuration standard.
- Specifications are versioned and amended in review comments. The agent must state which version it checked.
Value hypotheses to test
- Defects found before launch are corrected in configuration. Defects found after launch cost refunds, credits, rerating and customer contact.
- Pilot hypothesis: reduce first-pass review effort without increasing missed defects; compare against an expert-reviewed baseline.
- Every review leaves a findings record that improves the next specification and the next configuration standard.
Reproducible synthetic test
- inputs
- Allowance 20,000 decimal MB; debit 1,024 bytes once.
- assumptions
- 1 MB = 1,000,000 bytes; 1 GiB = 1,073,741,824 bytes. Store counters as integer bytes; no per-event MB rounding.
- expected
- Initial 20,000,000,000 bytes; remaining 19,999,998,976 bytes. Decimal allowance is 20 GB, about 18.626 GiB.
- boundary
- Test zero usage, exactly 20,000,000,000 bytes and one byte beyond. Reject negative usage; no unit inference from display labels.
- acceptance
- Charging engineer reconciles specification, export and byte counter exactly; an unknown conversion is unresolved, not a defect.
- Pilot measure
- Confirmed findings per review, review time per offer, and charging defects that reach production.
- Connect
- Offer specifications, product catalogue export, charging configuration export, configuration standards, prior defect records.
- Autonomy
- Read and prepare. No configuration is changed by the agent.
Revenue assurance analysts and billing operations
Revenue leakage investigation
“Data usage in roaming zone 3 rose sharply last month but rated revenue was flat. Where is the gap?”
Today. Leakage hides in the seams between mediation, rating and billing. An analyst pulls samples from each system, joins them by hand on different keys, and tests one hypothesis at a time. A single case can take weeks, and the systemic cause is often not recorded.
Zone 3 roaming data: mediated volume is up 31% month on month, rated revenue is up 2%. Find where the gap concentrates and what explains it.
Revenue Assurance Analystnow
Finding [measured] The gap concentrates in one segment: subscribers migrated to the new consumer plans after 3 June, on rating group 4012. [1]
Pattern [measured] 94% of zero-rated Zone 3 sessions in the period belong to migrated subscribers. Sessions from subscribers on legacy plans rate normally. [1]
Cause [measured] The migration created the new plans with rating group 4012, but the Zone 3 roaming tariff table maps only groups 4010 and 4011. Unmapped sessions fall to the default rule, which rates at zero and logs no error. [2]
Exposure [estimated] About 41,000 sessions since 3 June. The exposure estimate is stated as a range with its assumptions in the attached query, and excludes any fair-use cap that would have applied. [3]
Next Draft revenue assurance case attached with the sample records, the tariff table extract and the migration change record CHG-2291. Recommended next step: confirm the mapping fix with charging engineering and decide whether rerating is commercially appropriate.
Sources[1] Mediation extract, Zone 3, period (sample)[2] Rated event store (sample)[3] Tariff table ZONE3_v9 (sample)[4] Change record CHG-2291 (sample)
Proposed workflow
- 1
Frame the discrepancy
Define the population: zone, period, offers and event types. Compare usage volume at mediation, rated value at charging and billed value at invoicing for the same population, using approved read-only queries.
- 2
Localise the gap
Drill by offer, rating group, event type, device and day until the gap concentrates. Test the usual causes in order: events dropped or filtered in mediation, events rated at zero, wrong rating-group mapping, allowances that never expire, reference data drift after a migration.
- 3
Explain and evidence
Present the pattern with sample records, the configuration or reference data that explains it, an exposure estimate with its assumptions, and a draft revenue assurance case for the analyst to open.
Why this is hard
- Volumes are large and the joining keys differ across mediation, rating and billing. The agent works from approved aggregate queries and samples rather than scanning raw records.
- The plausible causes are many and the evidence for each lives in a different system. The agent must test hypotheses in a disciplined order and show its rejects.
- Exposure estimates are easy to overstate. The agent must state assumptions and ranges, not a single confident figure.
Value hypotheses to test
- Pilot hypothesis: shorten evidence assembly; measure elapsed investigation time and analyst review effort against matched historical cases.
- Cases close with a systemic fix and a recorded pattern, which makes the next occurrence faster to spot.
- Analysts spend their time on judgement and recovery decisions rather than on data preparation.
Reproducible synthetic test
- inputs
- Three synthetic event IDs: E1 1 MB, E2 2 MB, E3 0 MB, all zone 3/group 4012. E2 appears twice in mediation.
- assumptions
- Unique event ID deduplication; decimal MB; $0.10/MB, no allowance, cap, discount or tax. One final cent rounding.
- expected
- Three unique events, 3 MB, expected $0.30. With missing mapping rating all at zero, candidate exposure $0.30, not recovered cash.
- boundary
- A duplicate must not add $0.20. Unknown zone is quarantined rather than assigned a guessed tariff; test a known mapped control group.
- acceptance
- Revenue assurance confirms joins and tariff eligibility for every event; billing approves any rerating. Report unmatched records separately.
- Pilot measure
- Time from a flagged discrepancy to an evidenced root cause, and the share of cases closed with a systemic fix rather than a one-off adjustment.
- Connect
- Mediation output, rated event store, billing extracts, catalogue and rating configuration, reference data for zones and rating groups, change records.
- Autonomy
- Read and prepare. Approved read-only queries only.
Contact-centre agents, billing operations and complaints teams
Bill and charge explanation for disputes
“This customer says they were charged twice for their add-on after changing plans mid-cycle. Explain what happened.”
Today. Mid-cycle changes produce proration, partial credits and re-issued add-ons that front-line agents cannot trace. The contact is escalated to billing operations, the customer waits, and goodwill credits are sometimes granted for charges that were correct.
Account ending 7741, May invoice. Customer disputes two charges of $12.00 for the Streaming Pass add-on. They changed from Plan S to Plan M on 22 May.
Billing Explanation Agentnow
Finding [measured] Both charges are consistent with tariff v14. The net of these invoice lines is $15.10, not $24.00, because a proration credit on line 10 offsets the first charge. [1]
Line 4, $12.00 on 14 May [measured] Streaming Pass purchased on Plan S. Charged in advance for the cycle ending 13 June. [1]
Line 10, credit $8.90 on 22 May [measured] Plan change terminated the Plan S subscription. Synthetic tariff v14 s6.2 uses a 31-day cycle [14 May 00:00, 14 June 00:00), with termination at 22 May 00:00 in the same fixed timezone. The unused interval includes 22 May through 13 June: 23 days. Credit = $12 * 23/31 = $8.9032258, rounded once half-up to $8.90. Taxes excluded. [2]
Line 9, $12.00 on 22 May [measured] Streaming Pass re-provisioned under Plan M, charged in advance for the new cycle ending 21 June. [3]
Next Customer explanation (draft): When you moved to Plan M on 22 May, your Streaming Pass restarted with the new plan. We refunded the unused part of the first month ($8.90) and charged the new month in advance. These lines net to $15.10 and cover overlapping advance service periods, not a calendar-May service cost. The billing reviewer must confirm the tariff and next-cycle behaviour before sending this draft.
Sources[1] Invoice INV-0526-7741 (sample)[2] Tariff v14, s6.2 (sample)[3] Order history, account 7741 (sample)
Proposed workflow
- 1
Reconstruct the account timeline
Assemble orders, plan changes, bill-cycle dates, add-on purchases, adjustments and prior contacts into one dated sequence for the disputed period.
- 2
Trace every charge
Link each bill line to the tariff version in force at the event time, the proration rule applied and the usage or subscription event behind it. State plainly whether each charge is consistent with the tariff.
- 3
Draft for both readers
Prepare a plain-language explanation for the customer and an internal evidence note for the agent. If a charge looks wrong, prepare the credit request with the evidence attached for a supervisor to approve.
Why this is hard
- The correct tariff is the one in force at the event time, and several versions can apply within one invoice.
- Proration, advance charging and adjustments interact. A correct answer must reconcile to the cent and say why.
- The customer-facing draft must be simple and accurate at the same time, and must not reveal internal system names.
Value hypotheses to test
- Pilot hypothesis: reduce avoidable escalation only when an audited explanation reconciles to the invoice and tariff.
- Goodwill credits are granted when a charge is wrong, not because the charge could not be explained.
- Explanations are consistent across agents and channels, which reduces repeat contacts and complaints.
Reproducible synthetic test
- inputs
- Advance charge $12; cycle 14 May 00:00 to 14 June 00:00; change 22 May 00:00. New advance charge $12.
- assumptions
- Fixed timezone, end-exclusive 31-day interval. 23 unused days including 22 May. Daily proration; round half-up once to cents; tax excluded.
- expected
- Credit $12 * 23/31 = $8.9032258 -> $8.90. Invoice lines net $12 + $12 - $8.90 = $15.10, not calendar-month service cost.
- boundary
- Change at cycle start: $12 credit; at cycle end: $0. A 23 May change gives 22 days and $8.52. Agree partial-day/DST rules before applying to real accounts.
- acceptance
- Billing expert independently reproduces day count and every cent; unresolved tariff versions block customer advice and credits.
- Pilot measure
- Handling time for billing disputes, escalation rate to billing operations, and explanation accuracy on an audited sample.
- Connect
- Bill detail, versioned tariff catalogue, usage records, adjustments and credits, order history, interaction history.
- Autonomy
- Prepare for approval. A prepared credit request that a supervisor approves.
Product architects, BSS solution designers and change approvers
Offer change impact analysis
“We want to raise the out-of-bundle data rate and add a 5 GB rollover to three consumer plans. What does that touch?”
Today. An architect assembles the impact across catalogue, charging rules, billing, self-care channels, APIs, notifications, regulatory spend caps and tests. Dependencies are implicit and spread over several repositories. Missed impacts appear as late defects or as a customer-visible inconsistency on launch day.
Proposed change CR-0472: out-of-bundle data from $0.08 to $0.10 per MB and a 5 GB rollover (one cycle) on Plan S, M and L. Build the impact register.
Offer Impact Analystnow
Finding [measured] Twenty-three impacted items across seven owners. Two require new objects rather than value changes, and one has a regulatory dependency. [1]
Charging [measured] Seven rating rules across the three plans and two legacy variants still on the base carry the out-of-bundle rate. Rollover requires a new balance type with one-cycle validity and a defined consumption order ahead of the base allowance. [1]
Channels and APIs [measured] The self-care allowance view exposes one data balance per plan. Showing rollover separately changes the balance-summary API contract and two app screens. [2]
Regulatory [measured] The spend-cap notification wording quotes the out-of-bundle rate. The template and its approval record must be updated before launch. [3]
Next Also listed: four bill presentation lines, two notification templates, one settlement report, nine existing regression tests that assert the old rate, and eleven new scenarios needed for rollover expiry and precedence. Open question: do legacy variants receive the rollover or only the rate change?
Sources[1] Product catalogue export (sample)[2] Charging configuration export (sample)[3] API specification BAL-2.3 (sample)[4] Notification template library (sample)[5] Test repository (sample)
Proposed workflow
- 1
Resolve the offer graph
Identify every product specification, price plan, balance, counter, discount and bundle that references or inherits from the three plans, including legacy variants still in the base.
- 2
Trace downstream
Follow each element into charging rules, notification templates, bill presentation, self-care and API contracts, regulatory spend-cap rules, partner settlement and reporting. Note where a new object is needed rather than a changed value.
- 3
Prepare the assessment
Produce an impact register with an owner per item, the test scenarios required, open questions and a suggested sequence. The architect edits and signs off.
Why this is hard
- Dependencies are rarely declared. Many are only visible by reading configuration, API contracts and templates together.
- Legacy offers inherit from the same base and are easy to miss because nobody sells them any more.
- Distinguishing a value change from a structural change decides the size of the release, so the agent must be explicit.
Value hypotheses to test
- Estimates and sequencing are based on a complete register rather than on memory.
- Test scope is derived from the register, so regression coverage matches the change.
- Track impacts found after sign-off; reduced late discovery is a hypothesis, not an observed result.
Reproducible synthetic test
- inputs
- Base 20 GB, eligible unused prior balance 7 GB, rollover cap 5 GB, usage 6 GB in new cycle.
- assumptions
- Decimal integer bytes; rollover first; valid for one cycle only; unused excess above cap expires.
- expected
- Carry 5 GB, expire 2 GB. Usage consumes 5 GB rollover + 1 GB base; 19 GB base remains and rollover is zero.
- boundary
- At next cycle boundary, unused rollover expires without being rolled again; test 0, 5 and 7 GB eligible balances and exactly-at-expiry usage.
- acceptance
- Architect verifies eligibility, balance API and notification expectations; QA executes expiry and precedence tests before release approval.
- Pilot measure
- Time to a reviewed impact assessment, and the number of impacts discovered after sign-off.
- Connect
- Product catalogue, charging configuration, architecture repository, API specifications, notification templates, bill presentation rules, test repository.
- Autonomy
- Read and prepare. The architect owns the register and the decision.
QA engineers, charging engineers and release managers
Charging test design and failure triage
“Generate the regression scenarios for the family shared-data offer and tell me why last night's charging run failed.”
Today. Charging tests must cover lifecycle, boundary and concurrency cases at once, and writing them is slow. When a nightly run fails, engineers receive hundreds of log lines with no grouping, and the same cause is investigated several times by different people.
Nightly charging regression RUN-8823: 14 failures. Group them and tell me whether this is software, data or environment.
Charging Test Triage Agentnow
Finding [measured] One cause explains all fourteen failures. It is a configuration change, not a software defect. [1]
Signature [measured] Every failure is a credit-control update rejected for a family member after the primary line was suspended. The same result code appears in all fourteen logs. [1]
Correlation [measured] The failures begin with the first run after change CHG-2311, which altered the suspension behaviour of the shared balance so that members inherit the primary line's state. [2]
Assessment [inferred] The tests assert the previous behaviour, in which members keep using the shared balance while the primary line is suspended. Requirement FAM-07 v2 now specifies the new behaviour. The tests are stale, not the software. [3]
Next Prepared actions: one defect ticket marked test update, referencing FAM-07 v2 and CHG-2311, and fourteen suggested assertion changes. Not yet raised. Also noted: no existing test covers a member leaving the group during a suspended period.
Sources[1] RUN-8823 logs (sample)[2] Change record CHG-2311 (sample)[3] Requirement FAM-07 v2 (sample)[4] Test repository (sample)
Proposed workflow
- 1
Derive scenarios from the requirement
Generate cases for allowance boundaries, threshold notifications, sharing precedence between members, join and leave mid-cycle, suspension and resume, migration, expiry at midnight across a daylight-saving change, and online charging sessions with several rating groups and final-unit handling.
- 2
Compare with existing coverage
Match generated scenarios to the test repository. Report gaps, duplicates and tests that assert values the requirement no longer specifies.
- 3
Triage failures
Group failures by signature, correlate each group with deployments, configuration and test-data changes, classify the likely cause as data, environment or software, and draft one defect per cause for an engineer to raise.
Why this is hard
- Scenario space is combinatorial. The agent must prioritise the cases that carry revenue or regulatory risk rather than list everything.
- Failure logs mix protocol-level detail with application messages. Grouping requires domain knowledge of charging result codes and session flows.
- A failure can be caused by a stale test, a data set, an environment or a defect. Saying which one, with evidence, is the whole job.
Value hypotheses to test
- Boundary and lifecycle cases that are usually written last, or never, are generated first.
- A failed run is explained once, by one person, instead of being investigated in parallel.
- Release decisions rest on known coverage and understood failures rather than on a pass rate alone.
Reproducible synthetic test
- inputs
- Primary P and member M share 1 GB. P suspended before M requests 100 MB. Requirement FAM-07 v2 blocks all members while P is suspended.
- assumptions
- State transition commits before request; no concurrent reservation in this fixture. Rejection consumes no bytes.
- expected
- M request rejected, shared balance remains 1,000,000,000 bytes. After authorised resume, identical request succeeds with 900,000,000 bytes left.
- boundary
- Test suspension during an open reservation, duplicate retries and member departure separately with agreed reservation-release rules; correlation alone is not root-cause proof.
- acceptance
- QA replays state and request logs; engineer confirms requirement version before changing assertions. Missing concurrency rules remain a release gap.
- Pilot measure
- Accepted test scenarios per hour of QA effort, time from a failed run to an agreed cause, and defects that escape to production.
- Connect
- Requirements, test repository, test results and logs, deployment and change records, charging configuration.
- Autonomy
- Prepare for approval. Drafted defect tickets that an engineer reviews and raises.
Release managers, delivery leads, product owners and auditors
Requirement-to-charging traceability
“Show me every requirement in this release that has no matching catalogue configuration or test.”
Today. Business requirements, solution designs, catalogue configuration, charging rules and test cases live in five tools with five naming conventions. Go/no-go decisions rely on a traceability matrix built by hand, which is out of date by the time it is presented.
Release R26.09, charging scope: trace the 31 requirements through design, configuration and test. List the breaks first.
Release Traceability Agentnow
Finding [measured] Twenty-six of thirty-one requirements trace end to end with evidence. Five have breaks, two of them revenue-bearing. [1]
REQ-118, rollover expires after one cycle [measured] Design s4.3 and balance type ROLL_DATA (validity one cycle) are present. No test asserts the expiry. Coverage gap, owner: QA. [1]
REQ-121, monthly spend cap of $100 [measured] Design s5.1 present. No spend-cap threshold found in the charging export for the affected plans. Configuration gap, owner: charging engineering. Regulatory dependency. [2]
REQ-127, family member leaves mid-cycle [measured] Configuration and tests reference design v2; the requirement was amended in v3 to return the member's share. Stale link, owner: solution design. [3]
Next Two further requirements have configuration and tests but no design section, which the audit standard treats as a documentation gap. Full matrix attached with links.
Sources[1] Requirements tracker, R26.09 (sample)[2] Design document R26.09 v3 (sample)[3] Catalogue export (sample)[4] Charging export CFG-2026-0901 (sample)[5] Test repository (sample)
Proposed workflow
- 1
Build the thread
Link each requirement to its design section, the catalogue and charging objects that implement it, and the tests that exercise it, using identifiers where they exist and evidence-backed matching where they do not.
- 2
Find the breaks
Report requirements with no configuration, configuration with no requirement, tests that never exercise a boundary value, and links that point to a superseded version.
- 3
Prepare the readiness view
Produce the traceability matrix with links to evidence, a gap list by owner, and a draft release note. The release manager reviews it with the delivery leads.
Why this is hard
- Artefacts are heterogeneous and rarely share identifiers. Matching by meaning must be shown, not assumed.
- Versions drift. A link that was correct at design sign-off can point at a superseded requirement by test time.
- The output must be defensible to an auditor, which means every link carries its evidence.
Value hypotheses to test
- Go/no-go decisions are made on a current view with evidence, not on a matrix assembled the night before.
- Coverage gaps are found while there is still time to fix them in the release.
- Audit preparation becomes a by-product of delivery rather than a separate exercise.
Reproducible synthetic test
- inputs
- REQ-121 v3 requires a $100 monthly cap. CFG-CAP v3 enforces it. TEST-CAP v2 stops at $99.99; expiry requirement has no test.
- assumptions
- Synthetic hard cap rejects any charge taking cumulative spend above $100; no partial charging; tax excluded. Trace only current requirement versions.
- expected
- At $99.99, a $0.01 event passes to $100; next $0.01 is rejected with balance unchanged. Matrix marks cap test stale and expiry test missing, not end-to-end verified.
- boundary
- At cycle reset spend is $0; test event ordering across reset and a missing configuration link. An inferred semantic link requires reviewer confirmation.
- acceptance
- Release manager requires current source/config/test links and executed boundary evidence for every critical requirement; unresolved cap or expiry gaps block launch.
- Pilot measure
- Time to a reviewed traceability view, confirmed coverage gaps found per release, and requirements verified with evidence before go-live.
- Connect
- Requirements tracker, design documents, catalogue exports, charging configuration, test repository, release records.
- Autonomy
- Read and prepare. The release manager owns the go/no-go decision.
Agree the pilot acceptance boundary.
Select one offer family and replay a frozen, expert-labelled fixture set against the manual baseline. Record median and p90 review time, accepted findings, false positives and escaped critical defects. Proposed gate: every monetary assertion reconciles and no known critical defect is missed; any access leak or unsupported tariff blocks expansion. Record reviewer decisions and actual results beside each test. Read and draft first. Employees approve any system write. The initial scope excludes autonomous changes to charging rules, billing, customer accounts and production systems. Benefit estimates follow measured results, with no assumed savings percentage.
- Access
- Enterprise SSO, source permissions and least-privilege tools.
- Evidence
- Citations, timestamps and clear uncertainty when evidence is incomplete.
- Approval
- Prepared actions are reviewed and submitted by an employee.
- Audit
- Require and verify records of the user, sources, tool calls, approver and result.
A focused pilot with a production decision
- Scope
- One team, one or two workflows, a baseline agreed before the pilot.
- Configure
- Connect approved sources and develop the agent.
- Evaluate
- Test correctness, access boundaries and user effort.
- Decide
- Expand only when agreed acceptance gates pass.
Take the full pack to your team.
The PDF contains all six synthetic charging workflows with the illustrative exchanges, the pilot measures and the guardrail model, formatted for internal circulation. We email you a link; each copy is marked for its recipient.
- Six charging and billing workflows with proposed steps
- Illustrative exchanges showing the expected output
- Systems to connect and the autonomy level for each case
- Pilot measures you can baseline before starting
- The guardrail and pilot requirements to agree before access
A working session
A ThirdEye pilot for your charging team.
Select the first workflow, confirm data access and agree the success measures. Agree the application and inference boundaries, source access and acceptance criteria before any pilot.