Database-enforced isolation
Tables carry tenant_id and PostgreSQL row-level-security policies. Isolation is enforced in the database rather than relying only on application query filters.
Home / Taranga BSS architecture
ARCHITECTURE
Composable services.
Governed execution.
Explore Taranga BSS service boundaries, tenant isolation, standards-based interfaces and AI controls—and the engineering evidence and deployment responsibilities behind them.
Opens an editable email draft. No request is sent or meeting reserved.
ONE AI-NATIVE COMMERCIAL CORE
01
Run
Simplify operations. Automate commercial processes.
02
Grow
Launch offers faster. Unlock new revenue.
03
Learn
Measure what works. Improve every decision.
START WITH ONE USE CASE. EXPAND WITH RESULTS.
A readable model of the platform.
Channels access the commercial core through the API gateway. Domain services own their databases; events connect activity, and adapters define the boundaries with external providers.
Channels
Storefronts, apps, self-service, care and operator or partner experiences.
API gateway
Shared entry point and hostname-based tenant routing.
Domain services and databases
Commerce · Customer · Revenue · Service and network · Growth · Platform. Each service owns its database.
External providers
Connectivity, network/OSS, charging, payments, finance and other vendor-specific systems.
Identity and access controls
Per-tenant issuers and component-level token validation; database row-level security enforces tenant isolation.
Events and governed AI
Events and transactional outbox support data flows. The operational ontology, permissions and approvals govern AI actions.
Independent services. Explicit ownership.
Each component is independently deployable and owns its database. A shared API gateway provides access to the commercial core.
Shared business meaning does not require centralising all data ownership. During coexistence, define one logical master for each domain, with explicit write authority, reconciliation and operational responsibility.
FROM COMMERCIAL INTENT TO DELIVERY
Connected catalogues. Clear ownership.
Connect what the customer buys with the service definitions and fulfilment steps needed to deliver it. This is a logical relationship across capabilities, not a requirement to put every catalogue or every system’s data in one database.
01 / Product & offering definitions
Define the proposition: products, configurable options, bundles and their commercial terms. Pricing, promotions and eligibility describe how the offer can be sold.
Explore Product & Offerings →02 / Customer channels & orders
Present the proposition in Taranga-delivered or existing channels. Carry the selected offer and options into the agreed order workflow.
Explore Customer Channels →03 / Service definitions & fulfilment
Map the commercial order to the service specifications and fulfilment responsibilities needed for the selected use case. Define interfaces with network and wholesale providers.
Read the flow from product and offering definitions, through customer channels and orders, to service definitions and fulfilment. Catalogue definitions describe what can be offered or delivered; inventory records the products and services a customer actually has. Ordering and orchestration coordinate execution.
During coexistence, agree which system owns each definition, the mapping between product and service specifications, write authority, validation, reconciliation and failure handling. External charging remains a separate solution, with charging-to-billing data flows and operational ownership agreed for the deployment.
TM Forum Open APIs provide standard interface contracts. Integration still depends on the selected API versions, mappings, extensions and adapters. Conformance evidence applies to the tested scope; standard interfaces alone do not guarantee end-to-end interoperability.
Standards are the interface contract.
TM Forum Open API payloads remain standard on the wire, with Taranga-specific fields added as extensions. Conformance is assessed using TM Forum Conformance Test Kits.
Conformance evidence relates to the tested dataset and execution date; it is not continuously re-run. API coverage, versions and formal certification status should be established from the applicable evidence.
Tenant isolation enforced in the database.
Every table carries a tenant identifier with a PostgreSQL row-level-security policy. Each tenant has its own identity issuer; tokens are validated in every component, not only at the gateway. Machine credentials are issued for that tenant alone.
An identity issuer per tenant
Tokens are validated in each component, not only at the gateway. Tenant machine credentials are issued per operator.
Hostname-based routing
The gateway identifies the tenant from the hostname so an anonymous visitor can reach the appropriate storefront.
ONTOLOGY & AI CONTEXT
Shared meaning behind AI-assisted work.
The operational ontology models commercial concepts and relationships. Connect that context with registered actions, permissions and approvals, while keeping governance and execution responsibilities distinct.
AI proposes. A person decides. Actions leave receipts.
Software agents act through registered actions declaring typed inputs, executable preconditions, role permissions and approval requirements. Every execution writes a receipt, and outcomes are captured for assessment.
- Typed actions and preconditions
Governed actions declare typed inputs, executable preconditions and role permissions.
- Approval and accountability
Approval requirements control execution. Each execution leaves a receipt, and outcomes are captured for assessment.
- Data handling for model calls
Before prompts leave the process, supported sensitive-data patterns are replaced with reversible placeholders: email, phone, IBAN, account, ICCID, IMEI, card, national identifier and labelled address. Callers receive restored values. Every model call is metered and logged.
AI WORKFORCE
See governed operational work in practice.
Explore the AI Workforce care example and the relationship between worker identity, task permissions, escalation and human decisions. Validate the supported actions and operating controls for your use case.
258 automated browser suites test the running system.
The suites drive real browsers against the running BSS fleet through the gateway with real sign-ins, rather than mocks. An architecture ratchet constrains structural debt, and a BSS repository claims gate checks documented numbers and versions against code.
Technical snapshot: 7 October 2026. The BSS claims gate validates BSS documentation; this marketing website is separately maintained. Request the relevant run reports and release evidence when evaluating a deployment.
Test and claims checks
A claims gate checks documentation against code. Structural-debt checks constrain changes in each service.
Pull-request security checks
CodeQL, dependency review, secret checks and row-level-security tests against a live database form part of the described CI controls.
Delivery artefacts
Images include CycloneDX software bills of materials, vulnerability scans, keyless cosign signatures and build-provenance attestations.
Taranga BSS technology stack.
This stack describes the BSS product, separate from the marketing website and Sanity editor.
- Runtime
Java and Spring Boot, with Spring Security multi-issuer resource-server support.
- Data and events
PostgreSQL, Flyway migrations and Apache Kafka with a transactional outbox.
- Identity
OpenID Connect. Keycloak is the development identity provider, not a prescribed production choice.
- Product interfaces and testing
React and Vite, a server-rendered public shop, and Playwright browser tests.
- Delivery
Docker, Helm, Terraform and GitHub Actions.
Deployment boundaries you can evaluate.
Vendor-specific charging, field service, national registry and payment integrations use an adapter per vendor. Development stand-ins do not establish production integration support; production deployments supply the real adapters.
Agree the production identity provider, data and tenant boundaries, selected API coverage, provider dependencies and operational responsibilities for the deployment.
CHANNELS & CHARGING
Channels and charging: explicit ownership.
Use Taranga-delivered customer channels, connect existing customer experiences or combine both through the commercial interfaces. Charging is an external integration: select a lightweight open-source charging solution or retain the operator’s existing charging platform.
Define authority, interface coverage, charging-to-billing data flows, reconciliation and operational ownership. Charging is not developed or delivered by Taranga; the selected solution’s licence and integration requirements apply.
SOVEREIGN DEPLOYMENT
Sovereign deployment, with a defined operating boundary.
A sovereign Taranga deployment brings platform hosting, data handling and operational access within an agreed national boundary. Define the complete operating arrangement before deployment, including external services and who can administer or support the platform.
- Hosting and data
Agree the location and ownership of infrastructure, application data, backups and disaster-recovery environments.
- Operations and access
Define administrator identity, privileged access, encryption-key responsibility and where administration, monitoring and support take place.
- AI and external services
Assess AI inference, external APIs, telemetry, licence validation and integrations. Confirm which dependencies remain within the boundary and document any exceptions.
- Evidence and acceptance
Validate the agreed arrangement through deployment records, data-flow documentation, dependency review and operational access checks. Requirements and responsibilities are project-specific.
The sovereign deployment scope is agreed and validated for each project, including AI services, external integrations and support access.
Explore sovereign deployment options
Opens an editable email draft. No request is sent or meeting reserved.
Start with a concrete integration discussion.
Bring the selected business scope, current authoritative systems and partner dependencies. Together we can identify the interfaces and ownership decisions to validate.
YOUR NEXT MOVE
Let’s start with your business.
Tell us what you want to change, launch or bring to your customers.
Request a meeting or demo
Opens your email application.