Commit History
-
[NOTICKET] feat(knowledge): DocumentBrief split + cross-document measure identity
Rifqi Hafizuddin +1: Claude Opus 5Two changes that belong together, both made BEFORE the authorised extraction run so the fresh rows land in the right shape and nothing needs re-keying after. V4-4 - THE DOCUMENT BRIEF SPLIT. The per-document object is now `DocumentBrief`, `kind='document'`, prefix `b_`, and `domain` is reserved for the scope-level semantic model composed in src/knowledge_domain/. Prefix history, and it is not churn: b_ (BriefContext) -> d_ (DomainContext, 2026-09-01) -> b_ again (DocumentBrief, 2026-09-08). The middle move renamed the object without changing what it held - a per-document card. v4 builds the real domain context and gives d_ to it, so this one goes back to the name that describes it. Safe only because nothing is approved against it: an id prefix change after an expert has ruled is a migration that loses their approvals. WHAT A DOMAIN IS THE UNIT OF (Rifqi's question, answered in the plan section 3.0). Per SCOPE - the company - composed across all its documents and runs. …b5de3b4 -
[NOTICKET] docs(knowledge): one name for the rules; correct the stale v3 banner
Rifqi Hafizuddin +1: Claude Opus 5NAMING. One concept carried three names - the CLI wrote `interpretation_pack.json`, the type is `RuleEntry`, the DB column says `kind='rule'` - and it misleads in practice: reading the CLI output beside the consumption plan, "interpretation pack" and "rules" do not obviously connect, which is exactly how the question came up. The file is now `rules.json`, so file, entity and kind agree. One write site, no readers. "The Interpretation Pack" is deliberately KEPT in prose as the name of the deliverable - what these rules are FOR - just no longer as a third identifier. Cheap to do now: knowledge_reviews is empty, so no expert approval is keyed to any of these names. STALE BANNER. Output contract section 8 said the v3 LLM-facing parts - `purpose_verbatim` as a span-guarded quote, and the `subdomains` aggregate - were "still proposed and not built". They shipped 2026-09-02 and the banner was never updated, so it contradicted the field table directly beneath it, which dates both changes. Ve…73495cb
-
[NOTICKET] refactor(knowledge-extraction): BriefContext -> DomainContext
Rifqi Hafizuddin +1: Claude Opus 5The workstream diagram has always called this box "Domain Knowledge", while the model and its fields described a short orientation card. Rename the entity to match the intent before anything is persisted: once an expert has approved rows keyed on these ids, changing the `b_` prefix is an id migration that loses the approvals - the exact failure the deterministic-id scheme exists to prevent. BriefContext -> DomainContext brief_id -> domain_id (prefix b_ -> d_) ExtractionResult.brief -> .domain brief_context.json -> domain_context.json Deliberately unchanged: - `Branch = "summary"` and GUARDED_FIELDS["summary"]. The branch literal is the measurement key in CallUsage.branch / RejectedField.branch; renaming it would break comparability with the committed eval baseline. - prompts/summary.txt. Editing prompt text needs the eval path, and the rewrite belongs with the v3 schema change, not with a rename. No field, prompt or guarding change - the …7f47c61
-
[NOTICKET] feat(knowledge_extraction): output schema v2 — entity ids, links, 16 fields cut
Rifqi Hafizuddin +1: Claude Fable 5Harry's review of the output contract asked for four things: an id on every entity, a formula referenced rather than restated, rules related to formulas, and a smaller schema. All four are adopted. Two defects surfaced while adding the ids, and they matter more than the ids do. Neither existing identifier survived a re-run: `cluster_id` was a frequency-rank ordinal (`#c000` over a list sorted by mention count), so one changed count reshuffled every id after it, and `rule_id` was written by the model, so the same rule could return a different slug next run. The product is an expert working a review queue — if Mas Beta approves 40 entries and a prompt is retuned, unstable ids lose which 40. Approval continuity, not linking, is why these exist. New `ids.py` mints term/formula/rule/brief ids as sha256 over content: never positional, never model-supplied. New `link.py` resolves every reference after the branches run — deterministic, no LLM, no spend — and returns dangle counts rather than…49dfe4d
-
[NOTICKET] fix(knowledge_extraction): refuse an artifact that will not name its backend
Rifqi Hafizuddin +1: Claude Opus 5MinerU's `pipeline` and `vlm` backends emit different text from the same PDF. The same equation arrives as a semantic `\times` from one and as a spaced literal `x` from the other, and word boundaries that survive in `\text{...}` under `vlm` are gone under `pipeline`. Two extraction results measured on different backends are therefore not comparable, and nothing downstream can tell them apart after the fact. This is not hypothetical: the two halves spent a week comparing numbers taken from two different parses and read the disagreement as a rendering bug. Each side was measuring correctly, on a different artifact. The provenance already existed and was walked around. `ParsedDocument` carries `parser_backend`, and the parsing half reads it from MinerU's own `_middle.json` rather than from config, precisely so the recorded backend is the one actually used. It never reached extraction because what crossed the seam was a bare `content_list.json`, stripped of its envelope. So the CLI now …4db5f14
-
[NOTICKET] feat(knowledge_extraction): paid extraction stage + validate, diff, queue
Rifqi Hafizuddin +1: Claude Fable 5Completes every stage that does not depend on the seam. The pipeline now runs end to end: artifact -> filters -> cluster -> rank -> LLM -> validate -> diff -> frequency-sorted review queue. extract/ client on the nano __54n quad; structured output is PROBED not assumed (json_schema, falling back to json_object + validate-retry, recording which applied); cached tokens read from the API, never modelled. Four branches, one call per TERM CLUSTER. Prompts stay as files so the fixed prefix is byte-identical and caching keeps engaging. validate/ span check (whitespace-only normalisation, never repairs, unlocatable provenance rejects every guarded field), escalation, conflict detection by token overlap — explainable to the reviewer, and it never picks a winner. diff/ new / duplicate / conflicting against an explicitly supplied active glossary, so the duplicate and conflicting paths are reachable. The …ab5ea78 -
[NOTICKET] feat(knowledge_extraction): span filter — E1 recall 0.8537, matches the frozen baseline
Rifqi Hafizuddin +1: Claude Fable 5Adds the term-filter stage, the last free stage before the paid extraction call. Dependencies (approved): gliner>=0.2.13 (resolved 0.2.28), torch>=2.6 (resolved 2.11.0+cpu). Install verified clean — `import torchgen` succeeds, so not the corrupt-wheel failure recorded in the calibration doc. filters/span_filter.py runs the model on EVERY chunk, unconditionally. There is deliberately no relevance gate in front of it: a pre-filter's false negatives drop content before extraction sees it, and dropped content never reaches expert review to be caught. "Zero candidate spans" is the relevance signal instead. Two mechanical traps handled, both of which silently cost recall: - the model truncates long inputs and WARNS rather than failing, so chunks are fed as overlapping 130-word windows with character offsets remapped. Offsets are walked over the original spacing, never re-joined — re-joining would shift every offset in a chunk containing newlines and break every span check. - the ~12…3a01634 -
[NOTICKET] fix(knowledge_extraction): move runner into the package; fix two ranking defects
Rifqi Hafizuddin +1: Claude Fable 5Runner relocated scripts/run_knowledge_extraction.py -> the package as src/knowledge_extraction/cli.py. scripts/ is gitignored, and this runner is the pipeline's operator entry point, so it has to ship with the module: uv run --no-sync python -m src.knowledge_extraction.cli <artifact.json> pyproject: narrow the T201 lint exemption to that one CLI file rather than all of scripts/, so the ignore traces to this change and nothing else. Two ranking defects found while verifying against the real 9-page BUMA standard (both recorded as deviations V1/V2 in KNOWLEDGE_PIPELINE_CALIBRATION.md §9): V1 — a heading that names the term now counts as a mention at offset 0 for cue-proximity scoring. Indonesian standards are written "2.1.3 Physical of Availability (PA)" / "Adalah ketersediaan fisik...": the heading names the term and the body opens with the definitional cue WITHOUT repeating it, so the definition section earned no cue bonus at all. Measured before the fix, PA's own definition se…72605ff