How we audit the Affiliate Pledge.
The Affiliate Pledge commits us to running a review every quarter and publishing what it finds. It also says, of reordering cards by what we would earn, that "the quarterly audit is designed specifically to catch this."
That sentence claims a procedure exists. This is the procedure.
It is published before the audit it governs rather than alongside it, because a method written after an audit describes what somebody did, and a method written before is something the audit has to follow. The pledge claims the second.
What this is not
One person runs it. It is not an external audit, it carries no auditor's opinion, and it is not an assurance engagement. It is a stated procedure, executed on a stated cadence, with the result published whatever it says.
Each check below states what it cannot establish. That is not a disclaimer. A check whose limits are unstated is a check nobody can rely on, and the limits are the part that tells you what the result is worth.
The checks
1. Did affiliate revenue arrive
What the pledge claims. Affiliate revenue enters our books at exactly one moment: when you apply for a card through Stack and the issuer pays a referral.
How we check. Read the Affiliate Revenue account in our chart of accounts for the period. Report the balance and every transaction posted to it.
It fails if. Any amount posted there did not come from a card application referral, or any referral revenue is found posted to a different account.
What it cannot establish. That revenue was not received and recorded somewhere we did not look.
Partly mitigated by the posting rule written into the account itself: it receives referral revenue from card applications and nothing else. The account was deliberately created as a new one rather than by renaming an existing default, because renaming a default in our bookkeeping system keeps its automatic categorization attached, which would mean the software decided part of what landed there. We have not directly verified that a newly created account carries none. It is why the account was set up that way rather than a property we have confirmed, and we will say so until somebody checks.
2. Does an affiliate relationship exist
What the pledge claims. We will never take payment from an issuer for placement or preferred treatment. A referral on a successful application is the only payment from an issuer we will accept.
How we check. Confirm whether any referral or affiliate agreement exists with any card issuer, signed or in discussion.
It fails if. An agreement exists, in either state, and the audit does not disclose it.
What it cannot establish. An informal arrangement nobody wrote down. There is currently one person who could make one, and this check is his confirmation on the record. The date of that confirmation is published in the audit, because "no agreement exists" is a claim about a moment and you need to know which one.
3. Can the recommendation engine see payout data
What the pledge claims. The separation is enforced in code. Max does not look at, weight, or factor in any affiliate relationship.
How we check. Search the database schema and the codebase for payout-shaped data: any column, table, configuration value or integration relating to referrals, affiliate arrangements, payouts or commissions. Report the count and any match.
It fails if. Any payout-derived data exists and the recommendation path can reach it.
What it cannot establish. What a future integration will do.
True by absence, not by containment. As of today no payout data exists anywhere in the system. Nothing is keeping it out of the recommendation engine; there is nothing to keep out, so the question has not arisen. That is a weaker thing than a wall and we will say so in every audit until it stops being true.
The transition. Before any payout data enters the system, a containment mechanism has to exist, and at that point this check changes: it stops asking whether the data exists and starts asking whether the recommendation engine can reach it. Without that sequence there would be a window where the pledge claims a separation backed by neither absence nor mechanism. Building the containment is a precondition of the first affiliate integration, not a follow-up to it.
4. How cards are ordered
What the pledge claims. The order of cards you are shown is determined by fit, not by what we earn.
What we audit. The ordering key for any surface that shows you cards you do not already hold. We name it that way rather than naming a specific database field, because a field can be renamed during a build for reasons unrelated to this check, and a check pointing at a renamed field passes for the wrong reason.
Today that subject is the ordering key on the add-a-card library, which serves onboarding and the add-card flow, currently the only two places you are shown cards you do not hold. If that changes, this line changes and the check does not.
How we check. Identify the ordering key in force, and report one of two states:
- The key is unset, so the order falls back to a stated default. It is currently unset on all 24 cards, so the live order is alphabetical.
- The key is set, and we name the source it was set from, which must not be derived from payouts.
It fails if. The key is set with no stated source, or from any source derived from referral value, payout, or an issuer relationship. It also fails if no ordering key can be identified for a surface showing unheld cards, because a key nobody can identify cannot be audited.
What it cannot establish. Intent. It establishes where the ordering came from, which is the checkable thing. An ordering with an honest source can still be a bad ordering. It cannot be a payout-weighted one without this audit saying so.
On Explore Cards. The pledge names a feature that is not built. The add-a-card library is the same subject under a different name and it exists now. When Explore Cards ships, its ordering joins this check rather than replacing it.
5. What Max is given
What the pledge claims. Max has no awareness that Stack could make affiliate money. The pledge calls this its load-bearing line.
How we check, two ways.
What we supply. A standing test asserts over the assembled input that actually reaches the model, the instructions, the tools and their descriptions, the data those tools return, and the conversation, rather than over the files those are built from. It fails if any affiliate reference appears in any of them.
What Max says. We ask Max whether Stack earns money when somebody applies for a card. We ask it several ways, because one phrasing tests one path and the claim is about all of them, and we publish the phrasings we used so you know what was asked rather than trusting it was asked well.
It fails if. The assembled input contains an affiliate reference, or Max asserts that Stack earns, or could earn, money from card applications.
It does not fail if Max declines to answer, says it does not know, or says it has no information about how we make money. The pledge claims an absence of awareness, so the failing observation is Max asserting the fact, not Max failing to deny it.
Why we ask at all. A language model with general knowledge of this industry could answer that question correctly from its own training rather than from anything we supplied. If that happens, everything we supply is clean and the sentence on the pledge is still wrong, by a route no code search reaches.
What we would do about it, decided in advance. That outcome needs the pledge reworded rather than the code changed, and the worst moment to write a sentence like that is while holding a failed check. So it is written now. "Max has no awareness that Stack could make affiliate money" would become:
Nothing Stack provides to Max references affiliate revenue, and no affiliate consideration enters what Max is given.
That claims something about what we supply rather than about what the model knows. The second is not ours to control and would fail the same test again.
If we ever make that change, the version history will say the previous claim was found inaccurate by this check and replaced with one we can establish. It will not say we clarified the wording, because that would not be true. Every prior version of the pledge stays readable at its own address, so you can see the broader claim and the narrower one side by side, and the reason for the change will be there rather than an unexplained retreat.
What it cannot establish. What the model knows. It establishes what we supply, and what Max says when asked several ways.
Publishing the result
The result publishes on the Affiliate Pledge as a new version, whatever it says. A failing check publishes as a failing check. The pledge commits us to publishing the result, not to the result being clean, and an audit that only publishes when it passes is not an audit.
Every published audit states its period as dates rather than as a quarter label, names which checks applied and which did not, and says why for any that did not.
When
Every audit publishes within 14 days of its quarter closing.
The pledge commits to a quarterly review and to publishing the result, and does not say how long after the quarter the result should appear. Without a number, late has no meaning, which means the commitment cannot be missed and cannot be met either. Fourteen days is generous at our size.
The next audit covers 4 August to 30 September 2026 and publishes no later than 14 October 2026.
Changing this method
Adding a check is additive and we will do it when we find something worth checking. Removing a check, or narrowing one, is a reduction in something we published, and it goes through the same review the pledge does before it happens.
This page is where the method lives. It is not part of our Terms of Service. The Affiliate Pledge carries the commitment; this describes how we keep it.