A metadata-driven product engineering platform for commodity trading & risk management systems
Gravitas Foundry provides a complete engineering platform for designing, governing, testing, extending, modernizing and upgrading enterprise trading platforms using canonical metadata instead of business code. This page documents the full architecture, capability by capability.
Gravitas Foundry provides a complete engineering platform for designing, governing, testing, extending, modernizing and upgrading enterprise trading platforms using canonical metadata instead of business code. That single sentence carries the whole architecture, so it is worth unpacking what it means in practice.
In a conventional trading estate, business behaviour lives in code. A validation rule is a method; a screen is a component; an API is a hand-written controller; the documentation describing all three is a separate artifact that was accurate on the day it was written. Because these are four different things maintained by four different mechanisms, they drift apart the moment anyone changes anything, and the drift is invisible until it causes an incident.
Foundry inverts that. There is one governed metadata repository, and business entities, capabilities, features, rules, API contracts, datasets, automation, execution evidence and governance all derive from it. Change the metadata and everything below it regenerates - consistently, and with an audit trail. Nothing has to be kept in sync by discipline, because nothing was separate to begin with.
A trading estate is described in four incompatible places at once: the code that runs it, the documentation that claims to describe it, the test suite that partially validates it, and the memories of the people who built it. None agrees with the others, and there is no mechanism that would make them agree. Every question worth asking - what does this do, what will this break, how do we know it works - therefore starts with an investigation.
Change one metadata definition and the affected features, contracts, tests and documents are identified and regenerated together, with an approval trail. In a conventional estate the same change means a developer, a doc ticket somebody will forget, a contract update the integration team learns about late, and a regression cycle scoped by guesswork.
The single largest avoidable cost in trading-platform delivery is starting from zero. The industry has implemented reference data, trade capture, lifecycle, position, valuation and settlement thousands of times, and every programme rebuilds them as if for the first time - specifying, building and testing capabilities that are, in their essentials, identical everywhere.
Customers receive a complete enterprise product instead. Fifteen modules arrive as production-ready business capabilities you configure and extend rather than invent. Each module below expands to show the business entities it holds, the capabilities it provides, the features underneath them, the estimated test-case coverage, and how much of that coverage is automated - so scope is a fact you can inspect rather than a promise you have to take on trust.
Business entities. Asset class, commodity, product, instrument, location, counterparty, portfolio, book, trader, currency, UOM, calendars, quality, benchmark
Capabilities. Create, modify, activate, deactivate, archive, restore, search, import, export - each governed and API-exposed
Features. Hierarchy maintenance, effective dating, cross-referencing, bulk import with validation, approval workflow
Business entities. Trade, trade leg, schedule, pricing formula, counterparty, book
Capabilities. Capture physical and financial trades across every desk, with validation and enrichment at entry
Features. Physical forward, swap, option, futures, spot, exchange, structured; templates and bulk entry
Business entities. Trade version, event, amendment, novation, termination
Capabilities. Confirm, amend, cancel, novate, terminate, exercise - every change an audited event
Features. State machine enforcement, maker-checker on amendments, full version history and replay
Business entities. Position, exposure, aggregation rule
Capabilities. Derive positions from trades as-of any date and book, netted and aggregated
Features. Real-time and end-of-day positions, netting rules, desk and portfolio roll-ups, blotter reconciliation
Business entities. Curve, valuation run, mark, model
Capabilities. Value positions against point-in-time curves; produce mark-to-market and attributed P&L
Features. Curve construction, seasonality, bitemporal point-in-time revaluation, P&L attribution
Business entities. Risk factor, scenario, limit, exposure
Capabilities. Compute and monitor market risk with scenarios, stress and limits
Features. VaR, sensitivities, stress scenarios, limit definition and breach workflow
Business entities. Counterparty, credit limit, exposure, collateral
Capabilities. Pre-deal and post-deal credit checks with exposure aggregation
Features. Credit limits, utilisation, pre-deal check, breach escalation, collateral positions
Business entities. Nomination, movement, contract, location
Capabilities. Plan and confirm physical movements against contracts
Features. Nominations, movement planning, actualisation, location and transport constraints
Business entities. Stock, location, movement, valuation
Capabilities. Track physical inventory positions and their valuation
Features. Stock by location and grade, movements in and out, inventory valuation and reconciliation
Business entities. Invoice, payment, settlement instruction, netting agreement
Capabilities. Take confirmed trades to settled cash with exceptions handled
Features. Invoice generation, payment netting, settlement instructions, exception repair queue
Business entities. Journal, ledger account, posting rule
Capabilities. Post trading activity to the general ledger with rules, not spreadsheets
Features. Posting rules, journal generation, reconciliation to sub-ledger, period close support
Business entities. Report definition, dataset, schedule, distribution
Capabilities. Define, generate and distribute regulatory and management reporting
Features. Report designer, scheduling, distribution, regulatory templates, evidence retention
Business entities. User, role, tenant, configuration, job
Capabilities. Run the platform: users, roles, tenants, configuration and jobs
Features. User and role management, tenant configuration, job scheduling, health monitoring
Business entities. User, role, permission, entitlement, audit record
Capabilities. Control and prove who can do what, everywhere
Features. RBAC, SSO, entitlements by entity and action, full audit trail
Business entities. Process, state, transition, approval, notification
Capabilities. Configure how work moves and who approves it - without code
Features. Maker-checker, approval chains, escalation, notifications, role-based routing
Every trading implementation rebuilds the same capabilities. Reference data, trade capture, lifecycle, position, valuation, settlement - these have been specified, built and tested thousands of times across the industry, and each new programme starts from an empty sandbox as if none of it had happened. The first year is spent reaching a baseline the industry reached decades ago.
A programme needs physical crude capture with regional validation. Rather than specifying and building trade capture, it starts from the Trade Capture module - 2,200 test cases already covering the standard behaviour - and adds the regional rule as metadata. The programme's real work is the rule, not the module.
Beneath the canonical product sits a canonical data model with the layering a serious estate needs. Raw data lands in bronze exactly as it arrived, is conformed to the canonical model in silver, and is served as business-ready marts in gold. The canonical layer itself is the governed business definition - the thing everything else agrees to mean the same way.
Every layer is versioned, described by metadata, and lineage-tracked, so any field can be traced back to where it came from and any past state can be reconstructed. And the model is extensible by design: your own entities are added as metadata and governed identically to the shipped ones, which is what keeps an extension an asset rather than a liability at the next upgrade.
In most trading estates the same business concept has three different shapes in three different systems, and a fourth in the warehouse. Nobody can say which is authoritative, so reconciliation becomes a permanent staffed function rather than an exception process, and every number that matters is argued about before it is used.
A commodity hierarchy differs subtly between the trading platform, the risk system and the warehouse - the same grade classified three ways. Mapped to the canonical model once, the difference becomes an explicit, versioned mapping rather than a recurring reconciliation break, and the lineage view shows exactly which system contributed which attribute.
The metadata repository is the platform's centre of gravity. Screens, forms, validation, business rules, menus, navigation, workflow, API contracts and reports are all defined here as governed configuration rather than compiled code.
The practical consequence is no-code configuration for the things that change most often, and upgrade-safety for the things you add. When a customization is a metadata definition against a canonical model rather than a fork of somebody's source, it can be carried across versions, and its impact on an upgrade can be analysed in advance rather than discovered in production.
When business behaviour lives in compiled code, every change - however small - is a development task, a release, and a regression cycle. Adding a required field to a trade screen for one desk can take a quarter. Worse, the change is invisible to everything except the code: the documentation, the API contract and the test pack all have to be updated separately, by different people, and they will not be.
A desk needs an additional mandatory field on physical crude capture, conditional on counterparty region. Traditionally: a change request, a developer, a release, a regression cycle. In Foundry: a metadata edit to the form and a cross-field rule, approved through maker-checker, with the impact analysis listing the affected screens, API contract, tests and documentation before it ships - and all of those regenerated from the same edit.
A business capability is a versioned unit of what the business does: capture a physical trade, confirm a trade, cancel a trade, approve a counterparty, maintain curves, maintain a product. Expressing the estate in these terms rather than in screens or tables is what lets business people and engineers talk about the same thing without translation.
Every capability is versioned, and every capability links to its features, test cases, automation, documentation, APIs and datasets. That linkage is the whole point: it means traceability from a business requirement to the running code and the passing evidence is a property of the repository, not a spreadsheet somebody maintains alongside it and updates when they remember.
The capability, its features, tests, automation, docs, APIs and datasets, versioned together.
Lifecycle behaviour with maker-checker, state transitions and full audit.
Governed reversal with evidence and downstream impact known in advance.
Reference-data governance with approval chain and entitlement checks.
Curve definition and versioning, bitemporal, feeding valuation deterministically.
Product definition as metadata, so a new product is configuration, not a project.
Business and engineering describe the same system in different languages. The business says 'we need to confirm trades faster'; engineering hears a ticket about a screen. Nothing in the estate holds the concept of a business capability as a first-class, versioned thing, so requirements are translated by hand at every hop and something is lost each time.
'Approve Counterparty' is a capability. Open it and you see its features, the 40 test cases that validate it, which of those are automated, the API contract that exposes it, the datasets that exercise it, its generated documentation, and the approval history of every change to it - in one place, derived from one definition.
The feature repository holds the level below capabilities: what a capability actually does, in enough detail to test it. Its structure is a strict hierarchy - module, business entity, capability, feature, test cases, automation, evidence - and each level links to the next.
That hierarchy is what makes the estate searchable rather than tribal. A question like "what does trade capture for crude oil physical forwards cover, and how do we know it works?" resolves to a path through the repository ending in test cases and their evidence, instead of a meeting with the three people who remember.
Trade Capture → Crude Oil → Capture Physical Forward → 200 test cases
Ask a trading organization what its platform actually does and there is no answer that is both complete and current. The knowledge is distributed across a requirements repository that stopped being maintained, a test suite whose names are cryptic, and the memories of people who may be on holiday or on their notice period. Scoping any change therefore starts with an investigation.
A regulator asks how physical crude forwards are validated at capture. The path resolves in seconds: Trade Capture → Crude Oil → Capture Physical Forward → its features, its 200 test cases, which are automated, and the last execution evidence for each. No investigation, no meeting.
Reference data is where trading estates quietly go wrong. When asset class, commodity, product, instrument, location, counterparty, portfolio, book, trader, currency, unit of measure, calendars, quality and benchmark each mean subtly different things in three systems, every downstream number becomes an argument.
Foundry models the full hierarchy once. Every entity carries the same governed lifecycle capabilities - create, modify, activate, deactivate, archive, restore, search, import and export - each with approval workflow and each exposed through an API, so the same definition serves the screen, the integration and the report.
Bad static data is the root of a surprising share of trading incidents, and it is almost never caught where it is created. A counterparty set up with the wrong legal entity, a calendar missing a regional holiday, a unit of measure that disagrees between two systems - none of these throw an error. They produce a clean, wrong number, discovered days later by someone reconciling.
A new counterparty is onboarded. The approval chain requires credit and legal sign-off before it can be traded against; the API refuses to accept a trade referencing it until it is active; the audit trail records who approved what and when. The same rules apply whether it was created on a screen, through an integration, or in a bulk import of two hundred.
Trading organizations run on approvals. Who can book, who must check, what escalates when a limit is breached, who signs off a reserve - these are business decisions that change with the org chart and the regulator, and they should never require a release to change.
The workflow engine expresses them as metadata: maker-checker, approval chains, lifecycle state machines, escalation paths, notifications and role-based routing, all configured rather than coded, and all versioned and audited like everything else in the repository.
Approval logic is business policy, but in most systems it is code. So when the regulator changes a requirement, or the org chart changes, or a desk is given a different limit authority, the change needs a developer and a release. In the meantime, the gap is filled by email and spreadsheets - which is exactly the evidence an auditor will not accept.
A limit breach on a power desk must escalate to the regional head above a threshold, and to the CRO above a larger one, with a four-hour SLA before it escalates again. That is three metadata rules and a notification configuration - approved, versioned, and effective without a release.
The rules engine is where the no-hardcoding principle earns its keep. Validation, eligibility, required fields, cross-field constraints, approval thresholds and calculation rules are all metadata definitions.
This matters for two reasons beyond convenience. First, a rule you can read is a rule you can audit - a regulator asking why a trade was accepted gets a definition, not a code walkthrough. Second, a rule in metadata participates in the dependency graph, so when it changes, the impact analysis knows which features, tests and reports are affected.
Defined, versioned and approved like every other artifact.
Field and record-level checks at entry, before bad data spreads.
What is permitted, for whom, under which conditions.
Conditional requirements that vary by product, desk or counterparty.
Constraints between fields that no single-field check can catch.
Thresholds and chains that decide who must sign.
Derived values expressed once and reused everywhere.
A validation rule buried in code is invisible to everyone except the person reading that file. The business cannot confirm it matches policy, QA cannot see it to test it, audit cannot review it, and the impact analysis cannot know it exists. When it is wrong, the first symptom is a trade that should have been rejected sitting in the book.
A regulator asks why a trade breaching an internal limit was accepted. Instead of a developer reading source in a meeting, the rule is opened: its definition, its version history, who approved the change that raised the threshold, and the date it became effective. That is a five-minute answer instead of a five-day investigation.
Every feature automatically documents its contract: endpoint, authentication, headers, parameters, payload, response, errors, version and worked examples. Because the contract is generated from the same metadata that defines the feature, it cannot describe behaviour the system does not have.
OpenAPI support means those contracts drop straight into the tooling your teams already use - client generation, contract testing, gateways and portals - rather than living in a document that says it is authoritative and is not.
Hand-written API documentation is wrong within a quarter. The integration team builds against the document, the behaviour has moved on, and the defect surfaces in UAT - or worse, in production, in a downstream system nobody realised was consuming that endpoint. Every organization knows this and every organization does it anyway, because keeping docs current by discipline does not scale.
A payload gains a conditional field. The contract regenerates, the OpenAPI spec updates, the impact analysis lists the three consuming integrations and the contract tests that must be re-run - all from the single metadata edit that introduced the field.
Testing is slow in most trading organizations for a boring reason: nobody can get realistic data safely. Production is sensitive, anonymization is a project, and synthetic data made by hand does not exercise the cases that actually break.
The dataset repository holds reusable business datasets, representative production datasets, anonymized production data and synthetically generated data, all versioned and shareable across teams and programmes. A dataset is an asset with a version, not an attachment on a ticket.
Curated sets that exercise real business scenarios, shared across programmes.
Shaped like the real thing, so tests hit the cases that actually occur.
The realism of production without the exposure.
Coverage for the edge cases production has not produced yet.
A test result is meaningless unless you know which data produced it.
Built once, used by every team that needs the same scenario.
Ask why a test environment is not usable and the answer is almost always data. Production data is sensitive and cannot be copied; anonymizing it is a project nobody funded; hand-made test data covers the happy path and nothing else. So testing either waits, or runs against data that does not resemble the cases that actually break.
A regression pack for physical crude settlement needs six months of realistic movements across four locations. Rather than a copy of production or a hand-built spreadsheet, it draws a versioned, anonymized dataset from the repository - the same one the migration team is validating against, so their results are comparable.
Automation in Foundry is not a folder of scripts that someone maintains until they leave. Each automated test is tied to the feature and capability it validates, so coverage is a queryable fact and an orphaned test is visible rather than quietly rotting.
The layers are deliberate: browser automation for screens, REST for contracts, SQL for state, JSON assertions for payloads, plus performance, security, smoke and full regression. Every run leaves evidence attached to what it proved.
Most automation suites decay. They are written during a project, maintained by whoever cares, and abandoned when that person moves on. Within a year a meaningful share is skipped, flaky or testing behaviour that no longer exists - and nobody can tell which, because the tests are not connected to the features they were meant to prove.
A capability's coverage view shows 200 test cases, 168 automated, last executed against a named dataset version with evidence attached - and flags the 32 that remain manual so the gap is a decision rather than a surprise.
Quality engineering is where the platform pays for itself fastest, because regression is where trading programmes quietly lose their budget. Planned by hand, executed by hand, and re-derived from scratch every release, the cost of proving nothing broke routinely exceeds the cost of the change itself.
Foundry holds a canonical test repository tied to the capabilities each test validates, with test design, generated automation, execution, reporting, coverage and evidence in one place. Regression packs are canonical rather than reinvented, and - because the dependency graph is explicit - tests can be selected by impact rather than run exhaustively.
That single change in approach is what turns regression from a fixed tax on every release into a variable cost proportional to what actually changed.
Scenarios that live with the capabilities they validate, not in a silo.
Coverage designed against features and rules, not invented per release.
Generated and tied to the feature it proves.
Runs, results and coverage in one place.
Proof attached to the capability, ready for audit.
Run what the change affected, not everything, every time.
Regression is the largest hidden cost in trading-platform delivery. Because nobody can say what a change affects, the only safe answer is to test everything - so a two-day change carries a six-week regression cycle. The effort is re-derived from scratch every release, and the suite that results is thrown away rather than becoming an asset.
A rule change touches three features. Impact analysis identifies 240 affected test cases out of a suite of 14,000. Those 240 run, evidence attaches to the three capabilities, and the release certifies in hours rather than the weeks a full-suite run would have taken - with better assurance, because the tests that ran were the ones that mattered.
Modernization stalls for a reason that has nothing to do with technology: nobody can describe the legacy system precisely enough to leave it. The knowledge is distributed across customizations written years ago, spreadsheets maintained by three people, and partners who have moved on.
Migration engineering makes description a machine task. The workflow is deliberate and each step produces evidence, so the migration can be defended to an auditor rather than merely asserted to a steering committee. And once the canonical mapping exists it keeps paying - it is the same map that makes later upgrade impact analysis possible.
Modernization programmes fail at the description step, not the technology step. The legacy platform's real behaviour lives in customizations written years ago by people who have left, in spreadsheets maintained by three people, and in partner knowledge that was never transferred. Without a precise description there is no safe target state, so the programme either stalls or proceeds on assumptions that surface as defects after cutover.
A twelve-year-old CTRM holds 400 customizations nobody has catalogued. Discovery produces the inventory; mapping expresses it against canonical; the gaps - the genuinely bespoke behaviour worth keeping - are isolated from the 80 percent that is standard capability implemented locally. The programme's scope becomes a fact instead of an estimate.
Every upgrade begins with the same question - what will this break? - and normally that question has no reliable answer. So the programme buys certainty the only way it can: months of manual regression and a long stabilisation window after go-live. The cost is not the upgrade. The cost is the uncertainty.
Foundry answers it structurally. The current platform's metadata is discovered and mapped to canonical, versions are compared against that map, and impact analysis walks the dependency graph to return exactly what is affected. The affected assets are then regenerated from metadata rather than rewritten, regression is targeted at what actually changed, evidence is captured automatically, and the release is certified through governed sign-off.
An upgrade's cost is dominated by uncertainty rather than by work. Nobody can enumerate what a version change touches, so the programme protects itself with exhaustive manual regression and a long stabilisation window - and still discovers surprises in production, because exhaustive testing of an undescribed system is not actually exhaustive.
A platform upgrade spans two versions. Impact analysis reports 47 affected capabilities, 1,900 affected test cases and 12 affected integrations - out of a much larger estate. The programme plans against that list on day one, rather than discovering it across four months of regression and a difficult month after go-live.
Impact analysis is the capability everything else enables. Because the metadata encodes an explicit dependency graph, a single proposed change reports the affected features, APIs, tests, SQL, reports, documentation, screens, workflows and integrations.
The value is entirely in the timing. Every organization eventually learns what a change affected - usually in production, at cost. Foundry moves that discovery to before deployment, while the information is still cheap to act on.
Every organization eventually learns what a change affected. The only question is when, and at what price. Without an explicit dependency graph, that learning happens in UAT if you are lucky and in production if you are not - and by then the cost of the discovery is many multiples of what it would have been at design time.
Someone proposes changing a unit-of-measure conversion. The graph returns: 9 features, 3 API contracts and their consumers, 310 test cases, 14 SQL assertions, 6 reports, 2 workflows and the documentation for each. What looked like a one-line change is correctly scoped before anyone commits to a date.
Documentation in enterprise software has a predictable lifecycle: accurate at go-live, approximately right for a quarter, actively misleading within a year, and quietly distrusted forever after. The cause is structural - it is maintained by a different mechanism than the system it describes.
Foundry generates functional specifications, technical specifications, API documentation, test documentation, release notes, user guides, admin guides and architecture documentation from the metadata that runs the platform. It cannot describe a rule the system does not have, because it is derived from the same definition.
Documentation drifts because it is maintained by a different mechanism than the system it describes. No amount of process fixes a structural problem: as long as the document and the behaviour are two separate artifacts updated by two separate acts of will, they will diverge, and the organization will learn to distrust the document.
A rule changes. The functional spec, the API documentation, the test documentation and the release note all regenerate from that single edit. Nobody was assigned a documentation ticket, and no document is now quietly wrong.
Generation is only as good as its grounding. A model asked to write test cases from a blank prompt produces plausible fiction; a model working from metadata that already describes the entities, capabilities, rules and contracts of a real trading platform produces assets a team can use. Foundry's repository is exactly that grounding.
From it, Foundry generates features, test cases, automation, documentation, SQL assertions, API payloads, migration mappings and regression packs. It also uses AI defensively rather than only generatively: duplicate detection surfaces where the estate describes the same capability three times under different names, and coverage analysis shows where a capability carries no meaningful test. Those two findings are usually worth more than any amount of new generated content, because they show where the risk is hiding.
One boundary is deliberate: AI generates artifacts, it does not make governance decisions. Approvals stay human and audited.
Drafted from the capabilities and entities already described.
Coverage proposed against real rules, not imagined ones.
Executable tests tied to the feature they prove.
Specs, API docs and release notes from live metadata.
State checks derived from the canonical model.
Valid examples straight from the contract.
Legacy-to-canonical proposals from discovered metadata.
Targeted suites assembled from the impact graph.
Where the estate says the same thing three ways.
Where a capability has no meaningful test.
AI in enterprise engineering usually disappoints for one reason: it is asked to generate from nothing. A model with no grounding produces confident, plausible artifacts that do not match the system - test cases for rules that do not exist, documentation for behaviour nobody implemented. The output looks impressive in a demo and creates cleanup work in reality.
Asked to generate a regression pack for an upgrade, Foundry works from the impact analysis and the existing test repository - producing targeted cases for the affected features, flagging three capabilities where the change lands but coverage is thin, and routing every generated case through review before it enters the canonical repository.
Trading platforms are audited, which means evidence cannot be produced retrospectively by whoever is free that week. Foundry treats governance as a property of the repository rather than a process laid over it.
Every artifact is versioned. Every change moves through maker-checker approval with a full audit trail. Change history, dependency tracking and electronic sign-off apply uniformly across capabilities, features, rules, contracts, datasets, tests and documentation, so the same discipline covers the business definition and the implementation. The result is a traceability chain - capability, feature, test, evidence, approval - generated as a by-product of working rather than assembled in a panic before a review.
In most organizations, evidence is produced retrospectively. An audit is announced, and a team spends three weeks reconstructing who approved what, why a change was made, and how anyone knew it worked. The reconstruction is expensive, incomplete, and - because it is a reconstruction - not really evidence at all.
An auditor asks how a specific settlement rule came to be, who authorised it, how it was tested and what evidence exists. Every element of that answer is already in the repository, versioned and linked - the capability, the rule, its approval, its tests and their last execution evidence. The answer takes minutes.
Security in a platform that describes an entire trading estate is not a feature, it is a precondition. Access is role-based across every repository, authentication is SSO with OAuth and JWT, and tenants are strictly isolated so multiple business units, regions or programmes can share an instance without leaking into one another.
Beyond access, the controls are the ones an enterprise security review expects: API security, full audit of every change, encryption in transit and at rest, and managed secrets rather than credentials in configuration files.
A platform that describes an entire trading estate is, by definition, a concentration of highly sensitive information: positions, counterparties, pricing logic, limits. It is therefore a target, and it will face an enterprise security review before it is allowed anywhere near production data.
A regional business unit runs its own programme on the shared instance. Its users authenticate through the corporate directory, see only their tenant's capabilities and data, and every access is audited. A user moving between business units gains and loses entitlements automatically, because entitlement follows directory group rather than a manual grant.
Foundry is deliberately non-invasive. It connects to the trading platform you already run rather than asking you to replace it, reading metadata through databases and APIs to describe what is there without requiring changes to it.
It reads and feeds the data platforms you already run, so datasets, evidence and generated artifacts land where your analytics already live. And it plugs into the engineering toolchain your teams work in daily, so generated automation, contracts and documentation flow into source control and the work it identifies lands in the backlog - rather than arriving as another portal somebody has to remember to check.
Any tool that requires you to replace a working trading platform before it can help you is not a tool, it is a programme - and it will not get approved. The systems that run trading are load-bearing; the realistic starting point is always the estate that exists, not the one an architecture diagram wishes existed.
A Foundry engagement on an incumbent platform starts read-only against a database replica. Within the first pass it has discovered the metadata, produced a canonical mapping, and pushed the generated contracts and automation into the team's existing repository - with no change to the trading platform at all.
Read the architecture from the bottom up and the design intent is obvious. Governance and security sit underneath everything, because in a regulated estate they are not optional. Above them, the repositories hold what the platform knows: datasets, tests, automation, documentation. The canonical product and data model sit at the centre as the shared definition. The metadata repository is the single source of truth that everything above derives from.
Above that, the rules and workflow engines interpret metadata rather than embedding logic, the API layer publishes generated contracts, and the presentation layer renders metadata-driven screens. No layer hardcodes what a layer below already describes, which is the property that keeps the whole thing coherent as it changes.
And the whole loop, viewed as work rather than as layers, runs from a business requirement through to continuous improvement:
Foundry is licensed as an enterprise platform. In practice it is scoped alongside a defined programme - an implementation, an upgrade, or a modernization - and then retained as the engineering foundation for continuous change, because the canonical mapping it builds is what makes every subsequent change cheaper than the last.
Pricing depends on the size of the estate and the scope of what you want described and governed, which is why it starts with an architecture workshop rather than a rate card. That workshop is also where we agree the baseline measures - how long a change takes today, what proportion of a release is regression effort, how much of the estate is described in the system - so any improvement is measured against your own numbers rather than asserted from someone else's case study.
Enterprise platform pricing usually asks you to commit before anyone knows the scope. The vendor quotes against a reference architecture, the buyer discovers their estate is nothing like it, and the difference becomes a change request. Both sides then spend the engagement arguing about scope instead of doing the work.
An organization scopes Foundry around a specific upgrade. The workshop establishes that regression is currently about half the release effort, and agrees that as the baseline. After the first upgrade the comparison is against their own prior release, on their own estate - a number they can defend internally rather than a vendor claim.
It is a metadata-driven product engineering platform for commodity trading and risk systems. Rather than running your trading business, it is the platform you use to build, extend, validate, govern, modernize and upgrade the systems that do. Everything it holds - business capabilities, features, rules, API contracts, datasets, tests, automation and documentation - originates from one governed metadata repository.
No. Foundry sits alongside the trading platform you already run. It connects to it, discovers its metadata, maps it to a canonical business model, and gives you impact analysis, generated documentation and regression assets around it. Your ETRM keeps trading; Foundry makes changing it safe and fast.
It means the behaviour of the system - screens, forms, validation, business rules, menus, navigation, workflow, API contracts and reports - is defined as governed, versioned configuration rather than compiled code. A change is an approved metadata edit, and everything derived from that metadata (documentation, contracts, tests) regenerates consistently.
A template gives you a starting shape you then diverge from, and the divergence is what makes upgrades painful. The canonical product is a living model: your extensions are expressed as metadata against it, so they remain connected to it and can be carried across versions with their impact analysed rather than discovered.
A versioned unit of business behaviour - 'Capture Physical Trade', 'Confirm Trade', 'Approve Counterparty', 'Maintain Curves'. Each links to its features, test cases, automation, documentation, APIs and datasets, which is what makes traceability structural rather than a document somebody maintains.
Yes. The canonical model is a foundation, not a straitjacket. You add your own entities, capabilities and rules as metadata, and they are governed, versioned and upgrade-aware exactly like the shipped ones.
The metadata encodes an explicit dependency graph. When you propose a change - or compare two platform versions - the graph is walked to report the affected features, APIs, tests, SQL, reports, documentation, screens, workflows and integrations. Crucially, that report exists before deployment.
Reusable business datasets, representative production data, anonymized production extracts and synthetically generated data, all versioned and shareable. It exists to remove the most common reason testing is slow: nobody could get realistic data safely.
Browser automation for screens, REST for API contracts, SQL for state assertions, JSON assertions for payloads, plus performance, security, smoke and full regression suites. Each run leaves execution evidence attached to the capability it validates.
Instead of running an entire regression suite on the assumption that anything might have broken, tests are selected by what the dependency graph says was actually affected. That converts regression from a fixed tax on every release into a variable cost proportional to the change.
A governed workflow: discover what the legacy platform contains, extract it, map it to the canonical model, transform, validate, load, reconcile against the source, and certify with evidence. Each step is auditable, so a migration can be defended rather than merely asserted.
Discover the current platform's metadata, map it to canonical, compare versions, analyse impact, identify affected features, APIs, tests, reports and documentation, regenerate those assets from metadata, execute targeted regression, capture evidence and certify for production.
Functional and technical specifications, API documentation, test documentation, release notes, user and admin guides, and architecture documentation - all generated from the same metadata that runs the system, so they cannot silently drift from reality.
AI generates features, test cases, automation, documentation, SQL assertions, API payloads, migration mappings and regression packs - grounded in real metadata rather than a blank prompt. It also runs duplicate detection and coverage analysis. It does not make governance decisions: approvals remain human and audited.
Versioning, audit, approvals, maker-checker, dependency tracking, change history, electronic sign-off and compliance reporting, applied uniformly to every artifact from business capability to test evidence.
Role-based access control, SSO with OAuth and JWT, strict tenant isolation, API security, full audit, encryption in transit and at rest, and managed secrets.
Yes, with strict tenant isolation, so an enterprise can run multiple business units, regions or programmes on one instance without data leaking between them.
Trading platforms including Openlink Endur, Allegro, RightAngle, AspectCTRM, TriplePoint and SAP IS-Oil; databases including Oracle, PostgreSQL, SQL Server and ClickHouse; data platforms including Snowflake and Databricks; and toolchains including Azure DevOps, GitHub, GitLab, Jenkins and Jira.
Through its databases and APIs, read-first. Discovery is designed to be non-invasive: it describes what is there without requiring changes to the system it is describing.
Yes. Modules, entities, capabilities, features, datasets, documentation, API contracts and test cases are all indexed, so the estate is browsable rather than tribal knowledge.
As an enterprise platform, typically scoped alongside a defined programme - an implementation, an upgrade, or a modernization - and then retained as the engineering foundation for continuous change. Pricing depends on estate size and scope, and starts with an architecture workshop rather than a price list.
It depends on the size of the estate and the goal: a single upgrade programme is a different scope from an enterprise modernization. The first step is a short architecture workshop that sizes it honestly against your platform and data.
Read access to a representative slice of the current platform, someone who knows the business domain, and a real proposed change to run the impact analysis against. That is enough to see the canonical mapping and generated assets on your own system.
CIOs and CTOs, enterprise and solution architects, ETRM product owners, QA and delivery managers, engineering managers, and the implementation teams working on Endur, Allegro, RightAngle and similar platforms.
Move from custom engineering to metadata-driven product engineering, on the trading estate you already have.