# delta mandate

![](./docs/internal/the_day_delta_was_defeated.jpg)

## Run the demo locally

### Prerequisites: install the remote prover cli

```
cd ../remote-prover
cargo install --path cli
```

### Steps

There are four actors of the demo. Each actor has to take a series of step described below.

**repyh**

- Launch the `remote_prover`

```bash
cd ../remote-prover
RUST_LOG=info  cargo run --release -p remote_prover -- \
  --port 50051 \
  --prover-mode cpu
```

- Build the ELF (in this repo)

```bash
cd ../agentic-guardrails
cargo build -p policy_engine_elf
```

- Configure ELF in the `remote_prover` (use helper CLI from the `remote_prover` repo)

```bash
remote_prover_cli --server http://localhost:50051 submit \
  --elf crates/policy_engine_elf/elf/delta_local_laws_policy_engine_program
```

- Configure `prover.toml` with the `elf_id` from above and launch the delta mandate Orchestrator:

```bash
cd ../agentic-guardrails
RUST_LOG=info cargo run --release -p mandate-orchestrator-server
```

**Company™**

- Launch evidence extractor API

```bash
./mockoon/run.sh
```

- Configure the prover with the evidence extractor URL (if not already stored in the prover DB)

```bash
guardrail-prover <PROVER_URL> config put --evidence-extractor-url <URL>
```

- "write the template" (it's under
  [clothing_purchase.template](./clothing_purchase.template)), hash it locally
  to get template_id

- submit the template and verify returned template_id

```bash
cargo run --bin mandate-orchestrator -- http://localhost:3000 \
  templates submit --body clothing_purchase.template
```

- Get the verifying key for the `elf_id` and write it in `verifier.toml`

```bash
remote_prover_cli --server http://localhost:50051 verifying-key \
  --elf-id 7ozguXdX5AZWNRPjnN1MUMqZDwmgVbB2xc1TPegwTZhS
```

- Launch the verifier

```bash
RUST_LOG=info cargo run --release -p mandate-verifier-server
```

**"User"**

- Create intent (with generated UUID). Edit the [Rust
  test](./crates/primitives/src/types.rs) to change the `template_id` and values
  to the correct ones.

```bash
cargo test -p primitives sign_mock_intent --quiet -- --nocapture 2>/dev/null \
  | awk '/^{$/,/^}$/' > signed_intent.json
INTENT_ID=$(jq -r .payload.id signed_intent.json)
```

The intent is written to `signed_intent.json`.

- submit the intent to the Orchestrator

```bash
cargo run --bin mandate-orchestrator -- http://localhost:3000 \
  intents submit --json-body signed_intent.json
```

**"Agent"**

- come up with the proposal to the intent 🤖

```bash
PROPOSAL_URL="https://www.amazon.com/dp/B0CK5R6PJM"
```

- submit proposal (with intent_id from above)

```bash
cargo run --bin mandate-orchestrator -- http://localhost:3000 \
  proposals submit --intent-id $INTENT_ID --url $PROPOSAL_URL
```

> the demo has been achieved

Now, what if the agent proposed the wrong product?
The intent clearly wants a pullover in size XL of some colors and brands.

What if the agent proposed a women's skirt instead?

```bash
PROPOSAL_URL="https://www.amazon.com/dp/B0DHXX6S9M"
```

You can check the product returned under this URL with:

```bash
curl localhost:3001/extract --json '{"proposal":{"url":"https://www.amazon.com/dp/B0DHXX6S9M"}}'
```

- submit again the same intent (but with a new UUID) to the Orchestrator

```bash
cargo run --bin mandate-orchestrator -- http://localhost:3000 \
  intents submit --json-body signed_intent.json
```

- submit proposal (with intent_id from above)

```bash
cargo run --bin mandate-orchestrator -- http://localhost:3000 \
  proposals submit --intent-id $INTENT_ID --url $PROPOSAL_URL
```

## Compile Docker images

1. Authenticate with GitHub Container Registry:

   ```bash
   echo "$GH_TOKEN" | docker login ghcr.io -u repyh-labs --password-stdin
   ```

2. Build and push the image:

```bash
docker buildx build \
  --platform linux/amd64 \
  --secret id=cargo_delta_token,env=CARGO_REGISTRIES_DELTA_TOKEN \
  --secret id=github_token,env=GH_TOKEN \
  -f Dockerfile.orchestrator \
  -t ghcr.io/repyh-labs/mandate-orchestrator-server:latest \
  --push .

docker buildx build \
  --platform linux/amd64 \
  --secret id=cargo_delta_token,env=CARGO_REGISTRIES_DELTA_TOKEN \
  --secret id=github_token,env=GH_TOKEN \
  -f Dockerfile.verifier \
  -t ghcr.io/repyh-labs/mandate-verifier-server:latest \
  --push .
```

`--platform linux/amd64` builds x86_64/AMD64 images even when the build is run
from an ARM machine.

The `github_token` secret is used only during compilation so Cargo can fetch
private GitHub git dependencies over HTTPS. `GH_TOKEN` must have read access to
those repositories.

The images do not copy `prover.toml` or `verifier.toml`; configure them at
runtime with environment variables or mounted config files.

### Docker runtime configuration

The Orchestrator image reads the following environment variables:

```bash
REMOTE_PROVER_URL="http://remote-prover:50051"
ELF_ID="..."
DB_PATH="/data/prover_db"
API_PORT="3000"
GRPC_PORT="50052"
```

The verifier image reads the following environment variables:

```bash
VERIFYING_KEY="..."
PROVER_URL="http://prover:50052"
DB_PATH="/data/verifier_db"
API_PORT="3003"
GRPC_PORT="50053"
```

`REMOTE_PROVER_URL`, `ELF_ID`, and `VERIFYING_KEY` are required for the
corresponding services. The other values shown above are the usual Docker
defaults or service URLs.
