Compliance
In addition to optimizing complex solver problems, Amazolve is also designed to help with compliance and regulatory requirements. A control, in business compliance terms, is something that implements a compliance "check" and Amazolve problem definitions (PDs) can act as controls for the process they are optimizing.
For example, the number of consecutive hours a truck driver (e.g., short haul, or LTL) can drive is strictly regulated by the government. A trucking company needs a system to manage this compliance that tracks driver hours in addition to optimally assigning customer orders and routes to drivers within the constraints of that compliance. These hourly constraints naturally become Amazolve PD constraints for optimization purposes, but also demonstrate to regulators that a control is in place to assign work in a compliant manner. In healthcare and many other sensitive regulated industries, clear demonstrable controls can save millions of dollars in fines, and speed compliance checks by regulators.
Compliance Communicated
Companies have to do more than simply state that they are compliant or that they have controls in place. They have to prove it. To support this, Amazolve has a unique feature that creates seamless documentation across business users, analysts, IT, and regulators: problem definitions (PD) as markdown (MD) files. In other words, the PD file that Amazolve uses can either be a raw JSON file, or an MD file with islands of JSON objects embedded within.
MD files are ubiquitous for documentation on the Web. They are easier to write than HTML, and are designed specifically for writing documentation. A simple Google search for markdown will yield a plethora of tools, guides and examples of markdown. In addition to the text documentation, MD also supports LaTeX which is a language for writing mathematical formulas, and supports embedded JSON islands. In fact, all of the Amazolve documentation (what you are reading now) is built using MD, LaTeX and JSON islands!
When describing compliance to a reviewer, or business user, a single MD file can show the process description, the mathematical constraints, and the constraint definitions as implemented in Amazolve - and that is the actual file that Amazolve uses during it's processing. There is ongoing 100% fidelity of the process from description to implementation.
In this sense, Amazolve solutions are self-documenting, repeatable, and compliant.
In a nutshell:
- Problem and constraint descriptions (narratives) are written in plain text within the MD file.
- Mathematical descriptions of constraints and objectives are written in LaTeX.
- The Amazolve PD constraint is written as a JSON object island within the MD.
- Amazolve is given the entire PD as configuration, and extracts just the JSON islands for the problem definition.
A Complete Example
The following example (everything below the line) is taken from the supply-chain (PBS meaning product breakdown structure) sample. This is of course an MD file so you are viewing it as a viewer would, however you can review the underlying MD file in the sample GitHub repo.
Imagine refering to this as a documented control from your compliance spreadsheet!
PBS Constraints
Constraint 1: One and only one assignment of the site per part:
\( \sum_{i} x_{ri} = 1 \enspace \forall r \)
{
"constraint": {
"CID": "C1",
"comment": "Constraint #1 - One and only one assignment per part",
"penaltyVar": "hardPenalty",
"sumIter": "iterDim",
"iterDim": "R",
"iterVars": [
"r"
],
"exprMain": "EQ(sum_assigned, 1)",
"sums": [
{
"sumIter": "iterDim",
"iterDim": "S",
"iterVars": [
"i"
],
"exprMain": "Xr(r, i)",
"resultVar": "sum_assigned"
}
]
}
}
Constraint 2: Origin and destination for each transport must be different:
\( \sum_{\left(r,s\right)\in\phi}\sum_{i} x_{ri}x_{si} = 0 \)
{
"constraint": {
"CID": "C2",
"comment": "Constraint #2 - Origin and destination must be different",
"penaltyVar": "hardPenalty",
"sumIter": "iterArray",
"arrayName": "phi",
"iterVars": [
"r",
"s"
],
"sums": [
{
"sumIter": "iterDim",
"iterDim": "S",
"iterVars": [
"i"
],
"exprMain": "Xr(r, i) * Xr(s, i)"
}
]
}
}
Constraint 3: The origin of two sub-parts of a common part must be different:
\( \sum_{\left(r,s\right)\in\psi}\sum_{i} x_{ri}x_{si} = 0 \)
{
"constraint": {
"CID": "C3",
"comment": "Constraint #3 - Origins of two subparts must be different",
"penaltyVar": "hardPenalty",
"sumIter": "iterArray",
"arrayName": "psi",
"iterVars": [
"r",
"s"
],
"sums": [
{
"sumIter": "iterDim",
"iterDim": "S",
"iterVars": [
"i"
],
"exprMain": "Xr(r, i) * Xr(s, i)"
}
]
}
}
Objective: Cost in transport between chosen sites must be minimized:
\( C = \sum_{\left(r,s\right)\in\psi}cost(r_a,s_a) \)
{
"constraint": {
"CID": "C",
"sumIter": "iterArray",
"arrayName": "phi",
"iterVars": [
"r",
"s"
],
"sums": [
{
"sumIter": "iterDim",
"iterDim": "S",
"iterVars": [
"i"
],
"sums": [
{
"sumIter": "iterDim",
"iterDim": "S",
"iterVars": [
"j"
],
"exprMain": "cost(r, i, j) * Xr(r, i) * Xr(s, j)"
}
]
}
]
}
}
PBS Constants
Symbol | Description |
---|---|
hardPenalty | Penalty applied to unmet constraints |
{
"constants": [
{
"name": "hardPenalty",
"def": 10000
}
]
}
PBS Arrays
Symbol | Description |
---|---|
cost | A database of costs of moving a given part between two locations |
phi | The product breakdown structure's parent/child part relationships |
psi | The product breakdown structure's sibling part relationships |
[
{
"array": {
"name": "cost",
"file": "array_cost.json"
}
},
{
"array": {
"name": "phi",
"file": "array_children.json"
}
},
{
"array": {
"name": "psi",
"file": "array_siblings.json"
}
}
]
PBS Atoms Configuration
A standard random initialization of the atoms is used and random mutations (or permutations) are applied during the search process. In addition, the atoms are intialized externally, depending upon the size of the part list and number of locations.
[
{
"params": {
"initializeType": "Random",
"mutatorType": "Random"
}
},
{
"atoms": {
"file": "atoms.json"
}
}
]