Measured Behaviour
Published
Two options sit on the same commitment object. One reverts to something narrower than your agreement and fails so loudly that somebody telephones that afternoon. The other reverts to something more permissive and produces the single most common cost-sharing finding there is, in silence. We measured both, and then both together.
A match that was met, and the two ways to break it
We built a cost-share commitment the way a real one is shaped: sponsor spending of 950,000 dollars, a committed match of twenty-five per cent of total project cost, three countable sources, in-kind contributions valued at what was actually evidenced rather than what was claimed, in-kind capped at forty per cent of the match, unrecovered indirect excluded, and five of the thirty-three contributions themselves paid for out of another federal award.
The correct run counts 332,420.00 against a required 320,605.00 and reports the match met, with 390,560.00 rejected: ten contributions from sources the agreement does not admit, two refused because they are federally funded, and seven certified after the commitment closed. Federal dollars counted: zero.
Protection alone, on all five profiles, produced identical behaviour. The rest came from member renaming reaching the commitment object, which is what a regexp like ^(allowFederalSource)$ or a broad RenameMembers pattern over a configuration literal does; the scoping mechanics are in Protect Members.
The loud half: a narrower default breaks the match immediately
The agreement admits institutional funds, third-party cash and in-kind contributions. The library admits one source - the recipient's own money - because that is the only contribution a library can be certain counts.
Renaming the countable-source list therefore reverts to something narrower than the agreement rather than wider, and the run was rejected: 223,500.00 counted against 293,375.00 committed. The match failed. The institution is in breach of a commitment it wrote into its own proposal, and it finds out the moment the run completes.
That is a bad afternoon and a good outcome. Nothing was mischarged, nothing was misreported, and the failure is in the one direction that gets fixed.
The quiet half: 26,700 dollars of somebody else's award
The neighbouring option says whether money from another federal award may count toward this award's match. It may not, and this commitment says so. The library's default is the opposite, and it has to be - a library cannot know which of your funds are federal.
Renaming it counted 359,120.00 instead of 332,420.00 and reported the match met. Two contributions worth 26,700.00 dollars, paid for out of another agency's award, were counted as this institution's own contribution.
Nothing refused, nothing warned, and the institution's own commitment check passed - it is a sufficiency test over the counted total, and every arm that widens what counts makes it pass more comfortably rather than less. Whether a given dollar is a countable dollar is precisely the judgement that was delegated to the engine, and a rule cannot audit the delegation it depends on.
This is the classic cost-sharing finding. The money is real, it was really spent on this project, and it is simply not this institution's to pledge.
The pair was identical to the loud half
Renaming both options together produced 223,500.00 counted against 293,375.00 committed, and a rejected run - byte-identical to the narrow-source arm alone.
The reason is mechanical. With the source list gone, only institutional money counts at all, and every federally funded contribution in the ledger came in as third-party cash or in kind. Whether federal money would have been allowed never arises, because none of it is countable in the first place.
So a member pattern wide enough to reach both keys produces a loud, immediate, unmistakable failure. A pattern narrow enough to reach only one of them produces a match that passes with somebody else's federal money in it. The careful pattern is the dangerous one, and it is dangerous precisely because it is careful.
Two more names, and one of them removes the commitment entirely
In-kind contributions on this award are worth what somebody evidenced them to be worth. Renaming the valuation basis reverted to the library's claimed basis, where the donor's own figure is taken as given: in-kind counted went from 11,220.00 to 87,800.00 and the total counted match to 409,000.00. The match still passed, with 76,580.00 dollars of unevidenced value in it.
And the ratio itself. Renaming the committed percentage reverts to the library's zero, so the required match went from 320,605.00 to 0.00 and the run reported the match met - which it is, trivially, against a commitment of nothing. An award can be closed out on that basis having never made the contribution it promised, and the report says met.
The in-kind ceiling, by contrast, moved no money at all: the in-kind counted in the correct run is far below forty per cent of the match, so removing the cap changed only a printed configuration line. Another half that looks inert, in a file where inert halves have already proved not to mean much.
What to do about it
The same three steps as everywhere else in this series, and none of them involve protecting the code less.
Exclude the commitment literal from the member pattern. A list of countable funding sources is not a secret, and it is the most load-bearing object in the file.
Assert the composition, not the verdict. The correct run reports the counted match by source, the number rejected for each reason, and the federal dollars counted. A test pinning federal dollars counted at zero fails on the quiet arm; a test pinning only met equals true passes on every arm in this article except the two loud ones.
And plan the rollout so a configuration object is never in the blast radius by accident. The staged approach in How to Roll Out JavaScript Obfuscation Without Breaking Production is written around exactly this kind of scoping decision.
Frequently asked questions
Did obfuscation change whether the match was met?
Not by itself. On all five profiles the protected bundle settled the same thirty-three contributions to the same result as the original. The differences came from member renaming reaching the names on the commitment object.
Why did one option fail loudly and its neighbour silently?
Because the library's substituted defaults point in opposite directions. The countable-source list reverts to something narrower than the agreement, so genuine contributions stop counting and the match fails. The federal-source prohibition reverts to permissive, because a library cannot know which of your funds are federal, so another agency's money starts counting.
What happened when both were renamed together?
The result was identical to the narrow-source arm alone: 223,500.00 counted against 293,375.00 committed, and the run rejected. With the source list gone only institutional money counts, so the question of whether federal money is allowed never comes up.
How much federal money was counted in the quiet arm?
Two contributions worth 26,700.00 dollars, taking the counted match from 332,420.00 to 359,120.00. The match was reported met and the institution's own commitment check passed.
Would our commitment check have caught any of it?
Only the arms where the match actually failed. The check we modelled is a sufficiency test over the counted total - did enough non-sponsor money arrive - which is the rule finance offices really write. Every arm that widens what counts makes that test pass more comfortably.
What is the worst single rename in the file?
Renaming the committed ratio. It reverts to zero, so the required match becomes 0.00 and the run reports the match met against a commitment of nothing, while the contributions themselves are counted and reported exactly as before.
How do we scope renaming so this cannot happen?
Exclude the commitment configuration literal from the member pattern, and pin the counted match by source and the federal dollars counted in a test. The option and regexp mechanics are documented in Protect Members.
Related reading