fix(oia): count scan-cap truncation separately from scaffolding (#64), and add future-agi/future-agi to pending

[michaeloboyle]

Two commits: a reporting-accuracy fix in the classifier, and the matrix row that
surfaced the bug.

Closes the first defect in #64. Audit tracker for the row itself: #62.

1. fix(oia): scan-cap truncation is not scaffolding

buildCorpus computed dropped against the pre-cap path length, so it summed two
unrelated quantities: paths removed by denoisePaths, and paths discarded by a
hardcoded 6,000-path cap. Both callers then rendered that total as
(N scaffolding paths excluded).

Measured on future-agi/future-agi:

Quantity	Value
raw paths	12,455
GitHub truncated flag	false
actually scaffolding	58
beyond the scan cap, never read	6,397
previously published as "scaffolding excluded"	6,455

A scaffolding count overstated by roughly 110x, on a governance artifact whose entire
purpose is evidence-tiering credibility, and it concealed that only 48% of the repo was
read at all.

Latent until now: every prior submission was smaller than the cap, so dropped was 0
and the parenthetical never rendered. This is the first submission large enough to trip
it.

Fix. buildCorpus returns dropped (scaffolding only) and truncated (cap
overflow) as separate counters. With kept they partition the input, which is pinned
by a test. SCAN_CAP is exported rather than inlined, so the reported number and the
actual behaviour cannot drift. Both callers, scripts/classify-oia.mjs and the page's
Rescan path, report them separately and name the cap.

Before: Heuristic file-tree scan of 6000 files (6455 scaffolding paths excluded)
After: Heuristic file-tree scan of 6000 of 12397 project files (58 scaffolding paths excluded; 6397 beyond the 6000-file scan cap, not read)

This is a reporting change only. No signal map, threshold, or corpus content
changed. The golden-vector tests are untouched and still pass, so no row's placement
moves.

2. The matrix row

One row in the pending band for
future-agi/future-agi: Apache-2.0,
~2.1k stars, bundling simulation, evals, guardrails, OpenTelemetry tracing, an
OpenAI-compatible gateway, and prompt optimization. It reached us as a direct
contribution invitation from the company's CEO, so it is funnel input rather than
personal correspondence.

Generated by scripts/add-pending.mjs, not hand-authored. status: pending,
evidence.t: auto.

issue is null on purpose. The project was not self-submitted, so the submission
form's submitter fields would be attributed to the wrong person. #62 tracks the audit
but is not a submission record.

Read this before promoting the row

The row sits on L2, L3, L4, L5, L6, L7 and L9 at centre-of-gravity level, with zero
presence-level layers. That vector is not trustworthy, for a reason this PR does
not fix:

full vector:      0,0,2,2,2,2,2,2,0,2
tree-only vector: 0,0,1,1,1,1,1,1,0,1
doc-only vector:  0,0,2,2,2,2,2,2,0,2   <- identical to full

The 6,000 scanned file paths contributed nothing. A 24,330-character README produced the
entire placement, because classifySignals promotes on all >= 3 && doc >= 1 while
all = tree + ' ' + doc, so the corroboration guard is satisfiable from prose alone.
That is defect 2 in #64. It moves placements on every auto row, so it belongs to a
deliberate committee-informed re-classification, not to this PR.

Qualification gate as detected: issues yes, docs yes, infographic yes, ADRs no,
PRD no. Under @mrjcleaver2's proposed criteria that fails two of three documentation
requirements. Committee call, not a classifier call.

One further note for the committee: this is an evaluation and measurement vendor
whose public accuracy claims carry no stated baseline. Listing a measurement tool means
downstream users can inherit its metric definitions as their own gold standard. Listing
is not endorsement of its numbers, but we should know which we are doing.

Verification

• Red-first: all three #64 assertions failed against the old counters before the
  fix. npm test now 164/164 pass, 0 fail. The pre-existing 161 were unaffected
  throughout.
• Ground truth reconciles: 58 + 6,397 + 6,000 = 12,455, the exact measured path
  count for the repo.
• No placement drift: the regenerated row's layer vector is byte-identical to the
  pre-fix one. Only the narrative and evidence text changed.
• curated[] byte-identical at 20 entries; pending[] 5 to 6; no duplicate names.
• CI test check green on this branch.
• The earlier adversarial pass on the data-only version returned PARTIAL, and this PR is
  the remediation of the finding that drove it.

Row anchor once deployed:
https://agenticsorg.github.io/community-projects/oia-matrix.html#oia-future-agi-future-agi

[michaeloboyle]

Moving this to draft. Two corrections, one of which I got wrong twice.

Adversarial verification returned PARTIAL on this branch. All six mechanical claims hold (diff is exactly two files, curated[] byte-identical at 20, npm test 161/161, row anchor renders behaviorally with zero page errors). The block is a factual defect in the committed bytes, now filed as #64.

1. The row publishes a false number

evidence.n says (6455 scaffolding paths excluded). Measured ground truth for this repo:

Quantity	Value
raw paths	12,455
API truncated flag	false
actually removed by denoisePaths	58
discarded by the hardcoded .slice(0, 6000) cap	6,397
published as "scaffolding paths excluded"	6,455

buildCorpus computes dropped against the pre-cap length, so it sums de-noising and truncation and the narrative attributes all of it to scaffolding. The row therefore overstates the scaffolding count by roughly 110x and hides that only 48% of the repo was scanned. On a governance artifact whose whole purpose is evidence-tiering credibility, that should not ship.

Latent until now: the other five pending rows all have dropped = 0, so the parenthetical never rendered. This is the first submission large enough to trip it.

2. My layer-vector explanation was wrong, in both directions

First I called the seven-layer vector monorepo signal saturation. Then I posted controls (slugify all-zero, django/django zero centre-of-gravity at the same 6,000-file cap) and concluded the breadth was therefore probably real. The controls were sound but the conclusion did not follow. Instrumenting the classifier directly:

full vector:      0,0,2,2,2,2,2,2,0,2
tree-only vector: 0,0,1,1,1,1,1,1,0,1
doc-only vector:  0,0,2,2,2,2,2,2,0,2   <- identical to full

The 6,000 scanned file paths contributed nothing. The entire placement comes from a 24,330-character README. classifySignals promotes on all >= 3 && doc >= 1, but all = tree + ' ' + doc, so both halves of the guard are satisfiable from prose alone. The doc >= 1 clause was meant to stop file paths asserting an unclaimed centre of gravity; because doc is folded into all, it corroborates nothing.

That also explains the zero layers at level 1 signature: every group either cleared 3 hits in the README or found nothing at all.

So the vector is over-broad after all, and the narrative's "Heuristic file-tree scan of 6000 files" actively points readers at the wrong basis for a placement the file tree did not influence.

What happens next

Parked in draft until #64's first defect is fixed, then this row gets regenerated with honest counts. Defect 2 changes placements for every auto row in the matrix, so that one is a deliberate committee-informed re-classification, not a silent recompute, and it does not gate this PR.

[Copilot]

Copilot review overview

🟡 Changes recommended

The new matrix row’s narrative text is misleading (“from a submission”) despite issue: null and the PR description indicating it was not self-submitted.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Narrative incorrectly says auto-classified from a submission · New

What changed in this PR

Adds future-agi/future-agi as a new pending entry in the OIA application matrix, along with a generated README badge, aligning with the intake pipeline that auto-classifies repos and queues them for committee review.

Changes:

• Appends a new pending row for future-agi/future-agi in docs/data/oia-matrix.json with layers, spans, evidence, and narrative metadata.
• Adds the corresponding badge SVG at docs/badges/future-agi/future-agi.svg for embedding and row linking.

File	Description
docs/​data/​oia-matrix.json	Adds the new pending matrix entry for future-agi/future-agi (layers/spans/evidence/gaps).
docs/​badges/​future-agi/​future-agi.svg	Adds the generated OIA badge for the new matrix row.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.