+**MOTIVATION**
+
+Aside of per-release activities (release report), CSIT also provides testing
+that requires somewhat tight coupling to the latest (merged but not released)
+VPP code. Currently, the coupling is not as tight as possible.
+Instead of testing HEAD builds of VPP directly with HEAD CSIT code,
+HEAD of one project is run with somewhat older codebase of the other project.
+Definition of what is the older codebase to use is maintained by CSIT project.
+For older CSIT codebase, the project creates so-called "oper" branches.
+For older VPP codebase, CSIT master HEAD contains identifiers
+for "stable" VPP builds. Such older codebases are also used for verify jobs,
+where HEAD of the other project is replaced by the commit under review.
+
+One particular type of jobs useful for VPP development is trending jobs.
+They test latests VPP build with oper branch of CSIT,
+and analytics is applied to detect regressions in preformance.
+For this to work properly, VPP project needs a warning against breaking
+the assumptions the current oper branch makes about VPP behavior.
+In the past, the most frequent type of such breakage was API change.
+
+Earlier attempts to create a process to minimize breakage have focused
+on creating a new verify job for VPP (called api-crc job) that
+votes -1 on a change that affect CRC values for API messages CSIT uses.
+The list of messages and CRC values (multiple values are allowed)
+is maintained in CSIT repository (in oper branch).
+The process was less explicit on how should CSIT project maintain such list.
+As CSIT was not willing to support two incpompatible API messages
+by the same codebase (commit), there were unavoidable windows
+where either trenging jobs, or CSIT verify jobs were failing.
+
+Practice showed that human (or infra) errors can create two kinds of breakages.
+Either the unavoidable short window gets long, affecting a trending job run
+or two, or the api-crc job starts giving -1 to innocent changes
+because oper branch went out of sync with VPP HEAD codebase.
+This second type of failure prevents any merges to VPP for a long time
+(12 hours is the typical time, give time zone differences).
+
+The current version of this document is still being somewhat vague
+on the CSIT side of the process, but introduces a new requirement:
+The api-crc job should not give false -1, under any reasonable circumstance.
+That means, if a VPP change (nor any of its unmerged ancestor commits)
+does not affect any CRC values for messages used by CSIT,
+-1 should only mean "rebase is needed", and rebasing to HEAD should result
+in +1 from the api-crc job.
+