ENGINEERING NOTE 49 / 50 · CARD
Separate product capabilities from engineering examples
An architecture article can describe a good design without claiming the product exposes that API or feature today. Label examples and verify commercial claims separately.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Use a capability register
For every public feature claim, record the user-facing evidence and any account or product limitation. A backend adapter existing in source code does not establish customer access, contractual eligibility or universal merchant acceptance.
Label pseudocode
Use generic operation names in educational examples and say they are not a documented product endpoint. Link readers to the current product view for availability and fees. Do not publish invented endpoint paths as copy-and-paste integration instructions.
Keep claims narrow
A card platform’s distribution role is different from being the licensed issuer. A successful test is different from a guaranteed success rate. Explain the actual product boundary instead of borrowing the authority of a network, merchant or infrastructure provider.
Illustrative implementation
claim = {"feature":"example", "evidence":"public product view",
"scope":"specific product", "reviewed_at":date}Acceptance check
Review every call to action against the current product. Remove claims supported only by a hypothetical architecture diagram.