Adr16 high level regime abstractions #512
Conversation
Codecov Report
@@ Coverage Diff @@
## master #512 +/- ##
==========================================
+ Coverage 92.60% 92.61% +0.01%
==========================================
Files 298 298
Lines 18441 18455 +14
Branches 1472 1472
==========================================
+ Hits 17077 17092 +15
Misses 1088 1088
+ Partials 276 275 -1
Continue to review full report at Codecov.
|
|
|
||
| 2. **Low-level tariff changes are not policy-friendly.** Customs rules are often subject to trade policy regimes such as free trade agreements (FTA-s) or most favored nation (MFN) treatment. Trade policies often span multiple commodities and multiple time periods. For example, staging rates in an FTA may define how the duty rate for a given range of commodities imported from the trade partner may decline gradually over the course of several years. This is one policy that needs to be reflected in multiple individual customs rules via individual measures, one for each combination of commodity and validity period. | ||
|
|
||
| - Importantly, this is not a *bulk entry* issue. TaMaTo does provide utilities (e.g. a TARIC envelope importer and a configurable excel importer), which enable bulk load of a large number of data entries at a time. But the source files for bulk entry still need to outline customs rules one measure at a time, and they provide no meta context around the policy regime |
There was a problem hiding this comment.
Well, it’s not just a bulk entry issue. Volume is a component of the problem.
|
|
||
| - there is one of these entities for each measure type, responsible for handling all the peculiarities related to that specific measure type; | ||
| - all measure type entities share a common interface, ensuring the ability to automatically determine diffs vs current database state and apply changes accordingly | ||
| - measure types rarely change, so building up the library of measure type entities should be a one-off investment |
There was a problem hiding this comment.
Hm, this is true now but may not need to be true in the future. It’s only really because we don’t understand the steps necessary with CDS and have been warned it’s not trivial. If we knew more about those steps or could confirm it can be done, we could create more measure types ourselves.
|
Does anyone reading this PR know how much of this was already implemented in notebooks ? |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| The low-level data entry approach for customs rules in TaMaTo imposes a range of costs and operational risks: | ||
|
|
||
| 1. Lowe-level data entry can be *slow and tedious* via both the backend and the UI. This leads to delays in implementation of trade policies at the border (sometimes, these delays are significant and are measured in months). |
| The proposed solution centers on the use of two main abstractions: | ||
|
|
||
| 1. **Measure Type Entities.** These are responsible for managing writes to low-level TARIC-3 model entities of a given measure type, with all the peculiarities that are specific to that measure type | ||
|
|
There was a problem hiding this comment.
^ measure types are mentioned here for the first time - there should be a brief bit of text about them including examples of measure types.
Some of the info in the MeasureType class's docstring seems relevant -
"""
The measure type identifies a customs measure.
TARIC customs measures cover a wide range of information, including tariff
measures (such as levies and anti-dumping duties), and non-tariff measures
(such as quantitative restrictions and prohibitions).
"""
There was a problem hiding this comment.
| - the input data specifications can be literally any specification in any format (strings, json payloads, etc.) | ||
| - policy regime aggregates share a common interface, ensuring the ability to transcode inputs, to provide comprehensive previews of pending changes to validate policy implications, and to apply a policy | ||
| - policy regime aggregates are meant to be invoked directly when implementing tariff changes | ||
| - it is recommended that the aggregates are tested with fearues and scenarios under BDD |
TP2000-170 ADR16 - High-Level Abstractions for Trade Policy Regimes
Why
As part of architectural discussions about the future design directions for TaMaTo, the TAP data team has agreed to open two related ADR-s for discussion - this one on high-level abstractions for trade policy regimes and the other for a new UK trade policy data specification for DIT
What
This PR contains the draft of ADR16.
Recommended to use this link for reading through the formatted ADR before commenting.
NB: Unfortunately, I got to my last day before I could ready this for PR. This means that likely I won't be able to respond to what I'm sure is going to be a wide range of questions and comments. However, I hope it provides a good enough basis for the direction I think this should be taking on! <3