Level 4: Certified ArcFlow Architect
Title: Certified ArcFlow Architect
Prerequisite: Level 3: Platform Engineer
What certified means at this level
You understand Rust runtime architecture (arcflow-core) and the reasoning behind major decisions, select the correct integration surface for any scenario, design multi-tenant deployments with security boundaries, contribute to or evaluate workflow specification changes, audit deployments for trace data policy compliance using Postgres queries and trace exports, design enterprise reliability patterns, explain graph join semantics and max_iterations guards, compare embedded SDK versus server deployment tradeoffs, reason about deferred features and advise on workarounds, and design production RAG ingestion pipelines.
Competencies added over Level 3
| Competency | Demonstration |
|---|
| Runtime depth | Explain scheduler, trace bridge, provider abstraction |
| Surface selection | Written rationale for SDK vs server vs static vs Relay |
| Multi-tenant design | Tenant isolation for keys, data, and namespaces |
| Workflow specification and contracts | Schema evolution impact analysis |
| trace data policy audit | Query plus export based audit checklist |
| Reliability at scale | Retry, fallback, recovery, timeout strategy document |
| Graph semantics | Join rules, iteration guards, Graph recovery resume limits |
| Deferred features | Workaround for one FP item with accepted tradeoff |
| Production RAG | Ingestion pipeline design with chunking and ops |
Continue with
Practical project
Design a multi-tenant enterprise deployment from scratch. Deliver written artifacts, not only running code.
Deliverables
| Deliverable | Content |
|---|
| Architecture diagram | Server, Relay, Postgres, Qdrant, tenants, admin plane |
| Surface selection rationale | Per integration type: backend job, browser chat, batch ingest, compliance audit |
| Security boundary document | Keys, network zones, data residency, tenant isolation |
| Deployment runbook | Install, migrate, upgrade, rollback, backup |
| trace data policy audit checklist | Postgres queries and trace sampling procedure |
| Deferred feature recommendation | One of graph recovery resume, server SSE streaming, Operator dashboard UI, OpenTelemetry metrics export, CLI validate with workaround |
Multi-tenant design requirements
| Area | Decision to document |
|---|
| Identity | Separate admin vs runtime vs site tokens per tenant |
| Data | Namespace strategy for vector memory and published workflows |
| Network | Relay per region vs shared Relay with site ids |
| Blast radius | Failure containment if one tenant overloads Qdrant |
| Compliance | Trace retention and export policy per tenant |
trace data policy audit checklist (sample)
| Step | Action |
|---|
| 1 | Export 10 random run traces via CLI or HTTP |
| 2 | Search JSON for forbidden fields (prompt, message body, chunk text) |
| 3 | Query Postgres trace tables for column sizes and patterns per schema docs |
| 4 | Review Relay and server log sampling config |
| 5 | Confirm static bundles contain no runtime keys |
| 6 | Document findings and remediation |
Graph and reliability section
Explain in prose:
| Topic | Must address |
|---|
| Join semantics | What wait_for guarantees |
max_iterations | Loop guard purpose |
| Graph recovery resume | Why not to rely on graph resume in production yet |
| Retry vs fallback | When to use each at enterprise scale |
| SDK vs server | Latency, persistence, and compliance tradeoffs |
Deferred feature recommendation template
Pick one deferred feature from maturity and known gaps:
| Field | Your answer |
|---|
| Feature | e.g. Server SSE streaming |
| User impact | What customers cannot do today |
| Workaround | Supported alternative |
| Tradeoff accepted | Cost of workaround |
| Revisit condition | When to adopt native feature |
Example: Server SSE deferred, workaround SDK streaming or poll, accept higher latency for browser backends until native SSE ships.
Production RAG pipeline section
Document ingestion for at least two document types (PDF export, HTML, or markdown):
| Stage | Design choice |
|---|
| Source | Dashboard upload vs batch job |
| Chunking | Size, overlap, heading awareness |
| Embedding | Model selection and rotation |
| Namespace | Per tenant and per product |
| Evaluation | Recall spot checks without storing raw queries in logs |
| Reindex | Zero-downtime strategy |
Pass criteria checklist
| Check | Pass |
|---|
| Diagram matches narrative | yes |
| Every external integration has surface choice | yes |
| trace data policy audit procedure reproducible | yes |
| Multi-tenant isolation explicit | yes |
| Graph semantics section accurate | yes |
| deferred-feature workaround technically sound | yes |
| RAG pipeline operable | yes |
| Peer review | another engineer agrees |
Self-assessment checklist
| Question | Answer must be yes |
|---|
| Can you explain why traces are metadata-only in storage design? | |
| Can you propose a workflow specification change without breaking Relay clients? | |
| Can you defend SDK embed vs server for a regulated workload? | |
| Can you audit a live deployment in under two hours? | |
Program completion
Level 4 is the current top tier. Maintain certification by re-running trace data policy audits after major upgrades and revisiting deferred feature recommendations each release.