Migrated from private source issue alphazede/bran-dev#21
Origin
bran-dev — BRAN CLI and ranking. Capability gap, not a defect in shipped
behaviour. Surfaced while answering a real question in the OKF community about
retrieval architecture for large bundle collections.
Harness / version
bran 0.1.0, source commit 0a1de91, branch main.
What
A query is scoped to exactly one repository root, and that root must contain a
.bran/policy.yaml. There is no way to ask one question across several bundles.
query <repo-root> <request> takes a single positional root. There is no
--add-dir or multi-root flag, and pointing BRAN at a directory that merely
contains repositories returns unavailable.
Anyone with more than one repository hits this immediately. It is also the
shape most organisations are in: knowledge spread across many bundles rather
than one very large one.
Current evidence
Container directory holding 13 repositories, 131 GB total:
bran query /path/to/workspace "personal parlay"
status: unavailable
warnings: ["native_policy_unavailable"]
The same question, run per repository, answers correctly:
| repository |
on disk |
candidate corpus |
result |
| A |
6.3 GB |
9.8 MB |
ranks 1-4 are the matching plan directory |
| B |
13 GB |
45.9 MB |
ranks 1-4 are the matching implementation and tests |
| C |
16 GB |
6.0 MB |
0 results, correctly, no relevant content |
Two things this shows. Per-bundle ranking works and filters hard before the
query runs: a 13 GB checkout yields a 45.9 MB candidate corpus because build
artifacts and vendored dependencies never enter it. And the current answer to
"search everything" is to invoke BRAN once per repository.
Merging those results by hand is not safe. Scores are relative to the corpus
that produced them, so a confidence: 50 in one bundle is not comparable to a
confidence: 50 in another. Concatenating and sorting produces a ranking that
looks authoritative and is not.
Expected
One query can span several policy-bearing roots and return a single ranking
that is meaningful across them, without losing determinism or the offline
guarantee.
Acceptance
Origin
bran-dev— BRAN CLI and ranking. Capability gap, not a defect in shippedbehaviour. Surfaced while answering a real question in the OKF community about
retrieval architecture for large bundle collections.
Harness / version
bran 0.1.0, source commit0a1de91, branchmain.What
A query is scoped to exactly one repository root, and that root must contain a
.bran/policy.yaml. There is no way to ask one question across several bundles.query <repo-root> <request>takes a single positional root. There is no--add-diror multi-root flag, and pointing BRAN at a directory that merelycontains repositories returns
unavailable.Anyone with more than one repository hits this immediately. It is also the
shape most organisations are in: knowledge spread across many bundles rather
than one very large one.
Current evidence
Container directory holding 13 repositories, 131 GB total:
The same question, run per repository, answers correctly:
Two things this shows. Per-bundle ranking works and filters hard before the
query runs: a 13 GB checkout yields a 45.9 MB candidate corpus because build
artifacts and vendored dependencies never enter it. And the current answer to
"search everything" is to invoke BRAN once per repository.
Merging those results by hand is not safe. Scores are relative to the corpus
that produced them, so a
confidence: 50in one bundle is not comparable to aconfidence: 50in another. Concatenating and sorting produces a ranking thatlooks authoritative and is not.
Expected
One query can span several policy-bearing roots and return a single ranking
that is meaningful across them, without losing determinism or the offline
guarantee.
Acceptance
they are not and declines to interleave them.
does not silently drop it from a multi-root result.
reads; identical inputs produce identical output.