April 2026 to March 2027
Every COD annual update starts as a stack of technical references, sample XML, meeting notes, and open questions. This page shows how those inputs became a shared product narrative and a set of interactive artifacts the team could use.
Built from COD schema, sample, report, and implementation questions.
Discovery, report interpretation, Direct Loan logic, Workforce Pell, and internal rules.
A single place for teams to review the work instead of chasing scattered PDFs and notes.
The requirement itself is only the starting point. The harder work is cross-verifying it, identifying what changed from the prior cycle, deciding which teams are affected, and creating artifacts that let stakeholders see the same answer without needing to reconstruct the research.
The first challenge in an annual COD cycle is not coding. It is getting everyone to see the same change at the same level of detail. The schema and sample comparisons turn a new technical reference into a shared map of what moved, what was added, and where the risk sits.
Element-by-element comparison between 2025-26 and 2026-27 schema behavior.
This is the first pass at turning a new COD cycle into something actionable. It identifies the new or changed XML surface before the team starts debating implementation details.
Side-by-side sample payload review so the schema changes feel concrete.
A schema diff tells the team what changed. A sample comparison shows what that change looks like inside a real COD-style record, which is where implementation questions usually become obvious.
Volume 6 is where report behavior becomes operational. The changelog and explorer make import-report changes reviewable by product, engineering, QA, support, and implementation without asking everyone to navigate the source document from scratch.
Import-report changes grouped by what was added, changed, or removed.
This turns a long technical reference into a reviewable change log. It is meant to help teams decide what needs a code change, what needs a test case, and what only needs release-note visibility.
An explorable dashboard for the 2026-27 import-report surface.
The explorer is the artifact people use after the first read. It lets someone jump to the report surface they care about instead of searching through a large PDF every time a question comes up.
The field-logic artifacts show the second half of product work: once a requirement is known, the team still needs source-of-truth rules, export timing, validation behavior, and testable examples.
How packaged Enrollment Intensity is captured, capped, and exported for Direct Loans.
Enrollment Intensity is a good example of the annual-update problem: the field exists, but the team still needs to know which source value wins, when it applies, and how to test term and non-term cases without overbuilding the rule.
Visual logic for when InstitutionalLimitApplied should be reported on Direct Loan exports.
This artifact documents the decision boundary between a configured institutional limit and the actual COD export value. The useful part is not the tag name. It is the timing and omission behavior that keeps the export clean.
Reference for 2026-27 StudentLevelCode changes, including two-character values.
This is the kind of small data-shape change that can create outsized implementation risk. The artifact makes the new grade-level codes explicit and helps teams avoid formatting assumptions left over from one-character values.
Workforce Pell creates a cross-product workflow where program configuration, eligibility flags, and COD export behavior have to line up. The artifact keeps those concepts separate so the team can test the right thing.
Some artifacts are useful to internal teams because they describe supported message-class behavior. Those are kept behind a lightweight password gate because they are meant for a smaller audience, not because the site is treating the gate as high-security access control.