Intro and a diagram

doc/architecture-new.md

@@ -5,27 +5,60 @@ This document describes the design of the regulated stablecoin proof-of-concept
 ## Overview
 
 The POC consists of two components that make up the functionality of the regulated stablecoin.
-The first component is CIP-XXX (TODO: Cip No. and link), which gives us a unified standard for managing different programmable tokens, comparable to some of the better-known ERC standards on Ethereum.
+The first component is [CIP-0143](https://github.com/colll78/CIPs/tree/patch-3/CIP-0143), which gives us a unified standard for managing different _programmable tokens_, comparable to some of the popular ERC standards on Ethereum.
+
 The second component is a concrete instance of such a programmable token, namely a policy that checks each transfer of tokens in its domain to ensure that the sender is not on a list of sanctioned addresses.
 The policy also allows the issuer of the programmable token to seize funds from sanctioned addresses.
+We will call this policy the Access Control Policy (ACP).
+
+### CIP-0143
+
+At its core, CIP-0143 describes a registry of programmable token policies and a mechanism for finding the right script whenever one of the programmable tokens is minted, burned, or transferred to another user.
+
+```mermaid
+---
+title: Relationship between CIP-0143 and Access Control Policy
+---
+
+flowchart LR
+  cip[CIP-0143]
+
+  policy[Access Control Policy]
 
-TODO: Diagram relationship CIP/policy
+  other_policies@{shape: procs, label: "Other policies"}
+  style other_policies fill:#eee;
 
-Both components are implemented in Plutarch. Besides the on-chain scripts, the POC also includes:
+  cip -->|forwards access checks to| policy
+  cip --> other_policies
+```
 
-* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses
-* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters
-* A simple user interface that implements the use cases using browser-based wallets
-* An OCI image with the on-chain code, the off-chain code and the UI
+CIP-0143 supports a wide range of programmable token policies, including non-financial ones such as royalty collection schemes for NFTs.
 
-With the OCI image it is possible to run the complete system locally with just a single command.
+### Contents of this repository
+
+TOOD: Move to readme
+
+This repository contains 
+* Prototype implementation of CIP-0143 in Plutarch
+* Prototype implementation of Access Control Policy in Plutarch
+* Transaction building code for initial deployment, minting programmable tokens, transferring programmable tokens, adding addresses to the blacklist (ie. freezing), and seizing funds from blacklisted addresses. Based on sc-tools and cardano-api.
+* Emulator tests for the nominal cases (happy path) based on the actual ledger implementation and mainnet protocol parameters.
+* A user interface that implements the use cases using browser-based wallets. Based on next.js and lucid.
+* An OCI container image with the on-chain code, the off-chain code and the UI
+
+With the container image it is possible to run the complete system locally with just a single command.
 There is no need to install the build toolchain or to operate a cardano node or related infrastructure.
 The image can even be used to interact with existing deployments of the POC.
 
+TODO: Instructions for running the POC locally.
+
 ## High-Level Interactions
 
 ## On-Chain Scripts
 
+For each of the two components (CIP and ACP) there is a principal validation script that encodes the script's logic and vetoes any transaction that does not meet the specification.
+The principal validation scripts use the [stake validator design pattern](https://github.com/Anastasia-Labs/design-patterns/blob/main/stake-validator/STAKE-VALIDATOR.md).
+
 * CIP related
 * Policy related