[FEATURE] Extensible tag classification model discovery through Entry Points by RoelBollens-TomTom · Pull Request #463 · OvertureMaps/schema

Roel Bollens (RoelBollens-TomTom) · 2026-03-10T23:48:57Z

Extensible tag classification model discovery through Entry Points

This replaces the hardcoded model classification system with tag-based classification model discovery through Entry Points. This is based on #440 by Seth and several schema (ad-hoc) coding sessions where Seth, Vic, Dana, Tristan and Roel participated in.

Model discovery moved into system, eliminating assumptions about Overture in the process. The hardcoded namespace concept ("overture", "annex") and the ModelKind classifier is replaced with tags -- string labels derived by tag providers. Tags become the filtering, grouping, and classification mechanism for model discovery, driven by introspection and package metadata rather than central coordination.

system provides generic tag-based grouping without understanding what any particular tag means. Any package can register tag providers that classify models without special support in the discovery layer.

Purpose

Tags serve three roles:

CLI filtering: select subsets of models for output and codegen (--tag system:feature, --tag draft)
Classification and endorsement: distinguish features from extensions, mark models as vetted or approved by an authority
Marketplace taxonomy: browse and classify models and extensions in a future extension catalog

These roles overlap -- a tag like overture:theme=buildings serves both filtering and taxonomy. The design accommodates this overlap through structured tags that encode both ownership and dimension.

Tag Format

Tags are strings following the pattern [prefix:]key[=value]:

Plain: overture, draft, feature
Prefixed: system:extension -- : separates ownership
Prefixed k/v: overture:theme=buildings

: signals ownership and enables prefix reservation (see Privileged Packages and Tag Reservation). = signals a dimension with a value (groupable via --group-by). One level of each -- no nested colons or multiple = signs.

Minimal launch set

Tag	Meaning
`feature` (was: `system:feature`)	This model is a feature type (has geometry, inherits from Feature
`overture:theme=<theme>`	Which Overture theme this belongs to (e.g., `buildings`, `transportation`)
`overture` (was: `overture:official`)	Placeholder for a lifecycle/endorsement tag — exact name deferred pending Dana and Tristan's work on extension lifecycle

Reserved tags

Tags can be reserved either as simple tags or by namespaces. These are the tags and namespaces that are currently reserved:

Tag	Reserved for use by
`feature`	Tag providers from `overture-schema-system`
`overture`	Tag providers from `overture-schema-core`
`overture:*`	Tag providers from `overture-schema-core`
`system:*`	Tag providers from `overture-schema-system`

Extensions

Additional extensions and accompanied tags will be introduced in a future PR. Extensions allows to augment existing types with new fields (columns).

Tag	Meaning
system:extension	This model is an extension (adds columns/fields to an existing type)

CLI

The list-types command has been updated to support filtering and grouping by tags. Currently, it no longer displays the description or fully qualified class name. The json-schema and validate commands from the overture-schema cli and generate command from the overture-codegen cli have been updated to be able to filter on tags instead of filtering by theme and type. Further changes can be introduced in a future update.

Examples

% overture-schema list-types
address            feature  overture  overture:theme=addresses
bathymetry         feature  overture  overture:theme=base
building           feature  overture  overture:theme=buildings
building_part      feature  overture  overture:theme=buildings
connector          feature  overture  overture:theme=transportation
division           feature  overture  overture:theme=divisions
division_area      feature  overture  overture:theme=divisions
division_boundary  feature  overture  overture:theme=divisions
infrastructure     feature  overture  overture:theme=base
land               feature  overture  overture:theme=base
land_cover         feature  overture  overture:theme=base
land_use           feature  overture  overture:theme=base
place              feature  overture  overture:theme=places
segment            feature  overture  overture:theme=transportation
sources            overture
water              feature  overture  overture:theme=base

% overture-schema list-types --group-by overture:theme
overture:theme=addresses (1)
→ address            feature  overture  overture:theme=addresses

overture:theme=base (6)
→ bathymetry         feature  overture  overture:theme=base
→ infrastructure     feature  overture  overture:theme=base
→ land               feature  overture  overture:theme=base
→ land_cover         feature  overture  overture:theme=base
→ land_use           feature  overture  overture:theme=base
→ water              feature  overture  overture:theme=base

overture:theme=buildings (2)
→ building           feature  overture  overture:theme=buildings
→ building_part      feature  overture  overture:theme=buildings

overture:theme=divisions (3)
→ division           feature  overture  overture:theme=divisions
→ division_area      feature  overture  overture:theme=divisions
→ division_boundary  feature  overture  overture:theme=divisions

overture:theme=places (1)
→ place              feature  overture  overture:theme=places

overture:theme=transportation (2)
→ connector          feature  overture  overture:theme=transportation
→ segment            feature  overture  overture:theme=transportation

% overture-schema list-types --tag overture --exclude-tag overture:theme=base 
address            feature  overture  overture:theme=addresses
building           feature  overture  overture:theme=buildings
building_part      feature  overture  overture:theme=buildings
connector          feature  overture  overture:theme=transportation
division           feature  overture  overture:theme=divisions
division_area      feature  overture  overture:theme=divisions
division_boundary  feature  overture  overture:theme=divisions
place              feature  overture  overture:theme=places
segment            feature  overture  overture:theme=transportation
sources            overture

Deviations

Tag providers are additive only and can't remove existing tags.
The execution order of tag providers is non-deterministic.
There is currently no warning on a tag amount limit
Agreed minimal tag set deviates from coding session outcome to make them less clunky by dropping namespace

Seth Fitzsimmons (sethfitz) · 2026-03-12T05:08:23Z

+        filters = []
+
+        if tags:
+            filters.append(lambda key: all(tag in key.tags for tag in tags))


all() here means --tag foo --tag bar requires BOTH tags (AND). Is that the intended semantics, or should repeated --tag flags use OR?

This was intentional, but I guess this should still be formalized so I'll leave this open for discussion.

from the coding session minutes:

--tag semantics are AND
The mockups assume --tag overture --tag system:feature means "must have both tags" (AND). This contradicts the design doc's stated OR semantics. The group implicitly operated with AND throughout the exercise and no one objected. This should be formalized.

Ah, great. I'm good with that; it didn't track with how I'd been thinking about it earlier is all.

I'll still leave this open. Maybe after refactoring the other CLI commands opinions might change.

What we discussed this morning in the coding session: AND makes the most sense for CLI list, but there are other use cases where OR fits better.

I did some very cursory LLM-driven research about common CLI paradigms that support both AND and OR in filtering. The best example I could come up with were kubectl label selectors with -l and docker filters, but none of them fit our exact use case.

I thought about it a bit and came up with some priorities:

CLI should support both AND and OR.

Should not use any special shell characters, especially characters like ! that can get expanded even within double quotes.

The most common use cases should be simple.

Should not require a lot of typing.

The best idea I can come up with is to allow --tag to express an "OR of ANDs" by supporting multiple --tags values.

--tag can be repeated as many times as you want.

Each --tag supports as plus-sign-separated list. (Alternative: comma.)

Within a --tag the plus-separated values form an AND expression.

The multiple --tag arguments are unioned together as a big OR expression.

This allows you to express an "OR of ANDs" which is probably powerful enough for most CLI use cases.

I would also suggest allowing * wildcards to further strengthen the CLI power.

Examples

Get all models matching single tag, foo.

--tag foo

Get all models that are both foo AND bar.

--tag foo+bar

Get all models that are in an Overture theme AND also bar.

--tag overture:theme=*+bar

Get all models that are either foo OR bar.

--tag foo --tags bar

Get all models that are either Overture transportation features or Overture places features.

--tag feature+overture:theme=transportation --tag feature+overture:theme=places

--tag foo+bar I'm less a fan of, because it introduces a query language in the value. I'd rather keep --tag as a simple repeatable flag. But I like adding the wildcard for namespace:* and ns:predicate=*.

A git log style --all-match is something I considered to switch --tag values from OR logic to AND. My concern with that is that some commands may want AND by default, and that still doesn't give a clean way to support both AND and OR on the same command, if that's at all desired.

Alternative ideas:

--tag to include, --filter to exclude

-i/--include to include, -e/--exclude to exclude

existing is --tags and --exclude-tags

I'm still struggling to wrap my head around whether AND or OR is used because I don't have a mental model that leads to expectations. I think I expect it to differ by command. However, in the process of writing this out, my current inclination is:

--tag treated as OR to create a preliminary filter / result.

--filter (or --include for symmetry with --exclude, although the AND/OR inconsistency is trouble) treated as AND, applied to the preliminary result with AND to positively filter using large sets.

--exclude treated as OR, applied to the preliminary result with AND to filter out smaller sets.

The idea is that --tag does an initial select to reduce "everything" to an inclusive result, and then --filter draws a smaller circle and --exclude does a targeted job of removing undesired models.

# I want to expand my criteria once I commit to filtering # OR overture-schema list-types \ --tag overture:theme=places \ --tag overture:theme=buildings # I want to (positively) filter the preliminary results (from ORed tags) to datasets licensed under CDLA 2.0 # OR, with ANDed filters applied overture-schema list-types \ --tag overture:theme=places \ --tag overture:theme=base \ --filter license=CDLA-Permissive-2.0 # I want to (negatively) filter out ODbL-licensed datasets # OR, with ORed exclusions applied as filters overture-schema list-types \ --tag overture:theme=base \ --tag overture:theme=divisions \ --exclude license=ODbL-1.0 # I want to produce an increasingly broad JSON Schema equivalent # OR overture-schema json-schema \ --tag overture:theme=places \ --tag overture:theme=buildings # I want to select a narrow set of models to validate against # AND, using --filter instead of --tag overture-schema validate \ --filter overture:theme=base \ --filter source_type=raster # I want to generate docs for an arbitrary set of models # OR; AND would be too limiting overture-schema-codegen generate --format markdown --output-dir /tmp/overture \ --tag overture:theme=places \ --tag overture:theme=buildings

Attempting to clarify my idea further (and use set algebra to describe it):

--tag defines the scope. Without --tag, the scope is all models. With one or more --tag flags, the scope is the union of models matching any listed tag — --tag X --tag Y keeps models tagged X or Y.

--filter narrows the scope. Each --filter predicate adds a requirement every model must satisfy — --filter X --filter Y keeps only models matching both (AND).

--exclude removes from the scope. Models matching any listed exclusion are dropped — --exclude X --exclude Y drops models matching X OR Y.

So --tag is OR, --filter is AND, --exclude is OR-then-subtract.

Tag-based discovery is the primary entry point. OR is the right default for --tag — users reach for it to declare interest in any of several themes, and is what we concluded while working through this together. --filter is for the stricter case where every result must satisfy an additional requirement.

Equivalent set algebra: result = (⋃ tags) ∩ (⋂ filters) \ (⋃ excludes), with absent classes
contributing no restriction.

Drafted an implementation in 1ed1ce6

Victor Schappert (vcschapp)

Let some comments, but I'm generally aligned and would merge once Roel Bollens (@RoelBollens-TomTom) and Seth Fitzsimmons (@mojodna) are jointly aligned on merging.

Left some thoughts on the AND/OR issue in the CLI, probably above there somewhere. 👆

Victor Schappert (vcschapp) · 2026-03-25T17:13:38Z

+
+from overture.schema.system.feature import Feature
+
+logger = logging.getLogger(__name__)


This seems private, should i get the appropriate underscore prefix?

Victor Schappert (vcschapp) · 2026-03-25T17:18:21Z

+RESERVED_TAGS: dict[str, set[str]] = {
+    "overture": {"overture-schema-core"},
+    "feature": {"overture-schema-system"},
+}


I thought feature_provider was intentionally emitting feature rather than system:feature to be less clunky, per the PR description.

I understood from the PR description that you can reserve both plain tags and namespaces.

Personally I like this approach.

Victor Schappert (vcschapp) · 2026-03-25T17:23:54Z

+TagProvider: TypeAlias = Callable[[type[BaseModel], ModelKey, set[str]], set[str]]
+
+ModelDict: TypeAlias = dict[ModelKey, type[BaseModel]]
+
+TagProviderDict: TypeAlias = dict[TagProviderKey, TagProvider]
+
+ModelKeyFilter: TypeAlias = Callable[[ModelKey], bool]


Are any of these intended to be _Private, e.g. maybe TagProviderDict?

Victor Schappert (vcschapp) · 2026-03-25T17:33:42Z

+                    key = replace(
+                        key,
+                        tags=frozenset(generate_tags(model_class, key, tag_providers)),
+                    )


Basically switching the return type to tuple[str] from set[str]?

I have no opinion on this.

You could go the other way and return collections.abc.Iterable[str] - that way anything that can produce a sequence of strings via iteration would suffice.

github-actions · 2026-04-14T16:19:25Z

🗺️ Schema reference docs preview is live!


🌍 Preview	https://staging.overturemaps.org/schema/pr/463/schema/index.html
🕐 Updated	Apr 30, 2026 20:45 UTC
📝 Commit	1d23610
🔧 env SCHEMA_PREVIEW	`true`

Note

♻️ This preview updates automatically with each push to this PR.

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Co-authored-by: Seth Fitzsimmons <sethfitz@amazon.com> Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

… filtering logic - Removes overture tag provider (was deferred) - Simplified tags - Reserved tags instead of reserved namespaces - Fixes small issue introduced in earlier commit Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

… CLI commands Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

`filter_models` selects feature types from the registry through three combinators applied to the same tag grammar (plain `feature`, namespaced `system:extension`, or compound `overture:theme=buildings`): --tag OR defines scope (any-of) --filter AND narrows scope (all-of) --exclude OR-NOT subtracts (none-of) --type OR closed-list match on ModelKey.name (orthogonal) T = ⋃ tag predicates (absent → U) F = ⋂ filter predicates (absent → U) E = ⋃ exclude predicates (absent → ∅) result = (T ∩ F \ E) restricted to type_names if non-empty The mental model is procedural: --tag widens, --filter narrows, --exclude subtracts. Without --tag the scope is every registered model. An empty selector imposes no filtering. A `TagSelector` value object carries the three tag predicates: class TagSelector: include_any: tuple[str, ...] = () require_all: tuple[str, ...] = () exclude_any: tuple[str, ...] = () Field names encode the combinator (any-of / all-of / none-of), deliberately distinct from CLI flag names. Flags are user-facing affordances; field names are implementation-facing and self-document at the call site. `type_names` lives on `filter_models` as a keyword, not on `TagSelector`. It's a closed-list match on `ModelKey.name`, orthogonal to the tag predicate algebra. Isolating it makes `TagSelector`'s purpose statable in one sentence and confines a future fold-in of `--type` to a kwarg deletion that doesn't disturb `TagSelector`. User-facing help text frames flags as acting on feature types ("Include feature types with these tags — defines scope (OR; repeatable)"). Internal API docstrings keep "models" since they describe the Python class layer; "feature types" is the user-facing vocabulary for entry-point-registered top-level types, distinct from the Pydantic models used for nested fields. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Use provider_key.name (always a string) instead of provider.__name__, which raises AttributeError when a provider is a callable instance without __name__ — masking the original error inside the except block. Add exc_info=True to preserve the traceback in the warning. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Replace unittest.TestCase classes with module-level pytest functions parametrized over the tag lists. Per-tag parametrization isolates failures to the offending input instead of stopping at the first assertion in a loop. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Fixes D100 reported by pydocstyle / make docformat. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Plain tags, namespaces, and predicates now share a single TAG_PART pattern: lowercase alphanumeric start followed by alphanumeric, hyphen, underscore, or dot. Values remain case-permissive. Drops the prior asymmetry where namespaces and predicates allowed dots but plain tags did not. Make generate_tags private (its sole caller is discover_models) and broaden TagProvider's return type to Iterable[str] so providers can yield, return lists, or return sets. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

The provider's first argument is the value loaded from an `overture.models` entry point. For discriminated-union features (e.g. `Segment`) that's `Annotated[Union[...], Field(...)]`, not `type[BaseModel]` — the prior signature was a lie. Widen `TagProvider` and the in-tree providers to accept `Any` and document the boundary in `discovery/types.py`. Strip `typing_util.collect_types` to the cases discovery actually meets today: `Annotated`, `Union`/`X | Y`, plain class. Drop the unreached `NewType` and `Literal` branches. Point at `overture-schema-codegen`'s `extraction/type_analyzer.py:analyze_type` as the more capable implementation, with consolidation across system, core, and cli flagged as future work. `theme_provider` extracts the theme via `_theme_literal`, which asserts that `theme` is a single-value `str` `Literal[...]` and raises `TypeError` otherwise. `_generate_tags` catches and logs at WARNING, so third-party model-definition bugs surface visibly without crashing discovery. Promote tag-rejection logging from DEBUG to WARNING so authorization failures (invalid tags, reserved tags, reserved namespaces) don't disappear silently in normal operation. Convert filter tests from direct `_filter_tags` calls to a fake `TagProvider` driven through `_generate_tags`. Tests now exercise provider invocation and merge wiring, not just the filter, and decouple from the private filter name. Provider-behavior tests still call the providers directly. Add discriminated-union coverage for both `feature_provider` and `theme_provider`, plus a `TypeError` case for a non-Literal `theme`. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Seth Fitzsimmons (sethfitz) · 2026-04-30T18:17:31Z

+            added_tags = set(provider(model_class, key, tags.copy())) - tags
+            filtered_tags = _filter_tags(added_tags, provider_key)
+            tags.update(filtered_tags)


Dropped tags (when the tag provider manipulates the tag set) are silently ignored, so tag providers may only add tags. While I think this is desired behavior, the tag provider signature makes it look like they can be removed.

Thoughts?

Add Discovery and Tagging sections to system's README, covering the overture.models / overture.tag_providers entry point groups, the tag format, provider contract, namespace and tag reservation, the built-in providers, and TagSelector-based filtering. Update core's README: replace the stale Discovery bullet (discovery has moved to system) with one describing the authority and theme tag providers core contributes. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Tag providers now receive the concrete BaseModel subclasses for the entry point instead of the raw entry-point value. _generate_tags walks the model once via collect_types and passes the result to every provider, so providers can't forget to handle discriminated unions and the walk happens once per model rather than once per provider. The TagProvider type alias drops Any in favor of Iterable[type[BaseModel]], honestly typing what providers receive. The first arg of _generate_tags is annotated Any to match the entry-point loader, which yields union expressions that aren't type[BaseModel]. All three registered providers (feature_provider, authority_provider, theme_provider) update to the new signature; unit tests pass concrete classes directly while union-handling tests move to the _generate_tags integration boundary, where the walk now lives. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Seth Fitzsimmons (sethfitz)

Well, I'm happy with the state of the PR, but that's because I worked through my reactions to it and pushed a series of follow-up commits. (Not to say that it wasn't great before, but I took liberties with actually responding to my own comments by making changes. Mostly specific to filtering and supporting the nuances of union types like Segment.)

It's definitely worth others looking over the TagSelector business, particularly how they're handled (and what the CLI UX looks like), in addition to the other follow-ups I made.

Roel Bollens (RoelBollens-TomTom) added the change type - cosmetic 🌹 Cosmetic change label Mar 10, 2026

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from b8ca2fe to c00022c Compare March 11, 2026 20:31

Seth Fitzsimmons (sethfitz) requested changes Mar 12, 2026

View reviewed changes

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from a2461e3 to 61bb58f Compare March 16, 2026 20:27

Roel Bollens (RoelBollens-TomTom) changed the title ~~[WIP] Extensible tag classification model discovery through Entry Points~~ Extensible tag classification model discovery through Entry Points Mar 25, 2026

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from b602345 to 1501cc9 Compare March 25, 2026 14:30

Roel Bollens (RoelBollens-TomTom) changed the title ~~Extensible tag classification model discovery through Entry Points~~ [FEATURE] Extensible tag classification model discovery through Entry Points Mar 25, 2026

Victor Schappert (vcschapp) reviewed Mar 25, 2026

View reviewed changes

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from 1501cc9 to e5ad4c5 Compare April 14, 2026 16:17

Roel Bollens (RoelBollens-TomTom) temporarily deployed to staging April 14, 2026 16:18 — with GitHub Actions Inactive

Roel Bollens (RoelBollens-TomTom) requested a review from Seth Fitzsimmons (sethfitz) April 14, 2026 16:22

Roel Bollens (RoelBollens-TomTom) marked this pull request as ready for review April 14, 2026 16:22

Copilot AI review requested due to automatic review settings April 14, 2026 16:22

Copilot started reviewing on behalf of Roel Bollens (RoelBollens-TomTom) April 14, 2026 16:22 View session

This comment was marked as outdated.

Sign in to view

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from e5ad4c5 to 3daf759 Compare April 14, 2026 17:36

Roel Bollens (RoelBollens-TomTom) temporarily deployed to staging April 14, 2026 17:37 — with GitHub Actions Inactive

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from 3daf759 to f19416c Compare April 14, 2026 17:55

Roel Bollens (RoelBollens-TomTom) temporarily deployed to staging April 14, 2026 17:56 — with GitHub Actions Inactive

Roel Bollens (RoelBollens-TomTom) requested a review from Copilot April 14, 2026 18:13

Copilot started reviewing on behalf of Roel Bollens (RoelBollens-TomTom) April 14, 2026 18:13 View session

This comment was marked as outdated.

Sign in to view

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from f19416c to c8aa891 Compare April 14, 2026 18:45

Roel Bollens (RoelBollens-TomTom) temporarily deployed to staging April 14, 2026 18:47 — with GitHub Actions Inactive

Roel Bollens (RoelBollens-TomTom) requested a review from Copilot April 14, 2026 18:48

Copilot started reviewing on behalf of Roel Bollens (RoelBollens-TomTom) April 14, 2026 18:48 View session

This comment was marked as outdated.

Sign in to view

Roel Bollens (RoelBollens-TomTom) force-pushed the discovery-rework-with-tags branch from c8aa891 to e9eabf3 Compare April 14, 2026 19:03

Roel Bollens (RoelBollens-TomTom) requested a review from Copilot April 14, 2026 19:03

Victor Schappert (vcschapp) mentioned this pull request Apr 29, 2026

Tags: extensible model grouping #440

Closed

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 04:07 — with GitHub Actions Inactive

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 04:10 — with GitHub Actions Inactive

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 04:34 — with GitHub Actions Inactive

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 14:01 — with GitHub Actions Inactive

Roel Bollens (RoelBollens-TomTom) and others added 16 commits April 30, 2026 10:47

Refactor model discovery and introduce tags.

d7b9d3d

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

chore(system): use logger.warning instead of print

3ac4105

Co-authored-by: Seth Fitzsimmons <sethfitz@amazon.com> Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

refactor(core): simplify using direct boolean return

97741f0

Co-authored-by: Seth Fitzsimmons <sethfitz@amazon.com> Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

chore(system): update ModelKey docstring to reflect changed attributes

18e3f3e

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

chore(system, core): fixes linting/formatting issues

38362c3

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

refactor(codegen, cli): replace theme filtering with tag filtering in…

27d4471

… CLI commands Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

refactor(system): Adds reserved namespaces and logging to tag filtering

7ee3c5c

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

refactor(system): tighten discovery api and various small improvements

45b0e6d

Signed-off-by: Roel <75250264+RoelBollens-TomTom@users.noreply.github.com>

Simplify module path in entry point example

e8f0eec

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

docs(system): add module docstring to discovery models

57269ca

Fixes D100 reported by pydocstyle / make docformat. Signed-off-by: Seth Fitzsimmons <seth@mojodna.net>

Seth Fitzsimmons (sethfitz) reviewed Apr 30, 2026

View reviewed changes

Seth Fitzsimmons (sethfitz) force-pushed the discovery-rework-with-tags branch from 3e7503c to 0c50095 Compare April 30, 2026 18:19

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 18:21 — with GitHub Actions Inactive

Seth Fitzsimmons (sethfitz) temporarily deployed to staging April 30, 2026 20:43 — with GitHub Actions Inactive

Seth Fitzsimmons (sethfitz) force-pushed the discovery-rework-with-tags branch from 04a961b to 1d23610 Compare April 30, 2026 20:43

Seth Fitzsimmons (sethfitz) deployed to staging April 30, 2026 20:45 — with GitHub Actions View deployment

Seth Fitzsimmons (sethfitz) approved these changes Apr 30, 2026

View reviewed changes


		from overture.schema.system.feature import Feature

		logger = logging.getLogger(__name__)

Conversation

Roel Bollens (RoelBollens-TomTom) commented Mar 10, 2026 • edited by vcschapp Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Extensible tag classification model discovery through Entry Points

Purpose

Tag Format

Minimal launch set

Reserved tags

Extensions

CLI

Examples

Deviations

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Examples

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Victor Schappert (vcschapp) Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Victor Schappert (vcschapp) left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented Apr 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🗺️ Schema reference docs preview is live!

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as outdated.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Seth Fitzsimmons (sethfitz) left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Roel Bollens (RoelBollens-TomTom) commented Mar 10, 2026 •

edited by vcschapp

Loading

Victor Schappert (vcschapp) Apr 8, 2026 •

edited

Loading

github-actions Bot commented Apr 14, 2026 •

edited

Loading

Seth Fitzsimmons (sethfitz) left a comment •

edited

Loading