Next Release

The following changes have occurred to the open metadata types.

• New entity type called DataQualityRule, a subtype of GovernanceRule, describes a check on the quality of data in the terms used by data contract standards (quality dimension, check type, metric, severity, business impact, schedule, comparison operator and threshold values).
• DataField has three new attributes: allowsDuplicateValues, isPartitionKey and partitionKeyPosition. They record constraints and organization intent from a data specification, ready for when the implementing schema is catalogued.
• The PrimaryKey classification may now be attached to a DataField as well as a RelationalColumn.
• End 1 of the ContactThrough relationship is now Referenceable rather than ActorProfile, so that, for example, digital products and data sharing agreements can record their support channels.
• New classification called Promise marks an element whose real-world digital resource has not yet been delivered. Like Memento at the other end of an element's life, a promised element is only returned to lineage requests (forLineage=true), so a lineage graph can be designed ahead of the resources it describes without them appearing in ordinary catalog queries. It is managed through the Classification Explorer API, see Promise.
• SolutionComponent has two new attributes, deploymentStatus and userDefinedDeploymentStatus, recording how far the implementation of the component has progressed.
• The LineageRelationship, the common root of the lineage relationships, is now multi-link. Each lineage relationship carries the iscQualifiedName of the information supply chain it belongs to. Where several information supply chains make use of the same dependency, there needs to be a separate relationship for each of them, so multiple lineage relationships between the same two elements are now permitted. For the same reason, DataSetContent, DataMapping and DigitalProductDependency are now multi-link, and the 6.1 change that made SolutionLinkingWire multi-link, which had not taken effect, is applied by a new patch.
• The Exception relationship has three new attributes: affectedClassifications, affectedElements and affectedRelationships. The non-compliance that an exception reports is often not with the element it is attached to but with something attached to that element, so these attributes allow the exception to hang off the anchor element and still name exactly which of its anchored elements, classifications or relationships are affected.
• New relationship called ResourceConnection links any Referenceable to a Connection, so that elements that are not assets, such as a SoftwareCapability, can describe how a connector reaches their digital resource. AssetConnection is now a deprecated subtype of ResourceConnection, so existing relationships keep working.
• New subtypes of GovernanceActionProcess - AnalyticalActionProcess, CataloguingActionProcess, ExploringActionProcess, SurveyingActionProcess, ProvisioningActionProcess, DeletingActionProcess and SubscribingActionProcess - classify governance action processes by their purpose. The content packs now use them.
• New classification called RunMetrics records the run and failure counts, run times, duration, and rows and bytes read and written by a Process or a GovernanceActionProcessStep.
• New classification called Investigation marks a project that is being conducted to answer a question or seek out information.
• New classification called NamingStandardsVocabulary marks a glossary that holds the terms used in naming standards.
• DataScope and DataLens have four new attributes: dataValidityStartTime, dataValidityEndTime, dataCoverageStartTime and dataCoverageEndTime.
• Ownership has a new additionalProperties attribute.
• New survey annotation types called ContributorAnalysisAnnotation and CodeAnalysisAnnotation describe the activity around, and the content of, a software source code repository.
• New types describing software development - GeneratedTarget, ReusableTechnique, ReusableTechniqueUse, SoftwareComponent, SoftwareModule, RunnableSoftwareComponent, DependentSoftwareComponent and SoftwareSource - see 0280, 0281 and 0282.
• Other new attributes: embeddedMetadata on DocumentStore and MediaCollection; securityRoles on SecurityListMembership; displayName, description, externalEndpointAddresses and internalEndpointAddresses on NetworkGatewayLink.
• On NotificationType, notificationInterval is deprecated in favour of minimumNotificationInterval (in minutes) and nextScheduledNotification. The ContentStatus enumeration has a new value, OBSOLETE.
• New ResourceUse valid values called Naming Standards and Bitol Document.
• Every type in the open metadata type system has been compared with its documentation and the drift resolved - see the Changes to the open metadata types entry in the upgrade notes below.

Egeria can now exchange data contracts and data product descriptors with the teams that keep them in git, using the Bitol open standards. See digital product management for the mapping to open metadata.

• The Open Integration Framework (OIF) provides beans for both document kinds, a YAML/JSON formatter, mappers and generators between the documents and open metadata, and a listener mechanism in the integration daemon that mirrors its Open Lineage support. Documents can also be published to an integration daemon through its REST API.
• The new Bitol Content Pack supplies six integration connectors: receivers for file directories (such as a git checkout) and Apache Kafka topics, cataloguers that turn ODCS documents into data sharing agreements and ODPS documents into digital products, a publisher that generates the documents from the digital products and agreements in open metadata, and a file store that writes them out ready to commit. The connectors are enabled in the default servers.
• The Product Manager API can publish documents to an integration daemon, import them directly, and generate the ODPS document for a digital product or the ODCS document for a data sharing agreement.
• The Solution Architect API now supports the definition and retrieval of solution ports, which are used to represent the input and output ports of a data product.
• Sample ODPS and ODCS documents for the Coco Pharmaceuticals clinical trial are included with the sample data, and a new functional verification test suite (bitol-fvt) exercises the whole chain.
• The document files themselves are catalogued as data assets from the YAML and JSON file templates, with deployed implementation types that identify ODCS and ODPS documents in either format, and linked to the agreement or product catalogued from them as a Bitol Document resource.
• The vocabularies of the standards (quality check types, metrics, dimensions, severities and comparison operators, logical types, semantic types, server types, support tools and scopes, authoritative definition types, management port content and types, and data product types) are registered as valid metadata values by the Core Content Pack for the properties the Bitol cataloguers store them in.
• The support follows ODCS v3.2.0 and ODPS v1.1.0 (released 8 September 2026): enumerations, maps, vectors, synonyms, semantic types (measures and dimensions), the deprecated flag, the AI context block, vendor attribution on custom properties, SLA extensions, relationship ids, variable references, the physical encoding of servers and the SAP HANA, Apache Iceberg, Exasol, Teradata and Actian server types.

Egeria's OpenLineage support has moved from core specification 1-0-2 to 2-0-2, with every standard facet at its current version and the registered custom facets. Custom facets and unknown properties were previously dropped silently; they are now retained.

• Consuming events. The OpenLineage cataloguer now turns events into data assets, DataFlow, LineageMapping (column lineage), ControlFlow and ProcessHierarchy relationships, tabular schemas, RunMetrics, DataScope and a survey report for each statistics or data quality event, and handles renamed and dropped datasets. Datasets and jobs are matched to resources that are already catalogued, following the OpenLineage naming conventions, rather than creating parallel assets. Where there is more than one candidate, the others are linked as peer duplicates. Runs are only catalogued if the catalogRuns option is set, and sensitive facets such as environment variables and source code are not stored.
• Publishing events. Governance action runs are published with spec-conformant dataset names built from their action targets, provisioning outputs are published as outputs, and two custom Egeria run facets - egeria_governanceAction and egeria_informationSupplyChain - carry the information supply chain and governance action details.
• Analysis. Three new Lovelace governance action services - Profile OpenLineage Runs, Refine OpenLineage Data Scope and Summarise OpenLineage Data Quality - summarise the lineage captured.
• New technology types describe the tables of PostgreSQL, MS SQL Server, Oracle and Db2 LUW databases, together with data warehouses, NoSQL stores, file stores, document management systems, event streams and data pipelines, so that resources first seen through OpenLineage can be catalogued from templates.
• A new functional verification test suite, openlineage-fvt, exercises the cataloguer.

The Darwin Product Dependency Manager is a new integration connector supplied in the Core Content Pack. It maintains the coarse-grained lineage that the finer-grained lineage beneath it implies, working upwards through three levels on each refresh: data flows between data assets derived from the DataMapping relationships between their schema elements, data flows between software servers derived from the lineage between the data assets their capabilities own, and the DigitalProductDependency relationships that make up the data mesh, derived from the data lineage between the assets that are members of each digital product.

Each path is followed within a single information supply chain, and the iscQualifiedName is carried up onto the coarser relationship. Darwin creates the relationships that are missing, removes the ones it created that the lineage no longer supports, and fills in the information supply chain on relationships asserted by external users - but it never removes a relationship it did not create. A dependency that somebody has declared and no lineage path proves is recorded as an exception against the dependent product, for a steward to resolve.

It runs in its own integration group, Egeria:IntegrationGroup:Darwin, so all that is needed to start it is to configure an integration daemon with that group. A new functional verification test suite (darwin-fvt) exercises all three levels and the exceptions.

Egeria has had the types and APIs for duplicate management for some time, but nothing detected duplicates, acted on the links between them or created a consolidated element. The new Mendel Automated Duplicate Manager closes that loop. It runs in its own integration group, Egeria:IntegrationGroup:Mendel, and consolidates clusters of validated duplicates into a single element that is returned in their place, carrying over the members' properties, relationships and classifications.

• A lookup by unique name that finds more than one element now records a PeerDuplicateLink with status DISCOVERED, ready for a steward to review.
• Only duplicates with status VALIDATED are combined on retrieval.
• Duplicate entities no longer appear in search results, and the ends of ConsolidatedDuplicateLink are now the right way round.
• A content-pack-duplicate-report utility lists the duplicates between content packs, and the Jacquard solution components are now linked to their duplicates in the core content packs.
• A new functional verification test suite, duplicate-fvt, exercises the whole cycle.

The Open Metadata Digital Product Catalog now delivers data to its subscribers - previously a subscription could be taken out, but no data arrived.

• The Product Manager API can now create a digital product in one call, along with its manager, community, folders, guiding questions, product asset, licenses and data specification, and can add one-time, periodic and ongoing-update subscription types to it. The Jacquard Digital Product Loom now builds its catalog through the same code, via a new ProductManagerClient on the connector context.
• A product family is now subscribed to as one product, with one subscription and one provisioning pipeline, rather than a subscription for each member. Wedgwood delivers it a table at a time. Creating a family subscription now takes a few seconds rather than about five minutes.
• The Baudot Subscription Manager is now a dynamic integration connector running in the Jacquard integration group, see the upgrade notes. Notifications are now decided per subscriber, using the new minimumNotificationInterval on the notification type.
• The tabular provisioning services and Wedgwood now record the lineage of each delivery - a DataFlow from the source through the provisioning process to the destination, with a DataMapping for each column - in the information supply chain named by the request.
• A PostgreSQL schema can now be the source of a product, delivered table by table, and the PostgreSQL tabular data set connector can now read as well as write.
• Starting Jacquard's catalog of 111 products used to take sixteen minutes; it now takes about a minute and a half, because the catalog targets of every integration connector are now read on demand.
• New functional verification test suites, subscription-fvt and tabular-data-fvt, follow a consumer's journey from locating a product to receiving its data.

The Liskov Data Sharing Hub Manager now actively improves the descriptions of the members of a data sharing hub, enabling their cataloguing and requesting surveys of them (see the new excludedSurveyRequestTypes configuration property). It populates the hub's data dictionary from CSV files and database schemas - it had never been able to - with one data structure per database table, and links each DataField and DataStructure to the schema element it was derived from using an ImplementedBy relationship with designStep set to data-abstraction. Database schemas are now accepted as hub members.

The information supply chain mermaid graph has a new Status area that shows how far each solution component has progressed, from its deploymentStatus and any Promise classification, and the systems now have their own System Fabric area alongside the Data Fabric. Elements that are not solution components are now shown too. A new sample, SAMPLE Information Supply Chain - Deployment Status Demonstration, is included in the Core Content Pack.

The Metadata Expert API has two new sets of operations:

• Dynamic types. Open metadata types can now be added, updated and deleted at runtime (addTypeDef, updateTypeDef, deleteTypeDef, addEnumDef and deleteEnumDef). Until now new types could only come from open metadata archives or from the cohort. New types are validated against the existing types, homed in the local repository, reloaded after the archive types when the server restarts, and shared with the cohort. Types that came from an archive or another cohort member cannot be changed, and a type cannot be deleted while instances of it, or types that reference it, exist. The PostgreSQL repository stores the new types in a type_definition table that it creates automatically; the in-memory repository loses them on restart.
• Instance control. The re-identify (change the unique identifier), re-type and re-home (change the metadata collection that masters it) operations, which the repository interface has always supported, are now available for both elements and relationships.

Every open metadata relationship type and classification type can now be maintained through a typed API. An audit of the 199 relationship types and 85 classification types against the code that maintains them filled the gaps: new handlers and connector context clients for storage volumes, networks, operating platforms and concept model elements, and 98 new classification operations across eleven view services. New build-time checks keep the REST APIs and the type system aligned.

• The DevOps Pipeline API is now fully implemented.
• The Multi Language API now stores and retrieves translations (setTranslation, clearTranslation, getTranslation and getTranslations); previously its server operations were placeholders that stored nothing.
• The Project Manager API can classify a project as an Investigation, and the Glossary Manager API a glossary as a NamingStandardsVocabulary.
• The link operations for the multi-link relationships return the GUID of the new relationship, and it is used to update or detach that relationship.
• The Connection Maker API can attach a connection to any element through the ResourceConnection relationship.

• Multi Language API supports the attachments of translations for different languages to metadata instances.
• DevOps Pipeline API supports the maintenance of infrastructure metadata when new software is deployed to production.
• Privacy Officer API supports the maintenance of data processing descriptions associated with data processing purposes using in data privacy and data sharing agreements.

The MS SQL Server, Oracle, Db2 LUW and DuckDB content packs now include governance action processes to catalog an individual database schema and to remove it, as the PostgreSQL content pack already did. The schema-level processes had never worked for any vendor, because the JDBC integration connector refused a database schema as a catalog target; this is fixed. The Db2 LUW and PostgreSQL surveys no longer report the "statistics not gathered" sentinel values as the number of distinct values in a column.

The OMAG Server Platform Cataloguer, described in Leveraging Egeria, could not be used in a deployment with more than one platform, because two platforms that had not been given distinguishing names both wanted the same qualified name. This and six further defects are fixed. The cataloguer now also catalogs the platform it is running on, and restarts no longer re-catalog the platform. Elements catalogued by an earlier release are adopted and renamed automatically. More generally, dynamic integration connectors now only process catalog targets that are homed in their own metadata collection.

Several searches could silently return only part of the real result, with no error and nothing to say that the answer was incomplete. These are fixed:

• Paging through a PostgreSQL search is now stable - elements are no longer duplicated or skipped between pages - and the in-memory repository now sorts the same way.
• Classification filters (includeOnlyClassifiedElements and skipClassifiedElements), effectivity dates, relationship end types and engine action status are now pushed down into the repository query, so a page is no longer returned part-empty.
• The counting operations have a new pushDown option, so a caller that needs the count to agree with the list can ask for that.
• A string property containing a single quote gained an extra pair of quotes every time it was stored in the PostgreSQL repository; backslashes and LIKE patterns also failed. These are fixed, but values corrupted by an earlier release are not repaired.
• findEntitiesByPropertyValue now honours its startsWith, endsWith and ignoreCase flags, and a federated cohort works again when a secrets store is configured.
• Survey annotations are now anchored to their survey report, so deleting a report removes its annotations. The delete cascade now follows anchors transitively and no longer stops after the first hundred elements.

Egeria can produce 1517 distinct messages - the text of its exceptions, its audit log records and its notifications - and they are now published as a browsable set of pages in the messages-and-codes directory of the egeria repository. Each message now carries a link to the page that explains the component behind it: it is returned as messageURL on audit log records, reportedURL on exceptions and exceptionURL on REST responses, and printed by the console audit log. The PostgreSQL audit log store adds a message_url column automatically. Messages that nothing raises any more have been removed.

Seventeen opt-in functional verification test suites now cover the platform, its connectors and its content packs: auth-fvt, bitol-fvt, client-fvt, cts-fvt, darwin-fvt, duplicate-fvt, files-fvt, openlineage-fvt, platform-catalog-fvt, postgres-fvt, query-fvt, security-fvt, server-fvt, subscription-fvt, tabular-data-fvt, templates-fvt and type-fvt. Each is run with its own flag, for example ./gradlew :open-metadata-test:open-metadata-fvt:files-fvt:test -PrunFilesFvt - see testing. The cts-fvt suite runs the Conformance Test Suite against both of Egeria's own repositories, which it had not been run against since the runtime was restructured.

The defects the suites found are fixed in this release. Those that users are most likely to have met:

• A regenerated content pack was silently ignored when it was reloaded, so content pack changes have not reached existing repositories for some time.
• The file surveys never ran to completion.
• Templates left literal placeholders such as ~{resourceName}~ in the elements they catalogued.
• Out-topic connections shared one event bus identity, so only one engine on a server received events.
• The engine host and the integration daemon no longer require Apache Kafka, and the engine host retries missed engine actions within a short cycle rather than every 33 minutes.
• A Throwable that was not an Exception stopped the whole platform.
• Deleting a large anchored graph exhausted the heap.
• A server could miss a cohort registration that arrived just after it joined, and wait for the missing member for ever.
• The Babbage Analytical Engine could start duplicate Lovelace services, so, for example, karma points were awarded twice. Existing duplicate engine actions need cancelling by hand.
• Integration connectors that send metadata to a third party registered their listener again on every refresh, so they received duplicate events.
• The in-memory repository dropped classifications that a content pack added to an existing element, such as Promise.
• Several admin and operations client methods called endpoints that had moved, and returned 404.
• In the OpenMetadataAccessSecurityConnector, the instanceOwner dynamic group admitted every user, and a connection could be returned to a caller that was not authorized to read it. Reading a server's configuration document now needs an investigator rather than an operator.

The bearer tokens issued by the OMAG Server Platform's logon service expired one hour after they were issued, and this was hard-coded. The new bearerTokenTimeout property in the application.properties file sets the number of hours that an issued token remains valid for. Platforms that do not set the property keep the previous behaviour, since the default is still 1 hour, and so do platforms that set it to a value that is not a positive number of hours - the invalid value is reported as a warning.

The data file, media file, software file and folder templates in the Files Content Pack declare a deployedImplementationType placeholder. They now substitute it into the asset they create, where previously the template's own type (for example YAML File) was always used. Callers of these templates should supply the placeholder; the file cataloguers already do.

Trellis is the new home of Egeria's AI applications, in the egeria-trellis git repository. It contains two applications that use large language models alongside the open metadata ecosystem. Egeria is both their catalog of record and their identity provider: you sign in with your Egeria user identity, and the applications call Egeria as you.

• Resource Explorer discovers, surveys and catalogs information resources - git repositories, PostgreSQL databases and file systems. It supports broad scouting across many resources, deep assessment of a single resource, discovery of resources by what the surveys found, and enrichment by the people who know them. Investigations are recorded in Egeria as projects with working sets of the resources being explored, surveys can be scheduled, and the architecture recovered from the resources explored can be recorded as solution blueprints once a reviewer has accepted it.
• Egeria Advisor is a conversational assistant for people working with Egeria and pyegeria. It answers questions about Egeria's concepts and code, finds examples, and can act on your behalf through Dr.Egeria commands and reports, tailoring its answers to the perspective you select.

Both applications can be run alongside Egeria Workspaces through the new trellis optional runtime, and opened from the portal with single sign-on. They use a local Ollama server for their language models by default.

Egeria Workspaces has been extended in the following ways:

• The portal has a new Data Mesh view (Quickstart only) that draws every digital product and the dependencies between them, filtered by information supply chain. The Information Supply Chain tab of Egeria Explorer and the Lineage Explorer have a Show Promise / Memento option.
• Egeria Explorer has a new Patterns tab for browsing design patterns, and The Catalog has new Namespaces and Capability Hierarchy sections. The list panes have refresh buttons, and omni-search now also finds pyegeria classes and methods and REST API endpoints.
• The Overview dashboard is organized around ten viewpoint Perspectives, backed by Perspective and Question elements in Egeria.
• The Resource Explorer and Egeria Advisor AI applications can be started from the portal with single sign-on, and run in a new optional trellis runtime - see AI applications on Trellis above.
• The Quickstart and Freshstart servers now run the Mendel and Darwin nanny connectors and the Bitol integration connectors, and load the Apache Kafka and Bitol content packs. Quickstart creates a coco_data_hub database holding the data sets for the Coco Pharmaceuticals strategic digital product catalog (81 products and their dependencies).
• The start scripts upgrade pyegeria to the latest release on each start, unless it is pinned with --pyegeria-version, and take a new --egeria-cpus option. The platform's JVM settings have been retuned, an autoheal service restarts unhealthy containers, the portal restarts after a reboot, and data initialization batches run in the background with a new Activity Log tab on the Admin page.
• The Coco Pharmaceuticals workbooks have been extended with new governance domains, a data privacy program, a strategic information supply chain analysis, a design pattern library and new notebooks.

• Dr.Egeria has new command families for Asset Maker (creating assets from templates, with typed commands for PostgreSQL, Apache Kafka, Unity Catalog, CSV files, folders and secrets stores), Schema Maker and concept models, and new commands for the Promise, Investigation and NamingStandardsVocabulary classifications, governance points, project subtypes and Link Implemented By.
• The Data Designer commands have been realigned with the 0580/0581 types, including the new DataField attributes and PrimaryKey on a data field.
• Re-running a Dr.Egeria file no longer creates duplicate copies of multi-link relationships - the existing relationship is updated instead.
• pyegeria has closed almost all of the gaps between its view service clients and the REST APIs, and adds the Metadata Expert re-identify, re-type and re-home operations, a push_down option on the count operations, a for_lineage option on the lineage graph requests, and bearer token login.
• The hey_egeria command tech show elements register lists elements of any type, grouped by subtype and showing their classifications.
• My Egeria loads its Shop for Data tables in the background and has an updated Tech Types section.

The Coco Pharmaceuticals content has been extended with a strategic digital product catalog and the information supply chains behind it, and the Coco clinical trial governance action service that sets up the data lake has been fixed to find the Unity Catalog catalog in the place it is now described. These changes are specific to the Coco Pharmaceuticals scenarios.