sam-at-luther
commented
2 months ago Towards this, we need a super minimal ICS-lite, that essentially has 5 orgs: 1) Local OE (HOE) Claim Team, 2) Originating OE (OOE) Claim Team, 3) Local OE (HOE) Finance Team, 4) OOE Finance Team, 5) OOE Payment team.
Ignoring the connectors for now (which will be used to later call these API endpoints), we need the system to execute the following 5 steps, in this order, using this participant sequence:
- HOE Claim Team: collect and validate claim
- OOE Claim Team: review & update & validate claim
- HOE Finance Team: issue invoice
- OOE Finance Team: review & approve invoice
- OOE Payment team: collect payment details & make payment
I suggest each of these steps is a separate API endpoint ,and phylum endpoint. Make assumptions based on the data model, using ICS data model as inspiration, but we really only need a few fields (like 3 or 4). Don't worry about field validation, or user authentication / authorization for this first pass, we can add that later and it doesn't really show up in the demo.
We do need an endpoint to look up an event log (similar to BOA), to show how process evolves over time. Every step results in a new event in the log. Don't worry about separate domains / chaincode, this is all a single domain. Simplicity is the goal, while still being a meaningful business process.
We need a postman test that pumps through an entire claim lifecycle, and looks up the event log (BOA) at the end.
As follow up we'll add the connectors listed above , field validation, a basic UI showing a dynamic event log for a claim, and user auth.
Right now the sandbox application is a banking/finance example, where users have accounts denominated in some token class, and they can send tokens from one account to another.
We need the application to instead be claims, to better storytell the value of the platform, and more closely match the future use-cases we're interested in.