Resource review & selection
A five-check gate for reviewing directory resources
Test a transparent include, hold, or exclude rule against 12 controlled resource records, with the complete fixture available as JSON and CSV.
A directory becomes difficult to trust when a reader cannot tell why one resource was included and another was left out. This study asks a narrow question: can five observable checks produce repeatable include, hold, or exclude decisions for a small resource-directory fixture?
Yes, for the 12 controlled records in this fixture. The fixed rule classified four records as include, four as hold, and four as exclude. That balanced result was designed into the fixture so each route could be inspected; it is not evidence that real candidate pools divide evenly.
Question and observed result
The test applied the same five fields and the same ordered decision rule to every record. No total score, weighting, popularity signal, or later judgment was used. A record could not compensate for a missing direct source by passing unrelated checks.
The output matched the fixture's intended branches: records 01–04 met all five checks, records 05–08 contained one unresolved value, and records 09–12 failed task fit or direct sourcing. The raw records expose every input value and reason so another reader can reproduce the classifications.
| Decision | Records | Meaning in this fixture |
|---|---|---|
| Include | 4 | All five checks are yes |
| Hold | 4 | No exclusion trigger; at least one value is unresolved |
| Exclude | 4 | Task fit or direct sourcing is no |
Controlled test conditions
Run date: September 16, 2026. Dataset version: 1.1.0. Corpus: 12 fictional candidate records written specifically to exercise the decision branches. Each record supplies a short scenario and one value—yes, no, or unknown—for every criterion.
The classifier checks the two exclusion fields first. If neither excludes the record, it checks for any value other than yes; such a record is held. Only an all-yes record is included. Automated tests read the published JSON, recompute all 12 decisions with that classifier, and compare JSON with the downloadable CSV.
Five observable selection checks
These checks are deliberately small. They make a shortlist reviewable without pretending to measure every kind of usefulness. A real editor would still need subject knowledge, current source observations, and a reason for serving a particular audience.
| Field | Question | Why it is recorded |
|---|---|---|
| Task fit | Does it name a concrete task? | Connects the listing to a reader's next action |
| Direct source | Is the material published by its stated maintainer? | Keeps copies and roundups from replacing primary material |
| Maintainer named | Is responsibility for the material identifiable? | Makes provenance inspectable |
| Access checked | Was sign-in or payment status observed? | Prevents an unsupported access promise |
| Limits recorded | Is a scope or applicability boundary stated? | Keeps a useful resource from being presented as universal |
The ordered decision rule
1. Exclude: if task_fit or direct_source is no. 2. Hold: otherwise, if any criterion is no or unknown. 3. Include: only when all five criteria are yes.
The order matters. A direct-source failure produces an exclude decision even when every other field is complete. An unknown direct-source value produces a hold because the editor has not established the failure. The rule records uncertainty instead of converting it to a favorable score.
Record-by-record results
The table shows the five input values in the order above. Each title is a fictional fixture label rather than a reviewed external resource.
| ID | Fictional candidate | Task | Source | Maintainer | Access | Limits | Decision |
|---|---|---|---|---|---|---|---|
| 01 | Form pattern reference | yes | yes | yes | yes | yes | include |
| 02 | Deployment checklist | yes | yes | yes | yes | yes | include |
| 03 | Content audit worksheet | yes | yes | yes | yes | yes | include |
| 04 | API response guide | yes | yes | yes | yes | yes | include |
| 05 | Layout troubleshooting guide | yes | yes | yes | unknown | yes | hold |
| 06 | Research planning template | yes | yes | unknown | yes | yes | hold |
| 07 | Error-message examples | yes | yes | yes | yes | unknown | hold |
| 08 | Keyboard testing steps | yes | unknown | yes | yes | yes | hold |
| 09 | Design inspiration stream | no | yes | yes | yes | yes | exclude |
| 10 | Copied standards summary | yes | no | yes | yes | yes | exclude |
| 11 | General tools roundup | no | no | yes | yes | yes | exclude |
| 12 | Unscoped idea gallery | no | yes | yes | yes | yes | exclude |
Download and reproduce the fixture
Download the complete JSON evidence record for the criteria, scenarios, rule, output reasons, limitations, and correction history. Use the CSV decision table for a spreadsheet or a small analysis script.
To reproduce the result, read each row, apply the exclusion check first, then the unresolved-value check, and finally the all-yes inclusion check. Compare the computed decision with the published decision field. A different result indicates either a transcription error or a different rule.
Limitations
This fixture measures whether one small rule is applied consistently to designed inputs. It does not compare live resources, measure reader outcomes, establish source quality, or prove that these five criteria are sufficient for every directory.
The equal four-four-four split is a test design choice. Real candidate sets may contain any distribution. A production review must inspect the current original source, preserve the observation date and notes, and revisit records when access, ownership, or scope changes.
Version and correction history
Version 1.1.0 — September 16, 2026: added the scoped CC0 1.0 reuse statement and machine-readable license metadata. The fixture records, criteria, and decisions did not change.
Version 1.0.0 — September 16, 2026: initial publication. No data corrections were recorded. Future substantive corrections will retain these entries and add a dated note describing what changed; silent build time will not advance the version or dates.