Weak signal
- Component identified in vague terms (the app, the platform).
What this question asks
Part 1 of 4 - Permitted Purpose.
The first thing an auditor asks: what, specifically, are you claiming? Vague answers like 'the platform' or 'the app' fail before the technical merits are evaluated. This question forces the engagement to name a component with version range, scope, and owner.
Why it is on the rubric
Statute: 26 U.S.C. § 41(d)(1)(B)(ii) and § 41(d)(3).
This question implements Permitted Purpose from 26 U.S.C. § 41(d)(1)(B)(ii) and § 41(d)(3). The binder scores every claimed business component against this question and pairs the answer with cited evidence from your repositories.
Evidence the binder accepts
These are the artifact types the binder ingests to answer this question for a given business component.
- Git commit history (subjects, SHAs, file paths)
- Pull request titles
- Design documents (internal)
- Issue tracker tickets and labels
What weak vs strong evidence looks like
Weak evidence does not disqualify the component on its own; the binder will flag the gap and ask for a stronger artifact if one exists.
Strong signal
- Component named with version, scope, and observable boundary.
Other rubric questions under Permitted Purpose
All questions under Part 1 (Permitted Purpose) score the same business component:
Get documentation built to survive an exam
R&D Binder answers all 11 rubric questions for every claimed business component, with PR-number evidence and an audit-defense flag review.