KCIDB Cleanup

The KCIDB schema allows for a lot of flexibility, but that can easily become inconsistency when we are talking about a relational database. Recently, when we started working on features a little bit more complex than listing objects, we realized we had to handle too many corner cases, which were frequently related to incomplete or malformed data.

In order to expedite future features minimizing technical debt for the development team, we'd like to add more restraints to the protocol, creating a stricter policy around what will be inserted in the database, which will require a feedback loop to the submission origins, to notify them about rejected payloads.

We believe that, instead of a nuisance, this will be valuable for them! In addition to the aforementioned "expedited future features", they'll have more confidence that once their data is successfully consumed, it will appear correctly in all reports available in the dashboard.

Action Items:

• Discuss strict validation of KCIDB with origins
• Prepare feedback loop system
• Deploy strict validation

Start by reviewing the KCIDB schema and how submissions from origins are consumed into the relational database. Map the three stated action items: agree on strict validation, define feedback for rejected payloads, and deploy the validation. Done means malformed or incomplete payloads are rejected and their origins are notified.