Certifications
Mark reveals, nodes, topics, and domains as trustworthy so Orion and your team know which definitions are production-ready.
When to use it — After you have validated a reveal or other object and want it treated as production-ready.
Where to find it — Reveals are certified in Forge (the reveal detail panel). Everything else is managed in Context Studio → Governance → Certifications.
Who can use it — Reveal certification: Weaver and above. Generic object certification and topic certification: Luminary only.
Celiq does not have one single "certify" button. Certification is split across two systems that serve different purposes, and they have different role gates. This page explains both, when each applies, and who can do what.
The first system lives in Forge and certifies reveals — your shared metric and node definitions. The second lives in Context Studio under the Governance area and tracks certification status for a wider set of objects (nodes, reveals, topics, and domains), plus a dedicated action for certifying topics.
Overview
There are three distinct certification mechanisms in Celiq:
| System | What it certifies | Where | Role gate | Backing store |
|---|---|---|---|---|
| Reveal certification | A reveal (shared metric/node) | Forge reveal detail panel | Weaver and above | reveal_certifications |
| Generic object certification | Nodes, reveals, topics, domains | Context Studio → Governance → Certifications | Luminary only | context_certifications |
| Topic certification | A single topic | Context Studio (topic action) | Luminary only | context_topics (+ note in context_certifications) |
Reveal certification is the one that actively changes product behavior: a certified reveal gets a green check badge across Forge, is favored in the Catalog, and counts toward your Semantic Health score. The generic and topic systems are governance bookkeeping — they record a status and notes so your team has a clear, auditable signal of what has been reviewed.
When to use it
- Certify a reveal once you have confirmed its SQL and definition are correct and you want it to be the default, trusted answer for that metric — in the Catalog and when Orion answers questions.
- Use generic object certification when a Luminary wants a single Governance view of which nodes, reveals, topics, and domains have been reviewed, need review, or are deprecated.
- Certify a topic when a Luminary has reviewed a topic and wants to stamp it as certified for the team.
Certification is a signal of trust, not a lock. Certifying an object does not prevent anyone from editing it. It records who vouched for it and when.
Concepts
Reveal — A shared, named metric or node definition authored in Forge. See Reveals. Reveal certification — A Weaver-or-above action that flags a reveal as production-ready. Stored inreveal_certifications, keyed by workspace, domain, and reveal name. Carries the certifier's name, a timestamp, and an optional note.
Generic object certification — A status record in context_certifications, keyed by (object_type, object_id). object_type is one of node, reveal, topic, or domain. Status is one of certified, needs_review, or deprecated. Managed in the Governance area; writing it is Luminary-only.
Topic certification — A Luminary action that sets a topic's status to certified and stamps the certifier and time. If you add a note, it is also written into context_certifications as a topic record.
Semantic Health — A 0–100 composite score. Certified reveals contribute up to 40 of those points (the share of reveals that are certified), alongside the latest evaluation pass rate and resolved corrections. See Accuracy.
Getting started
Prerequisites:
- At least one reveal exists in a domain (to certify a reveal), or a node / topic / domain exists (for generic certification).
- You have the right role: Weaver+ to certify reveals; Luminary to write generic or topic certifications.
To certify a reveal, open Forge, select the domain, and open the reveal you want to certify so its detail panel shows the Certification card.
To manage generic certifications, open Context Studio, go to the Governance group in the left navigation, and select the Certifications tab.
Step-by-step
Certify a reveal in Forge (Weaver+)
Open the reveal's detail panel in Forge. In the Certification card, click Certify. A note field appears — optionally explain why this reveal is trustworthy (for example, "Matches finance close numbers Q2"). Click Confirm certify. The badge turns into a green check, and the card shows who certified it and when.
Re-certify or revoke a reveal
For an already-certified reveal, the same card shows Re-certify (to refresh the certifier, timestamp, and note) and Revoke. Revoking clears the certification — the reveal drops back to uncertified and its green badge disappears.
Open the Certifications governance tab (Luminary)
In Context Studio, open Governance → Certifications. You see every certification record for the workspace, newest first, each showing the object type, object id, status, optional notes, and who certified it.
Add a generic certification (Luminary)
Click + Add certification. Choose an object type (Node, Reveal, Topic, or Domain), pick the object, set a status (Certified, Needs review, or Deprecated), add optional notes, and click Save.
Change a certification status (Luminary)
On any row, use the status dropdown to switch between Certified, Needs review, and Deprecated. When you set it to Certified, Celiq records you as the certifier and stamps the time.
Examples
A common workflow: you build a revenue reveal in Forge, validate it against your finance numbers, then certify it with a note so the team trusts it.
The certify request that Forge sends for that reveal looks like this:
POST /api/forge/reveals/revenue/certify
{
"domain": "sales",
"note": "Matches finance close numbers for Q2"
}The stored certification row then carries the trust metadata:
{
"domain_name": "sales",
"reveal_name": "revenue",
"certified": true,
"certified_by": "Priya (Weaver)",
"certified_at": "2026-06-27T14:02:00Z",
"certification_note": "Matches finance close numbers for Q2"
}Separately, a Luminary doing a governance sweep in Context Studio might flag a stale node for cleanup:
POST /api/context/certifications
{
"object_type": "node",
"object_id": "legacy_orders",
"status": "needs_review",
"notes": "Source table deprecated — confirm before reuse"
}When a status is set to anything other than certified (like needs_review above), Celiq leaves the certifier and timestamp empty — those are only filled when the status is certified.
Best practices
- Certify reveals as the trust signal that matters. Reveal certification is what drives the green badge, Catalog ordering, and the Semantic Health score. Prioritize certifying the reveals people actually ask about.
- Always add a note when you certify. The note is the cheapest way to tell future teammates why this definition is trusted and what it was checked against.
- Use
needs_reviewanddeprecatedhonestly. In the Governance tab, mark objects you no longer trust asdeprecatedrather than deleting them, so the history stays visible. - Revoke when a definition changes. If a certified reveal's logic changes materially, revoke and re-certify after re-validating, rather than leaving a stale stamp in place.
- Validate before you certify. Certification is a vouch — run the reveal through validation and evaluations first.
Tips
Want a higher Semantic Health score? The certified-reveal component is the share of your reveals that are certified, worth up to 40 points. Certifying a few high-traffic reveals moves the score more than chasing rarely used ones.
Common mistakes
- Expecting one button to do everything. Certifying a reveal in Forge and certifying objects in the Governance tab are separate actions backed by separate tables. Certifying a reveal in Forge does not automatically create a
revealrow in the Governance Certifications tab, and vice versa. - Trying to certify reveals as a Tracer or Lens. Reveal certify and revoke require Weaver or above. Lower roles get a "Requires Weaver role or above" error.
- Trying to add or change a generic/topic certification without being a Luminary. Reading the Certifications list is open to your team, but adding, editing, and certifying topics are Luminary-only.
- Assuming certification locks an object. It does not. Anyone with edit rights can still change a certified object — re-validate and re-certify after meaningful edits.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Clicking Certify on a reveal returns "Requires Weaver role or above" | Your role is Tracer or Lens | Ask a Weaver or Luminary to certify, or have your role upgraded |
| Certify fails with "domain required" | The reveal's domain was not sent with the request | Open the reveal from within its domain in Forge so the domain is set, then certify |
| "+ Add certification" or the status dropdown is missing in the Governance tab | You are not a Luminary | The list is read-only for non-Luminary roles; ask a Luminary to make changes |
| Adding a generic certification returns "object_type and object_id required" | The form was submitted without selecting an object | Choose both an object type and a specific object before saving |
| A new generic certification returns "Not found" when you try to update it | The certification id does not exist in this workspace | Refresh the Certifications tab to reload current records, then update the existing row |
| Certified a reveal but its Semantic Health contribution looks low | The score is the share of all reveals that are certified | Certify more of your reveals, or check the score breakdown in Semantic Health |
| Topic shows certified but no note appears in the Certifications tab | A note is only written to the Certifications list when you provide one at certify time | Re-certify the topic with a note to record it |