| `promptkit-openrouter-standard` | Inherits from external catalog profile `gemini-flash-latest`. | A maintained selection for general-purpose text generation. |
| `promptkit-openrouter-auto` | Selects backend `openrouter` and model `openrouter/auto`. | Delegates model selection to OpenRouter's automatic routing. |
These definitions and purposes describe the initial selections only and are
not continuing model-selection promises.
The auto profile can initially be a direct profile definition; it does not
require a second catalog alias or a new public API. It inherits connection and credential
metadata from the OpenRouter backend and need not add generation overrides.
Promptkit forwards `openrouter/auto` as the model identifier through its ordinary
client. OpenRouter owns the routing decision, eligible models, and resulting
provider behavior. Promptkit adds no model-selection algorithm or fallback
loop. Its ordinary local validation does not check the upstream availability
of `openrouter/auto`.
Both profiles receive the stable-ID guarantee below. References to aliases
describe inherited definitions where applicable; the same namespace,
precedence, and structural-validation requirements cover direct definitions.
Only these two profiles are in scope. This roadmap imposes no additional
approval process for future profiles.
The only profile-specific continuity promise is that the literal names
`promptkit-openrouter-standard` and `promptkit-openrouter-auto` remain
available, subject to the supported dependency and consumer-override scope
below. Their actual models may change at any time, for any reason, without
notice to anyone. No deprecation, approval, or change-announcement gate applies
to model selection. The names do not promise a permanent model, provider,
routing strategy, or set of defaults. Both initially use OpenRouter, but the
profile names themselves are the only continuity guarantee.
In particular, `promptkit-openrouter-auto` is not required to retain
`openrouter/auto` or automatic routing indefinitely. Neither profile guarantees
unchanged output, cost, latency, capabilities, or upstream availability. While
using upstream automatic routing, the selected model can vary between requests
even with unchanged Promptkit and catalog versions.
Catalog dependency updates must preserve local resolution of the two maintained
profile names. If a referenced catalog profile disappears or is renamed,
adjust the affected alias together with the dependency update and ship both in
the same Promptkit release. If the catalog retains the referenced ID but
changes its model, inheritance picks up the change automatically; no separate
model-selection approval is required. Ordinary code review and structural
validation apply. Upstream deprecation, retirement, and mapping accuracy remain
the catalog library's responsibility and do not create a Promptkit monitoring
or upstream-verification obligation.
Release validation must prove that every maintained alias resolves against
the selected catalog versions. This continuity guarantee applies to the
versions selected and tested by Promptkit and assumes consumers have not
overridden the alias or its base with their own definitions. Independently
upgrading a transitive catalog can remove an alias's base without updating
Promptkit; that untested combination is outside the guarantee.
Aliases would retain the ordinary profile precedence and inheritance
semantics. They would introduce no new public API or automatic model failover.
An already deployed application would retain its compiled alias and catalog
data until upgraded; an upstream withdrawal would not change its selection
automatically.
Adding these profiles does not change existing default-profile selection.
Consumers opt into them through the existing profile-selection mechanisms.
### Ownership, Precedence, And Composition
The maintained alias definitions belong to a small Promptkit-owned profile
source. Profile precedence is consumer sources in their existing order, then
Promptkit-owned aliases, then external catalog profiles. Consumers may override
an alias or its base using the ordinary profile mechanisms.
Reserve the `promptkit-` profile-ID prefix against definitions in external
catalogs. Reject such catalog definitions even if they do not yet collide with
an existing alias. This namespace rule does not prohibit consumer overrides.
Retain existing catalog-local inheritance and backend-ownership validation,
and verify that the combined maintained profiles resolve without relying on
consumer overrides. Do not assert a permanent model or routing selection based
on a profile name. Runtime inheritance must continue to observe the complete
source hierarchy, including consumer overrides of aliases and their bases.
Reuse the existing resolver; exact private assembly and validation sequencing
belongs in the implementation plan. Do not introduce a second inheritance
implementation or freeze alias values in a way that bypasses consumer overrides.
## Local Validation And Existing Safeguards
Profile volatility does not remove existing structural validation or library
safeguards. Preserve the following implemented responsibilities without making
them additional profile-availability or permanent implementation promises:
- catalog assets are immutable build inputs rather than runtime downloads;
- manifests and profiles satisfy the supported schemas;
- IDs are unique and profiles select their owning backend;
- external catalogs do not define IDs in the reserved `promptkit-` namespace;
- secret-bearing fields and prohibited connection metadata are rejected;
- profile values are normalized, copied, resolved, and overlaid through the
existing Promptkit architecture;
- the selected catalogs pass Promptkit's integration suite before a Promptkit
release adopts them; and
- the module graph and checksums provide a reproducible identity for the data
that was tested.
These checks establish local integrity for selected data, together with the
maintained-profile resolution requirement above. They do not establish external
catalog profile continuity across versions or live upstream availability.
Promptkit's checks cover local syntax and structural semantics: supported
