Historical document. Current product terminology is Vocabulary (third pillar), concept scheme, and field binding. Retired names (ontology, KB, field mapping) appear here as program-era references only. See Canonical Terminology.

KB Phase 0 — User-Facing Vocabulary and Status Labels

Purpose

This guide is the single source of truth for the words the KB/ontology workflow shows users and the colours behind those words. It is written for three audiences:

• UI engineers writing copy in components/editor/*, components/semantic/*, toolbar dialogs, inspector tabs, and Semantic Home tiles.
• Backend / API engineers documenting routes, request models, and CLI help text.
• Docs / DevRel writing PR descriptions, release notes, and the revenue agent walkthrough.

Use it when:

• Authoring a new label, button, toast, table column header, or empty state.
• Translating a backend enum (e.g. SuggestionStatus.PENDING) into UI copy.
• Picking a badge component and Tailwind colour for a status.
• Writing a PR description that touches the KB workflow surfaces.

Cross references: program decisions are locked in docs/guides/kb-ontology-workflow-kanban.md § "Program Decisions"; the UI primitives this guide canonicalises are inventoried in docs/guides/kb-phase-0-ui-patterns.md § "Status, badges, chips"; the backend status enums it cites are inventoried in docs/guides/kb-phase-0-api-audit.md (routes + handlers + services).

Two non-negotiables:

1. Workspace = UI label over ConceptSchemeModel. No new persisted workspace model in Phase 1. The UI says "Domain workspace" or just "Workspace"; the backend keeps saying "concept scheme". Both names must remain greppable in their own surface.
2. No breaking backend changes in Phase 1. Backend enum values stay. The UI may relabel them but the wire format does not change. Where a status name in the backend reads awkwardly to users (e.g. open, request_changes), this guide names the UI label and the canonical colour without renaming the enum.

Core Vocabulary

Plain-English label first column. Backend term second. Definition and worked revenue/billing example follow. RDF/SHACL/OWL phrasing is allowed in the inspector tooltip / advanced settings / API docs column only.

User-facing label	Backend term (file path)	One-line definition	Revenue/billing example	Where the technical name may appear
Domain workspace (or Workspace in the breadcrumb)	ConceptSchemeModel (src/pycharter/db/models/semantic/vocabulary_metaschema_models.py); JSON field scheme / concept_scheme on most semantic routes	A named container that groups the concepts, mappings, suggestions, and source assets for one domain. The UI label over an existing concept scheme.	"Revenue" workspace owns the customer, subscription, invoice, mrr, arr concepts and the bindings that connect them to the revenue contract.	Inspector "Advanced" tab; CLI --scheme flag; OpenAPI concept_scheme field name.
Business term (or Concept in the inspector header)	ConceptModel (src/pycharter/db/models/semantic/concept.py); enum ConceptType (src/pycharter/semantic/ontology/models.py:33)	A named, governed unit of meaning inside a workspace (entity, process, event, attribute, rule, metric).	The business term "Active subscription" defines exactly which subscriptions rows count as active for ARR.	Inspector "Type" line ("entity / process / event / attribute / rule / metric"); API responses; NodeKindBadge tooltip.
Field mapping (or Mapping in dense tables)	BindingState (src/pycharter/semantic/lifecycle/_types.py:15); MappingState (src/pycharter/semantic/knowledge/mapping_manager.py:19); ConceptBindingEventModel for history	A directional link from one contract field (e.g. invoices.amount_cents) to one business term. Carries lifecycle state and evidence.	Mapping invoices.amount_cents → business term "Invoice amount" with state approved.	Inspector "Binding history" drawer; binding_events API; CLI / RDF dump.
Suggestion (UI label is Review item in the Semantic Home tile per proposal §"Rename Concepts in the UI Before Rebuilding Screens"; Suggestion in detail panels)	SuggestionStatus (src/pycharter/semantic/ai/suggestion_pipeline.py:54); SuggestionModel (src/pycharter/db/models/semantic/suggestion.py); routes under src/pycharter/api/routes/v1/semantic_suggestions.py	A proposed change (new term, duplicate, relationship, definition, mapping) generated by an extractor or LLM. Always has source evidence and a confidence.	Suggestion: "Create business term Net Revenue Retention from dbt/models/marts/revenue.yml, confidence 0.82."	Suggestion API; OriginChip; queue filters.
Source asset	Proposed SemanticAssetModel / semantic_assets table — not yet persisted, planned in P1-003/P1-004. Today the closest object is the fingerprinted entry in ExtractionCache plus a source_uri field on suggestions and lineage rows.	An imported file, schema, manifest, or document that the workspace knows about. Every suggestion points back to one.	Source asset: dbt/models/marts/revenue.yml (last imported 2026-05-18, fingerprint sha256:1a…).	Inspector "Source" line; SourceUriBreadcrumb; future /api/v1/semantic/ingestion/assets.
Ingest run (or Import run in the import wizard)	Proposed semantic_ingest_runs table — not yet persisted, planned in P1-002/P1-004. Today's nearest analogue is the per-call response from /api/v1/semantic/ingestion/kb-text|upload, /api/v1/semantic/ingestion/extraction-runs, and /api/v1/semantic/ingestion/import-all — none of which is durable.	One end-to-end import: which assets came in, which extractors ran, what was extracted, what failed.	Ingest run #42: ran tree-sitter + dbt extractors on 4 revenue assets, produced 37 suggestions, skipped 1 file.	Run detail page; IngestReportResponse; activity feed.
Evidence	Suggestion details + provenance JSON fields today (src/pycharter/semantic/ai/suggestion_pipeline.py:78); structured evidence model proposed in P2-002.	The "why this exists" payload beside every suggestion: source asset, source span / locator, confidence, rationale, similar concepts.	Evidence for the "Active subscription" suggestion: dbt/models/marts/revenue.yml lines 12–18, confidence 0.82, conflict with existing concept customer.subscription.	Suggestion side panel; ConceptOriginCard; PR descriptions.
Health issue (or Coverage and readiness issue for the Semantic Home tile per proposal table line 742)	Inline severity strings (error / warning / Info / Warning / Violation) on validator and SHACL output — see src/pycharter/semantic/concept_graph/validator.py and src/pycharter/semantic/backends/_pyshacl_validator.py:71. No persisted health snapshot today; calculate_semantic_health is computed inline (src/pycharter/semantic/knowledge/semantic_health.py).	An actionable finding from a semantic health check: who, what, where, suggested fix.	Health issue: "3 required revenue fields are unmapped; open the Mapping workbench filtered to revenue."	Health panel; CI report; toast on save.
Coverage (or Coverage percentage)	CompletenessReport.coverage_pct (src/pycharter/semantic/knowledge/completeness.py:82); MaturityLevel (src/pycharter/semantic/knowledge/completeness.py:18)	The share of contract fields in a workspace that have an approved mapping. Bumps as mappings move from unmapped → approved.	"Revenue workspace coverage: 62% (43 of 70 fields mapped, 28 approved)."	Semantic Home tile; CompletenessBar; editor API.
Context pack (UI label is Agent context preview in the Semantic Home tile per proposal table line 744; Context pack in detail surfaces)	ContextPack dataclass in src/pycharter/semantic/knowledge/context.py; data/seed/context_pack_schema.yaml	A token-budgeted, governed snapshot of a workspace neighbourhood that an agent or downstream API will retrieve.	Revenue context pack: 38 approved terms, 22 mappings, 4 source assets, 1,800 token budget; ready for the AI analyst agent.	Context Preview view; MCP / API responses; export dialog.
Review decision	semantic_proposals table (ProposalModel with status column — open / merged / closed); semantic_reviews table via ReviewWorkflow (src/pycharter/persistence/collaboration/review.py:44) with decision ∈ {approve, request_changes, reject}.	A reviewer's verdict on a proposal that bundles one or more accepted suggestions. Lives in the governance review queue, not the suggestion queue.	Priya reviews proposal #17 ("Promote ARR from free to domain tier") and chooses Approve.	Proposal detail page; ReviewList; audit log.
Governance tier	ConceptTier (src/pycharter/semantic/ontology/models.py:15): free / domain / core; GovernanceTier (src/pycharter/semantic/namespaces.py:56)	Who is allowed to change a term and how. Free = anyone; domain = domain owner; core = central team. Used to decide whether a suggestion can be accepted directly or must go through a proposal/review.	customer is core (central team owns it). Active subscription is domain (revenue team owns it). A user's private experiment_metric is free.	TierBadge; CLI; API.

Total: 12 entries.

Three rows above flag entities the proposal expects but Phase 1 has not yet persisted (Source asset, Ingest run, and the structured Evidence model). The vocabulary still lists them so the labels are ready for the import wizard and suggestion detail panel as soon as P1-002 / P1-003 / P1-004 / P2-002 land. Labels do not change once persistence catches up.

Status Labels

One subsection per entity that carries a status. Each subsection lists the backend value, the user-facing label, the canonical badge colour, and the existing primitive whose colour wins.

Three primitives currently render statuses across the workflow:

• StatusBadge (semantic) — src/pycharter/ui/src/components/semantic/StatusBadge.tsx
• MappingDot (inside AssetTree) — src/pycharter/ui/src/components/knowledge-base/panels/AssetTree.tsx:27
• BindingHistoryDrawer — src/pycharter/ui/src/components/editor/shell/BindingHistoryDrawer.tsx:22

These three disagree today (UX0-002 residual risk; kb-phase-0-ui-patterns.md question 4). This guide picks one canonical colour per status and notes which primitive sets the baseline. UI engineers reuse that primitive; they do not add a fourth colour map.

Suggestion status

Drives the Suggestions Inbox row tint, the inline accept/dismiss buttons, and the "Review items pending" tile on Semantic Home.

Backend value (SuggestionStatus)	UI label	Badge colour (Tailwind family)	Canonical primitive	Notes
pending	Needs review	amber-400 background, amber-800 text	StatusBadge (amber/yellow-100/800) — the existing semantic StatusBadge already paints pending and open yellow; align all "waiting on a human" badges to amber so suggestion rows and proposal rows match.	This is the default.
accepted	Accepted	emerald-600 background, emerald-50 text	StatusBadge (green/emerald-100/800).	Materialises into a concept / mapping; the row moves out of the inbox.
dismissed	Dismissed	gray-300 background, gray-700 text	StatusBadge default-grey treatment.	Use the StatusBadge default colour rather than red — dismissal is a routine no-op, not a failure.

Open question for PM (#1 below): does "Request changes" need a fourth suggestion status, or stay a proposal-level decision?

Mapping / binding lifecycle status

Drives the MappingDot legend, the Mapping Workbench row tint, the inspector binding picker, and the binding-history timeline. This is the status with the worst overlap today.

BindingState is the canonical enum (src/pycharter/semantic/lifecycle/_types.py:15). MappingState (mapping_manager.py:19) is identical plus technical_only. Keep both — they describe the same lifecycle viewed from different sides.

Backend value	UI label	Badge colour	Canonical primitive	Notes
unmapped	Unmapped	gray-300 dot, gray-600 text	MappingDot (bg-gray-300).	Default empty state.
suggested	Suggested	amber-400 dot, amber-800 text	MappingDot (bg-amber-400).	Same amber as pending suggestions — they are the same "human needs to look" signal.
mapped	Mapped	green-500 dot, green-800 text	MappingDot (bg-green-500).	A reviewer accepted but governance has not yet approved. BindingHistoryDrawer paints this bg-primary/10 today — replace with green-500 to match MappingDot.
approved	Approved	emerald-600 dot, emerald-50 text	MappingDot (bg-emerald-600).	Governance-approved. Same emerald used for suggestion accepted and proposal merged.
technical_only	Technical only	slate-400 dot, slate-700 text	MappingDot (bg-slate-400).	Field deliberately not modelled — e.g. created_at plumbing on invoices. Use the slate (cool grey) so it is visibly distinct from the gray unmapped state.
unresolved (projection-only)	Unmapped	gray-300 dot, gray-600 text	MappingDot (bg-gray-300) — render identically to unmapped.	Stored on MappingProjection.state (src/pycharter/semantic/mapping_projection/models.py:65-71); never appears on BindingState (src/pycharter/semantic/lifecycle/_types.py:15-30). The projection deliberately rolls up two distinct lifecycle situations under one row state: (a) the binding was explicitly reset back to BindingState.UNMAPPED via a reject hook, and (b) the binding's concept_key never resolved against the loaded ontology in the first place. BindingState keeps the finer transition history; the projection prefers a single "needs review" bucket for coverage maths. Surface the same UI label as unmapped — operators only see this token in DB rows and logs.
(partial — derived, not stored)	Partially mapped	green-500 / gray-300 split dot	MappingDot partial gradient (AssetTree.tsx:36).	Already implemented for table rows whose columns are mixed-state; keep.

BindingHistoryDrawer.STATE_CLASS must be updated to reuse the same five colours when it next changes (out of scope for P0-005; flagged on the UX0-002 residual-risks list and on this guide's Open Questions).

Note on unresolved vs. unmapped. P1-007-IMPL introduced a projection table (pycharter.mapping_projections) that stores a denormalised current-state copy of every binding for indexed lookups. Its state column uses the alphabet {"unresolved", "suggested", "mapped", "approved"} — note the leading "unresolved" where BindingState (src/pycharter/semantic/lifecycle/_types.py:15-30) uses "unmapped". The divergence is deliberate per the locked decision in docs/guides/kb-phase-1-p1-007-mapping-projection-decision.md:331-335: the projection collapses "explicitly rejected" and "never resolved" into one row state because the mapping workbench coverage gauge treats both as the same "needs review" bucket, while BindingState keeps the finer transition history needed by the lifecycle event log. The UI label and badge colour are the same for both backend tokens. Cross- reference the rollout doc docs/guides/kb-phase-1-p1-007-fu-b-lineage-rollout.md for the env vars and migration order that surface this state in production.

Proposal / review decision status

Drives ReviewList, the proposal detail page, the activity feed, and the dashboard "open / merged / closed" counters.

ProposalModel.status is stored as a string today (audit: semantic_dashboard.py checks "open" / "merged" / "closed" literals; semantic_activity.py:260 filters on "merged"). ReviewWorkflow accepts decision ∈ {"approve", "request_changes", "reject"} (src/pycharter/persistence/collaboration/review.py:52).

Backend value	UI label	Badge colour	Canonical primitive	Notes
open (proposal)	Open	amber-400	StatusBadge.	Aligns with pending suggestions / suggested mappings.
merged (proposal)	Merged	emerald-600	StatusBadge.	Aligns with approved mappings.
closed (proposal)	Closed	gray-300	StatusBadge.	Dismissed without merging. Use grey, not red — closing without merging is not a failure.
approve (review decision)	Approved	emerald-600	StatusBadge.	Recorded against a proposal.
request_changes (review decision)	Changes requested	orange-400	StatusBadge (orange-100/800).	The existing StatusBadge already uses orange for request_changes; keep — distinct from amber pending.
reject (review decision)	Rejected	red-500	StatusBadge.	This is the only status where red is correct: a reviewer actively said no.

The current StatusBadge (semantic/StatusBadge.tsx) is the source of truth — its existing red/green/yellow/orange ramp aligns with this table once dismissed is moved from red to grey (see Conflicts below).

Health-check severity

Drives the health panel, governance violation list, validation panel, and toolbar badges.

Severity values today come from two sources: - Concept-graph validator (semantic/concept_graph/validator.py:42): error, warning. - SHACL backend (semantic/backends/_pyshacl_validator.py): Info, Warning, Violation.

These are equivalent. Normalise to a three-level UI ladder:

Backend value(s)	UI label	Badge colour	Canonical primitive	Notes
Violation / error	Error	red-500 background, red-50 text, AlertCircle icon	CompanionPanel severity map (src/pycharter/ui/src/components/editor/inspectors/CompanionPanel.tsx).	Blocks merge / blocks agent context publication.
Warning / warning	Warning	amber-400, AlertTriangle icon	CompanionPanel.	Should fix; does not block.
Info	Info	sky-400, Info icon	CompanionPanel.	Informational only. Use sky (light blue), not green, to avoid colliding with approved.

The sky-blue (Info) recommendation is new — today CompanionPanel paints info issues in a generic muted tone. Adopt sky-400 the next time the severity map is touched.

Concept (governance) tier

Drives TierBadge (src/pycharter/ui/src/components/semantic/TierBadge.tsx) in the concept tree, search results, inspector header, and proposal detail.

Backend value (ConceptTier)	UI label	Badge colour	Notes
core	Core	indigo-600 background, indigo-50 text	"Core" is the most governed tier; use indigo (distinct from green/red/amber families used for status).
domain	Domain	violet-500 background, violet-50 text	Owned by a domain steward.
free	Free	slate-300 background, slate-700 text	No governance; equivalent visual weight to unmapped.

TierBadge already exists and renders CORE / DOMAIN / FREE pills — its exact Tailwind colours are not in kb-phase-0-ui-patterns.md line 141. Adopt indigo / violet / slate the next time the file is touched; the key invariant is that tier colours never overlap with status colours (green / amber / red / orange / sky / grey).

Asset / ingest-run status (proposed; not yet persisted)

These fields are defined by the proposal (P1-003 / P1-004) and have no backend value today. Reserve the labels and colours now so the import wizard, asset inspector, and ingest summary screen do not invent parallel taxonomies.

Proposed backend value	UI label	Badge colour	Notes
imported (asset)	Imported	emerald-600	Ready.
stale (asset)	Stale	amber-400	Source has changed since last import.
failed (asset)	Import failed	red-500	Extraction failed — appears in the ingest summary failures list.
pending (ingest run)	Running	amber-400 + spinner	Same convention as worker.JobStatus.PENDING / CLAIMED.
completed (ingest run)	Completed	emerald-600	All assets processed.
partial (ingest run)	Partial	orange-400	Some files skipped or failed — links into the failures list. Matches dashboard/StatusBadge.tsx partial colour.
failed (ingest run)	Failed	red-500	Run aborted.

Adopt the same three primitives (StatusBadge, severity ramp, dot) when these fields ship. Do not introduce a fourth colour family.

Tone and Language Rules

Where RDF / SHACL / OWL terms may appear

The proposal explicitly classifies "RDF", "SHACL", "OWL reasoning", "context pack", and "concept scheme" as technical vocabulary that may appear as needed (proposal §"Progressive Disclosure" lines 193–199).

Apply this matrix:

Surface	RDF/SHACL/OWL OK?	Example
Top-level nav, breadcrumbs, page titles	No. Use "Workspace", "Mapping", "Health", "Context pack".	"Revenue / Mappings / invoices.amount_cents"
Semantic Home tiles	No.	"Coverage 62%", "Review items: 37"
Suggestions Inbox row text	No.	"Create business term Net Revenue Retention"
Inspector header line	No.	"Business term · Entity · Domain tier"
Inspector "Advanced" tab / tooltip / metadata	Yes, with a short gloss.	"Concept scheme (RDF / SKOS): revenue"
Modal — Save / Export / Import — advanced section	Yes.	"Export as RDF (Turtle / JSON-LD)"
Governance / validation panel detail text	Yes, when the SHACL shape name is the diagnostic.	"Shape RevenueInvoiceShape violated at path :amount_cents"
API docs, OpenAPI descriptions, CLI --help	Yes.	--scheme flag; concept_scheme field.
PR descriptions, ADRs, internal docs	Yes.	"Adds ConceptSchemeModel migration."

Accepted vs. rejected copy (revenue/billing flavour)

Surface	✓ Accepted	✗ Rejected
Empty state on a new workspace	"No business terms yet. Import a contract or schema to get started."	"ConceptScheme has no skos:hasTopConcept members."
Toast after accepting a suggestion	"Accepted Active subscription. Now appears in the Revenue glossary."	"Materialised suggestion sug_42; rdfs:label assertion added."
Health panel issue text	"3 required revenue fields are unmapped. Open the Mapping workbench."	"3 sh:minCount violations on :RevenueContractShape."
Mapping Workbench column header	"Field" / "Business term" / "Status"	"skos:Concept IRI" / "rdf:predicate"
Inbox row, primary line	"Suggest mapping: invoices.amount_cents → Invoice amount (0.82)"	"Suggestion 42: bind :invoices#amount_cents to :InvoiceAmount (conf 0.82)"
Inbox row, secondary line	"From dbt/models/marts/revenue.yml, lines 12–18"	"Provenance origin: dbt; source URI: pipeline_run://…"
Export dialog	"Export the Revenue workspace as RDF (Turtle, JSON-LD)"	(RDF here is fine — this is the Advanced surface.)

Plural and capitalisation conventions

• Singular noun for an inspector header, plural for a tile or list header. Example: tile "Review items: 37"; inspector header "Review item".
• Sentence case in body copy and toasts. Title Case only for nav and primary headings.
• Status labels are sentence case ("Needs review", "Changes requested", "Import failed"), not Title Case.
• Avoid acronyms in the primary label column. "ARR", "MRR", "NRR" are fine when they are the business term itself — wrap them in the concept name.

Backend → UI Status Map

Single reference table — copy from here when authoring a column header, toast, or filter chip.

Backend enum / field	Value	UI label	Badge colour	Description
SuggestionStatus	pending	Needs review	amber-400	Suggestion awaiting a reviewer.
SuggestionStatus	accepted	Accepted	emerald-600	Reviewer accepted; materialised into a concept or mapping.
SuggestionStatus	dismissed	Dismissed	gray-300	Reviewer declined; not a failure.
BindingState / MappingState	unmapped	Unmapped	gray-300	No binding exists for this field.
BindingState / MappingState	suggested	Suggested	amber-400	Automated picker proposed a binding; needs human review.
BindingState / MappingState	mapped	Mapped	green-500	Reviewer accepted the binding; not yet governance-approved.
BindingState / MappingState	approved	Approved	emerald-600	Governance-approved binding.
MappingProjection.state (projection-only)	unresolved	Unmapped	gray-300	Projection rollup of BindingState.UNMAPPED + bindings with no resolved concept_key. Render identically to unmapped. See "Mapping / binding lifecycle status" above.
MappingState	technical_only	Technical only	slate-400	Field deliberately not modelled.
ProposalModel.status	open	Open	amber-400	Proposal awaiting review.
ProposalModel.status	merged	Merged	emerald-600	Proposal accepted; changes are now in the workspace.
ProposalModel.status	closed	Closed	gray-300	Proposal closed without merging.
Review decision	approve	Approved	emerald-600	One reviewer's verdict on a proposal.
Review decision	request_changes	Changes requested	orange-400	Reviewer asked author to revise.
Review decision	reject	Rejected	red-500	Reviewer actively declined the proposal.
Validator / SHACL severity	error / Violation	Error	red-500 + AlertCircle	Blocks merge or agent context publication.
Validator / SHACL severity	warning / Warning	Warning	amber-400 + AlertTriangle	Recommended fix; does not block.
Validator / SHACL severity	Info	Info	sky-400 + Info	Informational.
ConceptTier	core	Core	indigo-600	Central team owns it.
ConceptTier	domain	Domain	violet-500	Domain steward owns it.
ConceptTier	free	Free	slate-300	No governance.
MaturityLevel (CompletenessReport)	unmapped	Unmapped	gray-300	Matches BindingState.unmapped.
MaturityLevel	partial	Partial	amber-400	Some assets mapped, no definition.
MaturityLevel	complete	Complete	green-500	Mapped + defined.
MaturityLevel	approved	Approved	emerald-600	Steward-approved. Matches BindingState.approved.
Asset status (proposed P1-003)	imported	Imported	emerald-600	Ready.
Asset status (proposed P1-003)	stale	Stale	amber-400	Source changed since last import.
Asset status (proposed P1-003)	failed	Import failed	red-500	Extraction failed.
Ingest-run status (proposed P1-004)	pending / claimed	Running	amber-400 + spinner	In progress.
Ingest-run status (proposed P1-004)	completed	Completed	emerald-600	All assets processed.
Ingest-run status (proposed P1-004)	partial	Partial	orange-400	Some assets skipped or failed.
Ingest-run status (proposed P1-004)	failed	Failed	red-500	Run aborted.

Three colour families do all the work above: green/emerald (approved / merged / completed / accepted), amber/yellow (needs-review / open / pending / suggested / stale / warning), red/orange (rejected / failed / error / changes-requested), plus grey/slate (unmapped / dismissed / closed / technical-only / free) and indigo/violet (governance tier only). Avoid introducing any sixth family.

Open Questions

Numbered for the PM to triage. Each names the audit/proposal cross reference that surfaced it.

1. Suggestion request_changes — the proposal lists "request-changes" as a suggestion action (proposal §"Step 4 Generate Suggestions", §"Step 5 Review and Approve") and as a review decision, but today only semantic_reviews carries request_changes; SuggestionStatus has just pending / accepted / dismissed. Do we add a fourth SuggestionStatus value or always route "request changes" through the proposal/review path? (API audit Open Question 3; proposal Step 5.)

2. Workspace-label scope — the locked decision (kanban "Program Decisions") treats "Domain workspace" as a UI label over concept schemes, but UX0-001 Open Question 1 asks whether all ontology surfaces relabel "Ontology" → "Domain workspace", or only the Semantic Home tile. The vocabulary assumes uniform relabel; PM to confirm scope.

3. Health-issue persistence — today health is computed inline (calculate_semantic_health) and SHACL severity strings vary (Info / Warning / Violation vs. info / warning / error). When P4-001 lands a persisted health-finding model, do we keep the sentence-case label set (Error / Warning / Info) and store the lowercase backend enum, or persist exactly what the validator emitted? (API audit §Health & Context gaps.)

4. MaturityLevel overlap with BindingState — MaturityLevel (used by the coverage bar) reuses three of four BindingState names but adds partial and complete. Should the UI surface MaturityLevel as a separate "Maturity" filter, or fold complete into mapped and partial into suggested for the user? Affects Mapping Workbench filter chips. (UI patterns audit §CompletenessBar; proposal §Step 7.)

5. MappingState.technical_only UX — MappingDot already paints it slate-400, but the workflow has no obvious surface that lets a user mark a field technical-only outside the legacy KB AssetTree. Where does that affordance live in the unified editor — inspector menu, Mapping Workbench row action, or import wizard bulk action? (UX0-001 §AssetTree; UI patterns audit §Bindings.)

6. Context-pack states — the proposal envisions context packs that can be ready, stale, or blocked (proposal §"Step 8 Serve Governed Context"). No backend enum exists today. Adopt the same three-colour ramp (emerald / amber / red) ahead of P5 to keep the Semantic Home tile copy stable?