oceanbase / oceanbase/powercontext

Tracking Issue: evaluate and integrate Jev with PowerContext

Open
#1,649 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ecosystem enhancement evaluation
Dominant language
Python
Stars
1.1k
Forks
212
Avg merge
1d 11h
Merged PRs (30d)
199

Description

Feature description

Evaluate two complementary ways to combine Jev and PowerContext: use Jev for bounded relevance and evidence judgments inside context workflows, and use PowerContext to supply the project history that those judgments need.

The first engineering deliverable is an optional Memory reranker with a controlled comparison. The first user-facing demonstration is a coding agent continuing a database-compatibility task with the right project constraints, prior failure evidence, and verification gaps.

Problem and proposed solution

Agents can retrieve irrelevant memories, reuse an inapplicable procedure, or accept a completion claim whose citation does not actually support it. Jev offers typed Choice, Score, and Noul decisions that may help with these narrow judgments. PowerContext provides durable facts, exact evidence and revisions, bounded context delivery, and work continuity.

This is an evidence-driven integration program. Provider claims about latency, price, and calibration are motivation for measurement, not established PowerContext results. No default provider switch or production quality claim is implied.

Child issues

  • P0 — #1643: feat(memory): add an optional Jev reranker with comparative evaluation
  • P1 — #1644: evaluation(context): assess Jev for semantic relevance and evidence coverage
  • P1 — #1645: feat(work): add advisory Jev checks for Handoff and Task Outcome evidence
  • P1 — #1646: example: demonstrate project-aware coding decisions with Jev and PowerContext
  • P2 — #1647: feat: evaluate Experience and Skill applicability with Jev
  • P2 — #1648: evaluation(memory): assess Jev for duplicate and conflicting Memory candidates

Delivery order and dependencies

  1. P0: establish the integration and baseline. Start with #1643. Reuse the existing MemoryReranker extension point, provider deadline/fallback behavior, and workload infrastructure. Compare no reranking, current LLM reranking, and Jev under fixed inputs and budgets.
  2. P1: test semantic value and demonstrate continuity. #1644 evaluates coverage beyond deterministic retrieval signals. #1645 evaluates whether exact evidence supports work claims. #1646 can start on the existing HTTP APIs independently of a production reranker and incorporate the evidence evaluator when available. Reuse transport and evaluation utilities where useful, while calibrating each task separately.
  3. P2: expand only where results justify it. #1647 covers read-time Experience/Skill selection. #1648 supplies a Jev experiment to the Memory lifecycle design in #1590. Neither requires automatic approval, retirement, installation, or execution.

An evaluation can close with a documented recommendation not to adopt Jev for that use case. Complete runnable experiments and reports; do not require every proposed model call to enter the default runtime.

Shared acceptance criteria

  • Every child has a reproducible result or implementation, explicit coverage limits, and an adopt/revise/stop decision. Live results are distinguished from fixtures and cached cookbook outputs.
  • Pin model and question-policy versions, separate calibration from held-out evaluation, and include English/Chinese, no-match, uncertain, conflicting, and adversarial cases relevant to each task.
  • Report downstream task quality as well as local scoring metrics, p50/p95 latency, actual context delivered, retries/fallbacks, and total pipeline cost. Define regression tolerances before inspecting the held-out results.
  • Existing behavior remains available without Jev credentials. A provider failure falls back to existing ranking or an unavailable advisory assessment, according to the operation.
  • PowerContext retains responsibility for authorized Scope selection, eligible exact revisions, evidence resolution, trust wrapping, and byte budgets. Sending historical content to a hosted provider is an explicit deployment choice; default telemetry does not retain private content.
  • The model-free recall gate remains the default behavior for that gate; any extra model assessment is separately opt-in and measured. New public schemas/APIs use the RFC and canonical OpenAPI workflow.
  • Jev probabilities do not establish authorization, successful execution, or completed work. declared/verified semantics and the existing Review and Artifact lifecycles remain intact.
  • Publish the project-history example and a concise explanation of when Jev adds value over PowerContext plus the host model alone.

Relationship to existing work

  • #1556 / #1596: the model-free recall sufficiency gate is already implemented. The Jev work tests additional semantic judgments and candidate ranking.
  • #1590: owns quality-aware Memory retrieval and reversible lifecycle policy; #1648 contributes provider-specific evidence.
  • #1422: owns the governed evaluation and improvement loop. Reuse its workload and evidence conventions.
  • #1352 / #1419: own work continuity and interoperable Handoff. #1645 and #1646 exercise their existing boundaries.
  • #1356: owns explainable PreparedContext receipts. An example's delivery log does not establish a new public receipt contract.
  • #1508 / #1635: own Experience/Skill consolidation, candidate evaluation, and Artifact evolution. Read-time Jev recommendations do not create a parallel evolution lifecycle.

Alternatives considered

The current deterministic paths, existing LLM reranker, dedicated rerankers, direct PowerContext-to-agent context delivery, and deterministic evidence checks are all valid alternatives. Choose each Jev integration on measured task benefit and operational cost rather than applying it to every decision.

Additional context

Code baseline reviewed: 92d2516, September 18, 2026.

Prepared with AI assistance. The issues describe proposed work; Jev benefits have not yet been reproduced in PowerContext.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with child issue #1643 and the existing MemoryReranker extension point, then review the provider deadline/fallback behavior and workload infrastructure. Compare no reranking, the current LLM reranker, and Jev under fixed inputs and budgets. Done means a reproducible implementation or evaluation with coverage limits, measured results, and an adopt/revise/stop recommendation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
ai, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.