Skip to main content

Reviewing Proposals

Private preview

Context Curation is currently in private preview and may not be enabled for your organization. Contact your Promethium representative for access.

Who reviews what​

Proposals are routed to the people who own the affected data:

  • Each proposal is tagged with the domains it touches, derived from the tables and rules it references (see Domains). A batch of proposals routes to users with Owner or Editor permissions on every domain the thread touches — a reviewer must be able to evaluate all of it.
  • Context that applies organization-wide, or whose domains can't be determined, routes to the organization's data stewards (Promethium data_steward role).
  • If triggered by an individual user — for example, uploading a document — that user is always notified of context proposals, alongside the resolved reviewers.

Review threads have a single owner: the first reviewer to act on a batch claims the thread, and other recipients see it as claimed / read-only. Follow-ups in that thread go to the thread's owner, who has the conversation's context and provided feedback. A claimed thread isn't stranded if its owner steps away — the owner or a data steward can release it back to the original reviewers for more input.

Finding your reviews​

Open Context Review from the Context Hub — the card shows how many threads are waiting on you; links from external notifications redirect straight to a thread. The queue lists your review threads, filterable by state:

  • New — a batch is waiting on a review
  • Awaiting response — you've sent feedback and the curator is working on the next round
  • Done — the thread has concluded

Select Start review on a thread to begin.

Reviewing a batch​

You step through the proposals one at a time. For each, you see the proposal itself alongside its evidence: why the curator believes it, excerpts from the source material, the existing context it relates to, and the curator's confidence level.

When a proposal would change existing context, the current and proposed versions are shown side by side — as an update (What changed) or, when they contradict each other, as a conflict with the curator's explanation of why the two can't coexist.

Decisions​

DecisionWhat it does
AcceptApproves the proposal as written
Request changesSends your feedback to the curator; based on that feedback, the proposal is revised for the next round or dropped
Keep existingFor conflicts: drops the proposal in favor of the current version

Feedback is required for any decision other than Accept. You can't submit the review until every non-accepted proposal carries feedback — the feedback is what the curator revises against, so an empty rejection would leave it guessing, and open up the possibility for suboptimal follow-ups.

Decisions save as a draft as you go, so you can leave and return. When every proposal is decided, submit the review.

What happens after you submit​

Everything accepted: the context is applied to the 360° Context Hub and takes effect for future answers. If an accepted proposal replaces existing, conflicting context, the prior version is retired — context is versioned, so the replaced version is preserved and the change is reversible. Your decision is recorded with the applied context.

Any feedback: nothing is applied yet. The whole batch returns to the curator, and the next batch in the thread adjusts accordingly — revised where your feedback applies, unchanged where it doesn't, and dropped where you rejected. A rejected proposal is not re-proposed in the thread. The thread shows Awaiting response until the revised batch arrives for review.

Writing effective feedback​

The curator revises based on what you write, so the feedback's precision determines the next round's quality. Three principles:

  1. State the verdict — should the proposal be revised, or dropped entirely?
  2. State why — the reason is what prevents the same mistake in the next round.
  3. Supply the correct fact when one exists — the curator can only propose what it can ground.
Weak feedbackEffective feedback
"No.""Incorrect — our fiscal year starts in February, not January."
"Not quite right.""Close, but revenue excludes intercompany transfers. Revise the rule to exclude them."
"Wrong.""This isn't a real business rule — the document describes a deprecated process we no longer follow. Drop it, and don't derive rules from the 'Legacy workflow' section."

The last example matters: when a proposal is simply wrong and there is no correct fact to supply, say so explicitly and tell the curator to drop it — including, where useful, which part of the source material led it astray. A decisive "drop this because X" ends the matter; a bare "no" can invite a revised guess.