One session would write tests. Another would skip them. One agent would update architecture notes. Another would leave the knowledge buried in chat history. One session would wait before opening a PR. Another would push ahead without the same level of verification.

That inconsistency is what led me to build OpenCaw.

OpenCaw is an open source framework library for AI-assisted development. I designed it to standardize agent instructions, roles, skills, reusable commands, architecture guidance, task tracking, verification, and project memory across tools such as Cursor, Codex, and Claude.

In simpler terms: OpenCaw gives your AI coding agents a consistent way to work. You can use it by speaking naturally about what you want, or you can call specific roles, skills, and commands when you want precision. The explicit names are there for control and repeatability, not because every user should have to memorize them.

What Is OpenCaw?

OpenCaw is not a traditional application framework. It does not dictate whether your app should use .NET, Node, Python, React, Angular, Terraform, Kubernetes, or any other stack.

Instead, OpenCaw is a shared AI development baseline that you mount inside an existing repository.

I built it around a simple idea: the reusable AI operating model should live in one place, while project-specific knowledge should stay inside the project.

OpenCaw gives agents a structured operating model that includes:

• Role definitions
• Skill instructions
• Reusable shell commands
• Architecture templates
• Task tracking conventions
• PR readiness rules
• Verification workflows
• Project-local memory files

The mounted OpenCaw folder acts as the shared configuration layer. The host repository keeps its own memory, rules, debug notes, tasks, goals, and project-specific context under .ai/.

That separation matters. I want teams to be able to improve their shared AI workflow without polluting the baseline with one repository's local quirks.

Why I Built It

I created OpenCaw because I wanted AI-assisted development to feel less like improvisation and more like engineering.

Prompting alone is not enough for long-lived repositories. A good prompt can get a useful answer once, but it does not automatically give you repeatable behavior across future sessions, other tools, or other team members.

Without a shared baseline, AI sessions tend to drift:

• One agent writes tests; another skips them.
• One agent updates architecture notes; another ignores them.
• One agent opens PRs too early; another waits for confirmation.
• One agent stores useful lessons in the wrong place.
• One agent understands the stack; another has to rediscover it.
• One agent verifies the work; another simply says it is done.

OpenCaw is my answer to that drift.

The goal is not to create one magic prompt. The goal is to create a durable operating manual for AI-assisted software work: how agents should plan, implement, verify, document, and hand off changes.

How OpenCaw Is Structured

I designed OpenCaw to be installed into a repository as a tool directory such as .codex, .cursor, or .claude.

A typical install looks like this:

your-repository/  
├── .codex/
│   ├── AGENTS.md
│   ├── .architecture/
│   ├── .roles/
│   ├── commands/
│   └── skills/
├── .ai/
│   ├── MEMORY.md
│   ├── RULES.md
│   ├── DEBUG.md
│   └── tasks/
├── AGENTS.md
└── ARCHITECTURE.md

The important separation is:

OpenCaw includes architecture templates under .architecture/, role definitions under .roles/, reusable task instructions under skills/, and shell automation under commands/.

The repository includes templates and conventions for many common engineering areas, including .NET, Node, Python, Playwright, React, Angular, Vue, Terraform, Kubernetes, Helm, GitHub Actions, Azure DevOps, Docker, databases, and more.

How to Install OpenCaw

Before installing OpenCaw into a project, I recommend forking the repository.

You can install directly from the public repository, but using your own fork gives your team control over updates, local customizations, release pinning, and upstream merges.

In the examples below, replace <your-org> with your GitHub user or organization.

Option 1: Install as a Git Submodule

This is the approach I recommend for most teams.

Use .codex if you want OpenCaw available to Codex-style agents:

git submodule add https://github.com/<your-org>/OpenCaw .codex  
git submodule update --init --recursive  

Use .cursor if you want OpenCaw available to Cursor:

git submodule add https://github.com/<your-org>/OpenCaw .cursor  
git submodule update --init --recursive  

Use .claude if you want OpenCaw available to Claude:

git submodule add https://github.com/<your-org>/OpenCaw .claude  
git submodule update --init --recursive  

A submodule is useful because your host repository can pin a known-good OpenCaw revision while still allowing controlled updates later.

Option 2: Install as a Clone

Use a plain clone when the repository needs a heavily customized copy of OpenCaw:

git clone https://github.com/<your-org>/OpenCaw .codex  

Or:

git clone https://github.com/<your-org>/OpenCaw .cursor  

Or:

git clone https://github.com/<your-org>/OpenCaw .claude  

This is easier to modify directly, but it also makes upstream updates less structured than a submodule.

How I Recommend Using OpenCaw

Once installed, OpenCaw should load through the repository's AGENTS.md bootstrap.

If your agent session does not appear to pick it up, explicitly ask it to read the instructions:

Read AGENTS.md instructions  

From there, the most important thing to know is this: you do not have to memorize every role, skill, command, task convention, or goal-flow phrase.

I include exact role names, skill names, and command paths because they are useful. They make workflows auditable, scriptable, repeatable, and easier to debug. But OpenCaw is also designed to work from normal human intent.

You can say what you want in plain English:

Review this project for security issues, create tasks for anything serious, and run whatever validation makes sense before summarizing the results.  

OpenCaw gives the agent enough structure to translate that into the right operating mode: likely a security role, task creation, issue management if relevant, validation commands, and an evidence-based final summary.

That means there are two equally valid ways to use OpenCaw:

My recommendation is to start with plain language. Add explicit roles, skills, or command paths only when you need more control.

1. Start With Intent

The most natural way to use OpenCaw is to describe the outcome you want.

For example:

Help me implement this feature safely. Plan the work, update the code, add tests, run the right checks, and tell me what changed.  

That is enough for an OpenCaw-aware agent to choose the right workflow. It can infer that this is implementation work, that task planning may be useful, that test and validation behavior matters, and that the final answer should include evidence.

This is the mode I want most people to use day to day. OpenCaw should make the agent easier to direct, not harder.

2. Use Roles When You Want a Specific Perspective

Roles tell the agent which perspective to use.

OpenCaw includes roles such as:

• backend-architect
• frontend-developer
• fullstack-engineer
• qa-engineer
• project-manager
• security-engineer
• sre
• devops-automator
• data-engineer
• technical-writer

The role index also supports aliases such as security, qa, frontend, backend, devops, sre, and pm.

You can be explicit:

use role security-engineer and review this repository for authentication, authorization, and dependency risks  

Or you can say the same thing naturally:

Review this repository like a security engineer. Focus on authentication, authorization, and dependency risks.  

Both are valid. The explicit version is useful when you want deterministic behavior. The natural-language version is easier to remember.

3. Compose Perspectives Without Memorizing Role Names

OpenCaw supports multi-role sessions. The first role acts as the primary perspective. Additional roles add specialist constraints or review lenses.

Explicit version:

use role backend-architect + security-engineer and review the payment API design before implementation  

Plain-language version:

Review the payment API design from both an architecture and security perspective before we implement it.  

I use this pattern often when I want implementation work to carry a second concern, such as quality, security, reliability, or documentation.

You do not have to know the exact role names. Describe the perspectives you want, and OpenCaw gives the agent a structure for mapping those perspectives into its role system.

4. Let Skills Stay Behind the Curtain

Skills are reusable instructions for common types of work.

I separate skills from commands on purpose:

• Skills define the reasoning workflow.
• Commands define repeatable execution.

You can call skills explicitly:

use skill create-task-file + manage-task-issues + test-dotnet  

But you can also just describe the work:

Turn this GitHub issue into a tracked task, implement the fix, link the task back to the issue, and run the relevant .NET tests.  

That plain-language prompt gives the agent enough signal to use the task-file, issue-management, and .NET testing workflows without requiring you to remember the internal skill names.

Useful skills include:

Skills make agent behavior less dependent on one-off prompt wording. The skill names are helpful labels, but they are not the only way to trigger the behavior.

5. Use Commands for Repeatable Execution

Commands are shell scripts inside the OpenCaw baseline.

Examples:

./.codex/commands/validate-opencaw.sh
./.codex/commands/generate-architecture.sh DOTNET NODE GITHUB_ACTIONS
./.codex/commands/dotnet-build.sh
./.codex/commands/dotnet-test.sh

I like showing the full command paths because they make it clear what is actually available in the repository. They are useful when you are running something manually, writing documentation, debugging a workflow, or wiring OpenCaw into automation.

But you do not need to remember those paths during normal agent usage.

Instead of saying this:

Run ./.codex/commands/dotnet-build.sh and ./.codex/commands/dotnet-test.sh  

You can say this:

Build the .NET project and run the relevant tests before summarizing the result.  

Instead of saying this:

Run ./.codex/commands/generate-architecture.sh DOTNET REACT GITHUB_ACTIONS  

You can say this:

Create an architecture document for this .NET and React project that uses GitHub Actions.  

OpenCaw includes commands for validation, architecture generation, .NET restore/build/test, Playwright evidence reporting, task files, issue linking, PR readiness, goal files, sub-agent planning, security scans, and database tooling.

The point is not to make users memorize shell scripts. The point is to give the agent reliable tools it can choose when you describe the outcome you want.

6. Let OpenCaw Create Durable Task Artifacts

For substantial work, OpenCaw uses .ai/tasks/ in the host repository.

A typical task structure looks like this:

.ai/tasks/
├── TODO.md
├── OPEN_ISSUES.md
└── checkout-refactor/
    ├── TASK.md
    └── SUBAGENTS.md

I use this structure because chat history is not enough for serious engineering work.

The task directory gives the repository a durable trail:

• What the task is
• What issue it maps to
• What needs to be done
• Which sub-agent lanes were planned
• What remains open
• What validation happened

You can request this explicitly:

use skill create-task-file and create a task under .ai/tasks for this refactor  

Or you can say it naturally:

This refactor is large enough that I want a durable task plan before implementation.  

Both should lead the agent toward task planning. The task system exists so work can be paused, resumed, reviewed, and handed off without relying only on chat history.

7. Use Architecture Templates Early

If your repository does not have an ARCHITECTURE.md, OpenCaw can generate one from selected templates.

Manual command version:

./.codex/commands/generate-architecture.sh DOTNET REACT GITHUB_ACTIONS

Explicit agent version:

use role software-architect and generate ARCHITECTURE.md for this repository using DOTNET, REACT, POSTGRESDB, and GITHUB_ACTIONS templates  

Plain-language version:

Create an architecture document for this repo. It is a .NET backend with a React frontend, Postgres storage, and GitHub Actions for CI.  

By default, I keep the generated architecture file concise by referencing selected templates instead of inlining all template content. The architecture generation script also supports an --inline option when full embedded template content is explicitly needed.

My recommendation is to create or update architecture documentation early. It gives the agent a contract to preserve instead of forcing every session to rediscover the system from scratch.

8. Use Sub-Agent Planning Only When Work Can Be Split Safely

OpenCaw includes project-manager and sub-agent orchestration support.

Sub-agent planning is useful when different lanes can work independently, such as:

• One lane investigates current behavior.
• One lane updates backend code.
• One lane updates frontend code.
• One lane writes tests.
• One lane reviews security or performance.

Explicit version:

use 4 agents with project-manager + fullstack-engineer + qa-engineer to split the checkout refactor into safe parallel lanes, keep write sets separate, then integrate and verify  

Plain-language version:

This checkout refactor may be too large for one linear pass. Split it into safe parallel work lanes if that makes sense, keep overlapping file changes to a minimum, then integrate and verify everything together.  

I do not recommend forcing parallel work just because multiple agents are available.

Good sub-agent planning should keep write sets narrow, avoid overlapping changes, and prefer fewer high-quality lanes over unnecessary fragmentation.

9. Use Goal Flow for Multi-Task Delivery, Not Auto-Merge

Goal flow is for explicit, multi-task automation.

It can move from task to task, raise PRs after validation, run post-PR QA, and produce a final approval report.

It does not mean automatic merge approval, and it does not skip QA.

Explicit version:

goal: modernize the reporting module across these five tasks. Automatically raise each task PR after validation, run post-PR QA, then continue to the next task. Do not merge PRs automatically.  

Plain-language version:

I want to work through these five reporting-module tasks as one coordinated goal. For each task, validate the work, open a PR when it is ready, run post-PR QA, and continue to the next task only if the checks pass. Do not merge anything automatically.  

Use goal flow when you have a clear sequence of tasks and want the agent to manage delivery discipline across them.

Do not use it when requirements are still vague or when each step still needs product approval.

Plain-Language Intent vs Explicit Controls

Here is the simplest way to think about it:

Tell OpenCaw what outcome you want. Use exact names only when exactness helps.  

The explicit names are still valuable. I keep them visible because teams need stable vocabulary for docs, automation, task files, pull requests, and repeatable workflows.

But the day-to-day user experience should feel natural.

This is the balance I wanted OpenCaw to strike: plain-language control for humans, explicit machinery for agents and teams.

Example Prompts

Here are practical prompts I use or recommend after installing OpenCaw. Each example is written in plain language first, with an explicit version where the extra precision may help.

Repository Onboarding

Plain-language version:

Read the project instructions, inspect this repository, summarize the stack, identify missing architecture documentation, and recommend what should be standardized.  

Explicit version:

Read AGENTS.md instructions. Then inspect this repository, summarize the stack, identify missing architecture documentation, and recommend the OpenCaw architecture templates that apply.  

Architecture Generation

Plain-language version:

Create an architecture document for this repo. It has a .NET backend, React frontend, Postgres database, and GitHub Actions CI. Keep the document concise and easy for future agents to follow.  

Explicit version:

use role software-architect and generate ARCHITECTURE.md using DOTNET, REACT, POSTGRESDB, and GITHUB_ACTIONS. Keep the generated file concise with template read directives.  

Security Review

Plain-language version:

Review this repository for security risks. Focus on authentication, authorization, secrets, dependencies, logging, and deployment. Create tracked tasks for high-priority fixes and verify anything you change.  

Explicit version:

use role security-engineer + sre and review this repository for authentication, authorization, secrets, dependency, logging, and deployment risks. Create a task file for each high-priority fix.  

Test Coverage

Plain-language version:

Improve test coverage for this feature. Include edge cases, regression coverage, and a clear summary of the verification you ran.  

Explicit version:

use role qa-engineer and generate full test coverage for the current feature, including edge cases, regression tests, and verification evidence.  

Full Feature Delivery

Plain-language version:

Build the user settings page end to end. Plan the work, implement the API integration, add UI validation, update documentation if needed, run the right checks, and summarize the evidence.  

Explicit version:

use role fullstack-engineer and build the user settings page with API integration, UI validation, tests, task tracking, architecture updates if needed, and final verification.  

Existing GitHub Issue

Plain-language version:

Work on issue #123. Turn it into a tracked OpenCaw task, implement the fix, link the task back to the issue, add tests, run validation, and prepare it for PR review.  

Explicit version:

work on #123. Import the issue into OpenCaw task tracking, implement the fix, add tests, run verification, and prepare PR readiness evidence.  

Parallel Refactor

Plain-language version:

This checkout refactor is large. Split it into safe parallel work lanes only if that reduces risk. Keep file ownership clear, integrate the result, and verify the whole flow before calling it done.  

Explicit version:

use 3 agents with project-manager + backend-architect + qa-engineer to plan and implement the checkout refactor. Split only safe parallel lanes, keep write sets separate, then integrate and verify.  

Multi-Task Goal

Plain-language version:

Treat these five reporting tasks as one coordinated goal. Complete them in order, validate each one, open a PR when each task is ready, run post-PR QA, and stop if any check fails. Do not merge automatically.  

Explicit version:

goal: complete the reporting modernization across the five tasks listed in TODO.md. Raise each task PR after validation, run post-PR QA, and stop if validation or QA fails. Do not merge PRs automatically.  

Keeping OpenCaw Updated

If you installed OpenCaw as a submodule, update it with:

git submodule update --remote .codex  

Or, for another mount name:

git submodule update --remote .cursor  
git submodule update --remote .claude  

For production repositories, I recommend pinning a known release tag rather than automatically following the latest commit.

Example:

cd .codex  
git fetch --tags  
git checkout 2.0.0  
cd ..  
git add .codex  
git commit -m "chore(opencaw): pin OpenCaw 2.0.0"  

Replace 2.0.0 with the release tag you want to pin.

This gives you the best of both worlds: centralized updates when you want them, and controlled changes when stability matters.

Best Practices

Keep OpenCaw Shared, Keep Memory Local

Do not put project-specific lessons inside the OpenCaw baseline unless you are intentionally changing the shared framework.

Store project memory in .ai/.

Good places for project-local knowledge:

.ai/MEMORY.md
.ai/RULES.md
.ai/DEBUG.md
.ai/FRAGMENTS/
.ai/LEARNINGS/
.ai/tasks/

This is one of the most important design choices in OpenCaw. The baseline should be reusable. The host repository should own its local truth.

Validate After Changing Roles, Skills, or Commands

Run validation after editing OpenCaw internals:

./.codex/commands/validate-opencaw.sh

This is especially important if you customize roles, add skills, or introduce new commands.

Prefer Clear Intent Over Memorized Syntax

Weak prompt:

fix this  

Better plain-language prompt:

Fix this bug like a senior developer. Find the root cause, make the smallest safe change, add regression coverage, run the relevant checks, and summarize the evidence.  

More explicit version:

use role senior-developer + qa-engineer and fix this bug. Find the root cause, implement the smallest safe change, add regression coverage, run verification, and summarize the evidence.  

Both improved prompts give the agent a perspective, a quality bar, and a definition of done. The explicit role name is helpful, but the intent matters more than the syntax.

Ask for Evidence, Not Just Completion

A strong OpenCaw workflow ends with proof.

Good verification requests include:

Run the relevant tests and include command output in the final summary.  

Verify the browser flow with Playwright and attach evidence to the PR comment.  

Compare behavior before and after the change and document the difference.  

I care about evidence because "done" is cheap. Verified is what matters.

Use Goal Flow Carefully

Goal flow is powerful, but it works best when the task sequence is already clear.

Use it for planned delivery, not open-ended discovery.

Good goal-flow prompt:

goal: complete the migration plan across the five tasks already listed in TODO.md. Raise each PR after local validation, run post-PR QA, and stop if validation or QA fails. Do not merge PRs automatically.  

Do Not Skip the PR Readiness Gate

In normal task flow, OpenCaw expects the agent to ask before pushing or opening a PR.

Goal flow is the explicit exception, and even then it still requires validation and post-PR QA.

That gate exists for a reason. AI-assisted development should move quickly, but it should not bypass engineering discipline.

When OpenCaw Is a Good Fit

OpenCaw is especially useful when:

• You use AI coding tools across multiple repositories.
• Your team wants consistent agent behavior.
• You want repeatable architecture and verification standards.
• You want durable task tracking instead of chat-only planning.
• You want role-based AI workflows for architecture, QA, DevOps, security, and full-stack work.
• You want a project memory system that does not pollute the shared baseline.
• You want controlled PR readiness and QA behavior.

It may be more structure than you need for a tiny throwaway project. But for long-lived repositories, especially team-owned codebases, that structure is the point.

Final Thoughts

I built OpenCaw because I wanted AI-assisted development to become more repeatable, more auditable, and more useful across real repositories.

OpenCaw does not replace your coding agent. It gives that agent better rails.

Installed as .codex, .cursor, or .claude, OpenCaw becomes a reusable baseline for how work should be planned, implemented, verified, documented, and handed off.

The result is a more governed AI workflow:

• Plain-language intent tells the agent what outcome you want.
• Roles define perspective when you need precision.
• Skills define reasoning workflows behind the scenes.
• Commands define repeatable execution.
• .ai/ stores project memory.
• Verification evidence keeps the process honest.

For teams trying to move from casual AI prompting to repeatable AI-assisted engineering, OpenCaw is the structure I wish I had earlier. That is why I built it.

Most developers underestimate how transferable enterprise engineering patterns really are.

A queue is still a queue.
A scheduler is still a scheduler.
A planner is still a planner.

Whether the environment is:

• a Fortune 500 logistics platform,
• a cloud-native orchestration system,
• an autonomous AI workflow,
• or a colony of programmable units inside a video game.

That is what makes Screeps uniquely valuable for developers trying to learn modern AI systems engineering.

At first glance, Screeps looks like a programming game.

In reality, it is a persistent distributed systems simulator disguised as a game engine.

More importantly, it allows developers to practice:

• enterprise software architecture,
• AI planning,
• autonomous orchestration,
• observability,
• and systems design,

in an environment where the results are visually observable in real time.

That combination is extremely rare.

A Missing Piece in AI Education

Most AI learning material focuses on:

• prompts,
• embeddings,
• vector databases,
• model APIs,
• inference pipelines,
• or neural architectures.

Very little focuses on:

• autonomous orchestration,
• long-running planning systems,
• failure recovery,
• distributed coordination,
• or AI-native software architecture.

But these are the exact problems enterprise teams are struggling with right now.

Modern AI systems increasingly resemble:

• operating systems,
• distributed schedulers,
• planner networks,
• asynchronous workflow engines,
• and event-driven ecosystems.

Ironically, Screeps teaches these concepts better than many enterprise tutorials because the systems and their execution become visually observable.

You can literally watch architecture decisions succeed or fail.

Screeps Is Closer to Enterprise Software Than Most Developers Realize

A mature Screeps colony resembles a production enterprise platform far more than a traditional game bot.

Consider the parallels.

Enterprise Platform

API Gateway  
 ├── Authentication Service
 ├── Billing Service
 ├── Notification Service
 ├── Queue Processors
 ├── Workflow Orchestrators
 └── Monitoring Pipelines

Screeps Colony

Global Colony Manager  
 ├── Spawn Planner
 ├── Logistics Planner
 ├── Harvest Scheduler
 ├── Defense Coordinator
 ├── Expansion Planner
 └── Telemetry System

Structurally, these are extremely similar systems.

Both involve:

• asynchronous work,
• constrained resources,
• event-driven behavior,
• state synchronization,
• priority management,
• fault handling,
• distributed execution,
• and long-term planning.

The difference is that Screeps allows you to see the orchestration.

Enterprise Coding Standards Translate Directly Into Screeps

One of the most valuable aspects of using Screeps as an AI engineering sandbox is that enterprise coding patterns map naturally into colony architecture.

This means developers can strengthen both skill sets simultaneously.

Dependency Injection

Enterprise systems rely heavily on dependency injection for:

• modularity,
• testing,
• abstraction,
• and lifecycle management.

The same pattern becomes useful in Screeps almost immediately.

Hardcoded Approach

const roleHarvester = require('role.harvester');  

Hardcoded logic scales poorly.

Enterprise-Inspired Approach

class HarvesterBehavior {  
    execute(context) {
        // behavior logic
    }
}

container.register("harvester", HarvesterBehavior);  

Now your colony architecture supports:

• runtime composition,
• strategy replacement,
• testing,
• behavior injection,
• planner abstraction.

Exactly like enterprise systems.

Event-Driven Architecture

Enterprise systems increasingly rely on:

• Kafka,
• Azure Service Bus,
• RabbitMQ,
• event sourcing,
• reactive pipelines.

Screeps naturally pressures developers toward the same patterns.

Instead of direct execution:

creep.transfer(storage, RESOURCE_ENERGY);  

You evolve toward event production:

eventBus.publish({  
    type: "ENERGY_DELIVERED",
    source: creep.name,
    amount: 100
});

Now the colony becomes:

• observable,
• decoupled,
• replayable,
• analyzable.

This mirrors modern enterprise architecture almost perfectly.

Queue Systems and Work Orchestration

Enterprise orchestration systems live and die by queue management.

So do Screeps colonies.

A naive Screeps colony directly assigns work:

builder.build(target);  

A mature colony evolves toward distributed work scheduling:

taskQueue.enqueue({  
    type: "build",
    priority: 40,
    target: target.id
});

Suddenly you are implementing:

• priority queues,
• distributed scheduling,
• work leasing,
• retry handling,
• dead-letter concepts,
• starvation prevention.

These are enterprise engineering problems.

AI Planning Maps Directly to Enterprise Workflow Systems

This is where the connection becomes especially important for modern AI development.

AI systems are increasingly becoming:

• planner-driven,
• goal-oriented,
• workflow-based,
• and stateful.

Screeps naturally teaches these concepts because every colony already behaves like an autonomous workflow engine.

Goal-Oriented Planning

Enterprise AI systems increasingly rely on declarative goals.

Instead of:

Run task A.  
Then run task B.  
Then run task C.  

Modern systems increasingly define desired outcomes:

Maintain warehouse inventory above threshold.  
Reduce queue latency below SLA.  
Maintain service health under traffic spikes.  

Screeps evolves in exactly the same direction.

Early Colony Logic

spawnHarvester();  
spawnBuilder();  
spawnUpgrader();  

Mature Colony Planning

roomGoals = {  
    reserveEnergy: 50000,
    minimumHarvestRate: 120,
    constructionBacklogLimit: 5,
    defenseReadiness: "HIGH"
};

Now the colony planner determines:

• what should exist,
• when it should exist,
• and how to maintain equilibrium.

This is extremely similar to enterprise AI orchestration systems.

Observability and Telemetry

Enterprise engineering eventually teaches every developer the same painful lesson:

If you cannot observe the system, you cannot control the system.

Screeps teaches this aggressively.

Without telemetry:

• planners silently fail,
• logistics systems oscillate,
• CPU budgets collapse,
• economies deadlock.

This naturally pushes developers toward enterprise observability patterns.

Enterprise Monitoring Stack

Application Insights  
Prometheus  
Grafana  
Elastic  
Distributed tracing  
Structured logging  

Screeps Equivalent

Colony telemetry  
Task diagnostics  
Path heatmaps  
Tick performance metrics  
Planner audit logs  
Economic trend analysis  

The patterns are nearly identical.

The difference is that Screeps provides immediate visual reinforcement.

You can watch bad telemetry architecture hurt the colony.

Screeps Teaches AI-Native State Management

One of the hardest transitions for enterprise developers entering AI engineering is understanding long-lived state systems.

Traditional enterprise applications are often request-driven:

Request → Process → Response  

AI systems are increasingly persistent:

Observe → Plan → Adapt → Persist → Recover  

Screeps operates entirely in the second model.

Every tick:

• inherits previous state,
• modifies future state,
• reacts to changing conditions,
• and persists long-term consequences.

This mirrors:

• autonomous agents,
• workflow planners,
• AI orchestration systems,
• robotic coordination systems,
• and distributed automation platforms.

Coding Standards Become More Important, Not Less

One misconception around AI-assisted development is that coding standards matter less.

The opposite is true.

AI systems perform dramatically better when:

• architecture is predictable,
• abstractions are stable,
• naming conventions are consistent,
• planners are isolated,
• and system boundaries are clear.

Screeps makes this painfully obvious.

A poorly organized colony rapidly becomes impossible for:

• humans,
• planners,
• and AI coding systems

to reason about.

This naturally reinforces enterprise patterns like:

• Clean Architecture
• CQRS
• Domain-Driven Design
• Event Sourcing
• Service Isolation
• Planner Modularization
• Strategy Patterns
• Finite State Machines
• Blackboard Systems

Enterprise Refactoring Skills Become Transferable

One of the most surprising discoveries is how well enterprise refactoring skills translate into Screeps AI systems.

Enterprise Refactor

Break monolith into services.  

Screeps Equivalent

Break colony manager into planners.  

Enterprise Refactor

Introduce queue-based processing.  

Screeps Equivalent

Introduce colony task scheduler.  

Enterprise Refactor

Improve observability and tracing.  

Screeps Equivalent

Add planner telemetry and tick analytics.  

These are fundamentally the same engineering exercises.

AI Coding Models Become More Useful in Screeps Than Traditional CRUD

Large coding models struggle with isolated snippets because there is little systemic context.

But they become extremely effective when reasoning about:

• planners,
• workflows,
• scheduling,
• coordination,
• recovery systems,
• and architecture evolution.

Screeps gives models exactly the kind of environment where they excel.

Instead of prompting:

Generate a CRUD controller.  

You begin prompting:

Refactor this logistics planner to avoid oscillation during energy shortages.

Reduce path recalculation overhead.

Improve colony recovery behavior after catastrophic spawn loss.

Convert direct role assignment into a distributed task queue.  

These prompts are far closer to real AI engineering problems.

Safe Simulation Is the Real Advantage

Perhaps the most important aspect of Screeps is this:

It is a safe systems laboratory.

You can experiment with:

• autonomous planning,
• AI-generated code,
• aggressive refactors,
• distributed coordination,
• planner hierarchies,
• adaptive scheduling,
• and multi-agent behavior

without:

• damaging infrastructure,
• risking production systems,
• impacting users,
• or creating expensive outages.

This creates an unusually powerful learning environment.

Especially for enterprise developers transitioning into AI engineering.

Bridging Enterprise Engineering and AI Systems

This is ultimately why Screeps is so valuable.

It acts as a translation layer between:

• traditional enterprise software engineering,
• and modern autonomous AI architecture.

It allows developers to:

• apply enterprise patterns,
• observe autonomous behavior,
• test planner architectures,
• experiment with AI orchestration,
• and visually understand distributed systems dynamics.

All inside an environment where failure is educational instead of catastrophic.

Final Thoughts

Most developers trying to learn AI engineering focus too heavily on:

• model APIs,
• prompts,
• or frameworks.

But the future of AI systems is not just about inference.

It is about:

• orchestration,
• planning,
• state management,
• observability,
• distributed coordination,
• resilience,
• and long-running autonomous behavior.

Screeps happens to be one of the best environments available for learning all of those skills simultaneously.

Not because it teaches AI directly.

But because it teaches the engineering patterns that modern AI systems increasingly depend on.

The same systems that enterprise engineering teams depend on every day.

During gameplay of Arc Raiders, private Discord Direct Message (DM) conversations between two users were found being written in plaintext to a local game log file. Additionally, a full Discord Bearer authentication token was found stored in the same log file. These findings represent serious privacy and security violations that affect all players using Discord integration with the game.

Correction:

I originally reported that the bearer token had the ability to send a message on the user behalf. This was in error due to my misunderstanding of the permission rpc.voice.write. This permission only allows the token holder to change the users voice settings. It does not allow them to send a message as the user. This has been corrected in the article below to give the correct abilities. This message serves as a retraction notice.

Update: This has now been patched.

Affected Files

• Log File Location:

C:\Users\<username>\AppData\Local\PioneerGame\Saved\Logs  

• Log File Name: discord.log
• Discord SDK Version: commit 3b8f3adce7dd1d85463aa700d9185676633e98a1, version 1.8.13395

Risk Summary

Private DM Conversation Content Logged to Disk

Description:
Private Discord Direct Messages exchanged between two users were captured by the game's Discord SDK gateway connection and written in full to a plaintext log file stored locally on the user's machine.

Evidence:

• MESSAGE_CREATE gateway events appearing in the game log file
• Channel type 1 confirmed - this is a private DM channel, not a game or public channel
• Messages between users captured in full
• Message content, timestamps, user IDs, channel IDs all logged in plaintext

The Arc Raiders Discord SDK connects using a full user Bearer token, opening a complete Discord gateway connection identical to the one used by the Discord desktop app itself. Discord's gateway pushes all events to this connection - including private DM messages. Rather than filtering sensitive events, the SDK logs everything it receives to disk.

Impact:

• Any private conversation received while the game is running is written to disk
  
• Log files may be included in crash reports or bug report uploads
  
• Log files may be accessible to other applications on the same machine
  
• Third parties with access to the machine or crash reports can read private conversations
  

Discord Bearer Token Stored in Plaintext Log File

Description:
The user's full Discord Bearer authentication token was found written in plaintext inside the game log file.

Evidence:

"token":"Bearer <redacted>"

(Full token redacted for this report - present in original log file)

A Discord Bearer token is functionally equivalent to account access. Anyone in possession of this token can:

• Read all your messages and DMs
• Access your friend list, servers, and account settings
• Change voice, or discord settings
• Remain logged in until the password is changed

Impact:

• If the log file is ever shared (e.g., in a bug report, on a forum, to a support team), the token is fully exposed
  
• Crash report systems that automatically upload logs would transmit this token to Embark Studios' servers
  
• Malicious software on the same machine could harvest this token from the log file
  

Entire Friends List Presence Data Logged

Description:
PRESENCE_UPDATE and READY_SUPPLEMENTAL gateway events containing the online/offline status, activity, and metadata of the user's entire Discord friends list were written to the log file.

Evidence:

• Multiple PRESENCE_UPDATE events logged for third-party users
  
• READY and READY_SUPPLEMENTAL events containing bulk friend presence data at connection time
  

Impact:

• Third-party users who have no relationship with Arc Raiders have their Discord presence data written to another user's game log file without their knowledge or consent
  
• This affects people who never agreed to Arc Raiders' terms of service
  

Broader Than Necessary Gateway Scope

Description:
The Discord SDK integration requests and maintains a full Discord gateway connection using the user's Bearer token. Discord's own Rich Presence SDK is designed to only require a limited OAuth scope for game activity display. Using a full gateway connection vastly exceeds what is needed for Rich Presence functionality.

Impact:

• Exposes far more user data than necessary for the stated purpose (showing game status in Discord)
  
• Violates the principle of least privilege
  
• Creates unnecessary attack surface for all the findings listed above

For Embark Studios / Arc Raiders

1. Immediately filter MESSAGE_CREATE, PRESENCE_UPDATE, and authentication events from SDK logging
2. Never log Bearer tokens or authentication credentials to any file
3. Reduce the Discord gateway connection scope to only what Rich Presence requires (OAuth, not full Bearer)
4. Audit all crash report and log upload systems to ensure tokens and message content are scrubbed before transmission

For Discord

1. Review SDK design that allows full gateway connections via Bearer tokens for third-party games
2. Enforce stricter OAuth scopes for game Rich Presence integrations
3. Investigate whether this violates Developer Terms of Service

For Affected Users (Immediate Steps)

1. Change your Discord password immediately - this invalidates your current Bearer token
2. Do not share your log files with anyone, including support teams, until the token is removed
3. Disable discord integration inside of Arc Raiders this will remove the information being written to discord.log

This report was prepared based on direct analysis of game log files. All findings are based on observed technical behavior of the Discord SDK integration within Arc Raiders.

“Is this identity allowed to perform this action?”

They are far less effective at answering:

“Is this action correct right now?”

Most real-world security failures occur in this gap. Actions are authenticated, authorized, schema-valid, and yet behaviorally wrong. Endpoints are invoked out of order, workflows are bypassed, state is replayed, and valid APIs are called at invalid times.

I am proposing in this paper that State-Based Access Control (SBAC) addresses this gap by enforcing interaction correctness using a server-authoritative model inspired by authoritative simulation systems.

The diagram above illustrates how SBAC layers alongside RBAC and ABAC.
RBAC answers who may act, ABAC answers under what conditions, and SBAC enforces when an action is valid based on authoritative system state.
Only actions reachable from the current state are permitted. All others are treated as behavioral anomalies.

Motivation and Intuition

1. The Gap Between Allowed and Correct

Traditional access control models focus on identity and permission. They assume that once a client is authenticated and authorized, it will behave correctly.

In practice, this assumption fails. Attackers do not need exploits when they can simply call valid endpoints in the wrong order or at the wrong time.

SBAC exists to make behavior itself a first-class security concern.

2. The Core Principle

SBAC is built on simple concepts:

• Clients do not execute workflows
• They submit inputs
• The server decides what is possible

This principle has been battle-tested in multiplayer game engines for decades. SBAC applies the same thinking to web applications, APIs, and real-time distributed systems.

3. Why SBAC Complements RBAC and ABAC

SBAC is not a replacement for existing access control models.

• RBAC determines who may act
• ABAC determines under what conditions they may act
• SBAC determines when and in what order actions are valid

All three layers are required for correct enforcement.

SBAC Technical Specification

4. Definition of State-Based Access Control

State-Based Access Control (SBAC) is an access control model in which the validity of an action is determined by the current authoritative state of the system and the set of transitions reachable from that state.

An action is permitted if and only if:

1. The client is authenticated (out of scope)
2. The client is authorized by RBAC or ABAC (out of scope)
3. The action corresponds to a valid transition from the current state
4. All transition guards evaluate to true

5. Formal Model of Interaction State

SBAC assumes that applications have security-relevant state, even when that state is implicit in application logic.

This state must be made explicit.

Let:

• S be the set of all security-relevant server states
• I be the set of all externally observable client inputs
• T ⊆ S × I × S be the set of valid transitions

The authoritative interaction model is defined as:

G = (S, T)  

This graph is not a developer workflow diagram.
It is a security artifact.

If an action is not represented in T, it does not exist from a security perspective.

C# example: modeling states and transitions

public enum StateId  
{
    Browsing,
    CheckoutPending,
    Complete
}

public enum OperationId  
{
    StartCheckout,
    ConfirmCheckout
}

/// <summary>
/// Canonical external input after transport normalization.
/// </summary>
public sealed record InputEnvelope(  
    OperationId Operation,
    string ClientId,
    string SessionId,
    long Sequence,
    string Nonce,
    IReadOnlyDictionary<string, string> Meta,
    JsonElement? Payload);

public sealed record Transition(  
    StateId From,
    OperationId Operation,
    StateId To);

6. Transitions, Guards, and Reducers

Each transition in T is defined by:

• a source state
• an operation identifier
• a guard predicate
• a reducer function

The guard determines whether the transition is valid.
The reducer determines how the server state evolves.

Authorization logic belongs in guards.
State mutation belongs in reducers.

C# example: guard and reducer separation

public delegate ValueTask<bool> GuardAsync(  
    StateId state,
    ClassifiedClient client,
    InputEnvelope input,
    CancellationToken ct);

public delegate ValueTask<StateId> ReducerAsync(  
    StateId state,
    ClassifiedClient client,
    InputEnvelope input,
    CancellationToken ct);

public sealed record TransitionDef(  
    Transition Transition,
    GuardAsync Guard,
    ReducerAsync Reduce);

7. Input Envelopes and Normalization

SBAC does not validate raw requests.

All client interactions are normalized into a canonical input envelope before evaluation.

An input envelope typically contains:

• operation identifier
• client classification
• monotonic sequence number
• nonce or uniqueness token
• request metadata
• payload (if applicable)
• transport identifier

Normalization ensures uniform enforcement across transports, replay detection, and ordering validation.

C# example: normalize HTTP into an input envelope (minimal)

public static class InputNormalization  
{
    public static InputEnvelope FromHttp(HttpRequest req, string clientId, string sessionId)
    {
        // Example: map endpoint to an SBAC operation
        var op = req.Path.Value switch
        {
            "/checkout/start"   => OperationId.StartCheckout,
            "/checkout/confirm" => OperationId.ConfirmCheckout,
            _ => throw new InvalidOperationException("Unknown operation")
        };

        // Sequence/nonce can be sent as headers or body fields (implementation choice)
        var seq = long.Parse(req.Headers["X-Sbac-Seq"]);
        var nonce = req.Headers["X-Sbac-Nonce"].ToString();

        var meta = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase)
        {
            ["method"] = req.Method,
            ["path"] = req.Path.Value ?? "",
            ["ua"] = req.Headers.UserAgent.ToString()
        };

        return new InputEnvelope(op, clientId, sessionId, seq, nonce, meta, payload: null);
    }
}

8. The Ghost (Reachability Envelope)

At any moment, only a subset of transitions is valid.

Gs = { t ∈ T | from(t) = s ∧ guard(t, s) = true }  

Gs defines what actions are valid right now.
It is never fully exposed to the client.

Any input outside of Gs is behaviorally inconsistent and constitutes an anomaly.

The ghost represents a strict security boundary.
Transitions outside of Gs are not deferred, sanitized, or conditionally evaluated.
They are categorically invalid for the current state.

C# example: compute the ghost and enforce it

public sealed class SbacEngine  
{
    private readonly IReadOnlyList<TransitionDef> _defs;

    public SbacEngine(IEnumerable<TransitionDef> defs) => _defs = defs.ToList();

    public async ValueTask<IReadOnlyList<TransitionDef>> ComputeGhostAsync(
        StateId current,
        ClassifiedClient client,
        InputEnvelope inputContext,
        CancellationToken ct)
    {
        var candidates = _defs.Where(d => d.Transition.From == current).ToList();
        var allowed = new List<TransitionDef>(capacity: candidates.Count);

        foreach (var d in candidates)
        {
            if (await d.Guard(current, client, inputContext, ct))
                allowed.Add(d);
        }

        return allowed;
    }

    public async ValueTask<StateId> ApplyAsync(
        StateId current,
        ClassifiedClient client,
        InputEnvelope input,
        CancellationToken ct)
    {
        var ghost = await ComputeGhostAsync(current, client, input, ct);

        var match = ghost.FirstOrDefault(d => d.Transition.Operation == input.Operation);
        if (match is null)
            throw new SbacAnomalyException(SbacAnomaly.InvalidTransitionAttempt, "Operation not in ghost");

        return await match.Reduce(current, client, input, ct);
    }
}

9. Bounded Lookahead and Predictive Disclosure

SBAC may optionally define bounded reachability:

Reachable(s, k)  

This represents the set of states reachable from s within k transitions.

Bounded reachability enables predictive asset loading, UI prefetching, capability pre-issuance, and latency hiding.

Predictive disclosure must never expand the ghost.

C# example: bounded lookahead for prefetch hints (conceptual)

public static class Reachability  
{
    public static ISet<StateId> ReachableWithin(
        StateId start,
        int k,
        IEnumerable<TransitionDef> defs)
    {
        var byFrom = defs.GroupBy(d => d.Transition.From)
                         .ToDictionary(g => g.Key, g => g.Select(x => x.Transition.To).ToArray());

        var reachable = new HashSet<StateId> { start };
        var frontier = new HashSet<StateId> { start };

        for (int depth = 0; depth < k; depth++)
        {
            var next = new HashSet<StateId>();
            foreach (var s in frontier)
            {
                if (!byFrom.TryGetValue(s, out var tos)) continue;
                foreach (var to in tos)
                    if (reachable.Add(to)) next.Add(to);
            }
            frontier = next;
            if (frontier.Count == 0) break;
        }

        return reachable;
    }
}

10. Client Model

SBAC replaces the ambiguous notion of “user” with client.

A client is any external entity that interacts with the system and may originate inputs or receive disclosures.

Client classification is assigned by the server, not claimed by the client.

C# example: classify a client (simplified)

public enum ClientClass  
{
    Human,
    Api,
    Seo,
    Unknown
}

public sealed record ClassifiedClient(  
    string ClientId,
    ClientClass Class,
    string? SubjectId,     // user id or service principal id
    string? TokenId);      // JTI or equivalent

11. Client Classes

SBAC recognizes four common client classes:

• Interactive Human Client
• Programmatic API Client
• Observational Client (SEO)
• Unknown Client

Each class receives a different projection of the system and interaction surface.

12. Authoritative Disclosure (SEO)

Observational clients do not traverse workflows.

They receive disclosure projections, which are read-only, server-authored views of the system.

Disclosure endpoints must never originate state transitions.

13. Capability Tokens and State Coupling

SBAC discourages implicit permission for stateful operations.

Instead, the server issues capability tokens that bind an operation to a specific state or resource and are time-limited.

Capabilities are proofs of reachability, not authentication.

C# example: capability token shape (conceptual)

public sealed record Capability(  
    string CapabilityId,
    string ClientId,
    OperationId Operation,
    StateId BoundState,
    DateTimeOffset ExpiresAt,
    string Signature); // HMAC or asymmetric signature

// Verify that the capability was issued by the server and is still valid
public static bool VerifyCapability(Capability cap, StateId currentState, DateTimeOffset nowUtc)  
{
    if (cap.ExpiresAt <= nowUtc) return false;
    if (cap.BoundState != currentState) return false;
    // Signature validation omitted here (implementation-specific)
    return true;
}

14. Transport-Agnostic Enforcement

All client inputs must pass through the same authoritative validation pipeline, regardless of transport.

Behavior must be enforced identically across HTTP, WebSockets, SignalR, gRPC, and message queues.

15. Temporal Integrity

SBAC assumes adversaries can replay requests.

The server must therefore detect duplicated, reordered, or delayed inputs using sequence numbers, nonces, or server-issued state versions.

C# example: basic sequence/nonce gate (per session)

public sealed class ReplayGate  
{
    private long _lastSeq;
    private readonly HashSet<string> _nonces = new(StringComparer.Ordinal);

    public bool Accept(long seq, string nonce)
    {
        if (seq <= _lastSeq) return false;
        if (!_nonces.Add(nonce)) return false;

        _lastSeq = seq;

        // Production: expire nonces over time to bound memory.
        return true;
    }
}

16. Anomaly Classification

SBAC defines a standard anomaly taxonomy:

• Invalid transition attempt
• Temporal violation
• Guard failure
• Enumeration or probing
• Integrity divergence

Anomalies are first-class security signals.

Anomaly classification is coupled with response policy.

SBAC does not mandate a specific response, but it requires that anomalies be observable and actionable.
Common responses include token revocation, forced re-authentication, progressive trust degradation, and temporary account lockout.

C# example: anomaly types and exception

public enum SbacAnomaly  
{
    InvalidTransitionAttempt,
    TemporalViolation,
    GuardFailure,
    EnumerationOrProbing,
    IntegrityDivergence
}

public sealed class SbacAnomalyException : Exception  
{
    public SbacAnomaly Type { get; }

    public SbacAnomalyException(SbacAnomaly type, string message) : base(message)
        => Type = type;
}

Example: Blocking a Real-World Workflow Bypass

17. Scenario Overview

Consider a common e-commerce checkout flow:

1. Browse catalog
2. Select item
3. Start checkout
4. Confirm payment

The system uses modern authentication (OAuth or JWT-based access tokens), RBAC for role enforcement, and ABAC for contextual checks such as region, device, or account state.

An attacker does not bypass authentication.

Instead, the attacker successfully exploits a client-side vulnerability (for example, reflected XSS in a product review field) and steals a legitimate user’s access token.

The attacker now possesses a valid, unexpired token issued by the system and begins using it programmatically.

18. Attack Without SBAC

Using the stolen access token, the attacker:

• presents a valid bearer token issued to a real user
• satisfies RBAC checks
• satisfies ABAC checks

Instead of following the intended state progression enforced by the client UI, the attacker directly invokes:

POST /checkout/confirm  

No item has been selected.
No checkout session has been initialized.
No prior server-side state transition has occurred.

From a traditional access-control perspective:

• authentication passes
• authorization passes
• the endpoint exists and is valid

Unless additional ad-hoc checks exist, the request is processed.

This is not an authentication failure.
This is not an authorization failure.

It is a behavioral failure.

19. Same Attack With SBAC

In an SBAC-enabled system, the authoritative interaction graph includes states such as:

• Browsing
• CheckoutPending
• Complete

The transition ConfirmCheckout is defined as valid only from CheckoutPending.

At the time the stolen token is used, the server’s authoritative state for that session is:

Browsing  

The computed ghost is:

Gs = { StartCheckout }  

When the attacker submits ConfirmCheckout, the server evaluates the request against Gs.

The transition is not reachable.

The request is rejected and classified as a behavioral anomaly.

As part of anomaly handling:

• the access token is immediately invalidated
• the active session is terminated
• the legitimate user is required to re-authenticate

This response assumes credential compromise and prioritizes containment over attribution.

This corresponds to the blocked transition path shown in the SBAC diagram, where an out-of-sequence action is rejected before any state mutation occurs.

C# example: anomaly response (revoke token, force re-auth, lockout)

public interface ITokenRevocation  
{
    ValueTask RevokeAsync(string tokenId, CancellationToken ct);
}

public interface IAccountLockout  
{
    ValueTask RegisterAnomalyAsync(string subjectId, SbacAnomaly anomaly, CancellationToken ct);
    ValueTask<bool> ShouldLockoutAsync(string subjectId, CancellationToken ct);
    ValueTask LockoutAsync(string subjectId, TimeSpan duration, CancellationToken ct);
}

public sealed class SbacResponsePolicy  
{
    private readonly ITokenRevocation _revocation;
    private readonly IAccountLockout _lockout;

    public SbacResponsePolicy(ITokenRevocation revocation, IAccountLockout lockout)
    {
        _revocation = revocation;
        _lockout = lockout;
    }

    public async ValueTask HandleAnomalyAsync(ClassifiedClient client, SbacAnomaly anomaly, CancellationToken ct)
    {
        // Always revoke the token used in the anomalous request (credential misuse assumption).
        if (!string.IsNullOrWhiteSpace(client.TokenId))
            await _revocation.RevokeAsync(client.TokenId!, ct);

        // Track anomalies for escalation decisions.
        if (!string.IsNullOrWhiteSpace(client.SubjectId))
        {
            var subject = client.SubjectId!;
            await _lockout.RegisterAnomalyAsync(subject, anomaly, ct);

            if (await _lockout.ShouldLockoutAsync(subject, ct))
                await _lockout.LockoutAsync(subject, duration: TimeSpan.FromMinutes(15), ct);
        }

        // “Force re-auth” is typically implemented by refusing future requests
        // until a fresh token is minted (e.g., 401 + prompt login).
    }
}

20. Why This Matters

This attack is realistic and common:

• tokens are stolen via XSS, malicious extensions, compromised devices, or leaked logs
• the attacker does not need to escalate privileges
• the attacker uses the system exactly as designed, just out of sequence

The request was:

• authenticated
• authorized
• syntactically valid

It was rejected solely because it was not correct in the current state.

SBAC treats this as more than a failed request.

A behavioral anomaly indicates likely credential misuse. As a result:

• the token is revoked
• the user is prompted to re-authenticate
• the event is logged and correlated

Repeated anomalies originating from the same identity, device, or network context may trigger:

• progressive trust degradation
• temporary account lockout
• secondary verification requirements

SBAC does not try to prevent token theft.
It assumes credentials will eventually be compromised.

SBAC ensures that compromised credentials cannot be used to violate system behavior silently.

In SBAC, invalid behavior is not only blocked, it is used as a signal to actively protect the user.

21. Relationship to RBAC and ABAC

RBAC and ABAC still apply.

They determine who may act and under what conditions.

SBAC determines when actions are possible.

22. Limitations

SBAC does not prevent server compromise.

It enforces correctness of client interaction, not the purity of execution.

23. Conclusion

State-Based Access Control formalizes a class of security checks that most systems already attempt informally.

By making interaction state explicit, server-authoritative, and enforceable, SBAC closes the gap between “allowed” and “correct.”

By assuming credential compromise and enforcing correctness at the interaction layer, SBAC shifts security from prevention alone to continuous behavioral enforcement.

Clients do not navigate reality.
They propose inputs.
The server decides what is reality.

⚠️This article is for educational and engineering purposes only. It does not constitute financial advice, investment recommendations, or trading signals. Use the information at your own risk. Currency markets are volatile, and you should do your own research before making any financial decisions.

In the first iteration called the tides model, we looked at market behavior as surface tides of predictable oscillations captured by NickRypock Trailing Reverse (NRTR) and NickRypock Moving Average (NRMA) indicators.

They expressed the visible rhythm of market movement, the waves, if you will, that traders "surf" on.

But beneath that surface lie deeper currents!

Liquidity pockets, order flow imbalances, and liquidation clusters act like thermohaline currents, quietly steering large-scale behavior long before it’s visible above.
Meanwhile, sentiment events and social cascades act as storms, transferring sudden bursts of energy into the market’s atmosphere.

The new model, called the ocean model now introduces three-layers inspired by fluid dynamics:

• Surface Layer (Tides) observable price motion
• Subsurface Layer (Underflows) liquidity, order flow, and liquidation dynamics
• Atmospheric Layer (Storms) sentiment and emotional energy

Together, these layers form a coupled system of forces that can explain how market energy builds, transfers, and releases!

The Roaring Ocean Model

Each layer exchanges energy with the others:

• Subsurface imbalances precede large moves.
• Surface waves translate deep motion into price.
• Sentiment perturbs the whole system from above.

This represents the hydrodynamic energy balance of the market in one large expressive formula. Now, let's break this down in it's parts, and code!

The Market Tides Composite Index

At each timestep _t, given by streaming candles, order data, and sentiment state, the total market energy can be represented as the Market Tides Composite Index:

where:

• T_t = surface tide strength
• U_t = subsurface underflow strength
• α_t = atmospheric sentiment pressure
• G_t = nonlinear coupling amplifier
• w_T, w_U, w_S = layer weights (w_T + w_U + w_S = 1)

Below is the equivalent C# implementation:

public sealed class MtciParams  
{
    public double wT = 0.5, wU = 0.35, wS = 0.15;
    public double wL = 0.6, wShrt = 0.4;
    public double OFP = 0.6, LHF = 0.4;
    public double cT = 1.25, cO = 1.0, cH = 1.0, cS = 1.0;
    public double g1 = 0.4, g2 = 0.6, gMax = 2.0;
    public double Eps = 1e-9; // ε safeguard
}

public sealed class MtciEngine  
{
    private readonly MtciParams _p;
    public MtciEngine(MtciParams p) => _p = p;

    public double Compute(double price,
                          double nrmaL, double nrtrL,
                          double nrmaS, double nrtrS,
                          double ofp, double lhf,
                          double alpha)
    {
        double T_L = Math.Tanh(_p.cT * ((nrmaL - nrtrL) / Math.Max(price, _p.Eps)));
        double T_S = Math.Tanh(_p.cT * ((nrmaS - nrtrS) / Math.Max(price, _p.Eps)));
        double T = _p.wL * T_L + _p.wShrt * T_S;

        double U = _p.OFP * ofp + _p.LHF * lhf;

        double G = 1.0 + _p.g1 * Math.Abs(ofp) + _p.g2 * Math.Max(0.0, lhf);
        G = Math.Min(G, _p.gMax);

        return _p.wT * G * T + _p.wU * U + _p.wS * alpha;
    }
}

Surface Layer (Tides)

The surface layer measures how NRMA and NRTR diverge the “height” of the market wave across long and short timeframes:

Below is the equivalent C# implementation:

public sealed class NRTR  
{
    public double K { get; }
    private double _trend;
    private double _h, _l, _rev;

    public double Reverse => _rev;
    public double Trend => _trend;

    public NRTR(double k, double initial)
    {
        K = k;
        _trend = +1;
        _h = initial;
        _l = initial;
        _rev = initial;
    }

    public double Update(double close)
    {
        if (_trend >= 0)
        {
            if (close > _h) _h = close;
            _rev = _h * (1.0 - K * 0.01);
            if (close <= _rev)
            {
                _trend = -1;
                _l = close;
                _rev = _l * (1.0 + K * 0.01);
            }
        }
        else
        {
            if (close < _l) _l = close;
            _rev = _l * (1.0 + K * 0.01);
            if (close >= _rev)
            {
                _trend = +1;
                _h = close;
                _rev = _h * (1.0 - K * 0.01);
            }
        }
        return _rev;
    }
}

public sealed class NRMA  
{
    public double K { get; }
    public int Fast { get; }
    public int Sharp { get; }
    private NRTR _nrtr;
    private double _prev;
    private readonly Queue<double> _recent = new();

    public double Value => _prev;

    public NRMA(double k, int fast, int sharp, double initial)
    {
        K = k; Fast = fast; Sharp = sharp;
        _nrtr = new NRTR(k, initial);
        _prev = initial;
    }

    public double Update(double close)
    {
        double r = _nrtr.Update(close);
        double osc = (100.0 * Math.Abs(close - r) / Math.Max(close, 1e-12)) / Math.Max(K, 1e-12);
        _recent.Enqueue(osc);
        while (_recent.Count > Math.Max(3, Fast)) _recent.Dequeue();

        double avg = 0.0;
        foreach (var v in _recent) avg += v;
        avg /= _recent.Count;

        double F = 2.0 / (1.0 + Fast);
        double rho = F * Math.Pow(avg, Sharp);

        _prev = _prev + rho * (close - _prev);
        return _prev;
    }
}

Subsurface Layer (Underflows)

The underflow layer models two invisible but powerful forces:

1. Order Flow Pressure (OFP_t):

where B_d and A_d are bid/ask volumes within depth d.

2. Liquidation Heat Flux (LHF_t):

These combine into:

Below is the equivalent C# implementation:

public static class Underflows  
{
    public static double Ofp(double cO, double bidsDepthSum, double asksDepthSum, double eps = 1e-9)
    {
        double num = (bidsDepthSum - asksDepthSum);
        double den = (bidsDepthSum + asksDepthSum + eps);
        return Math.Tanh(cO * (num / den));
    }

    public sealed record LiqEvent(bool IsShort, double Price, double Size, DateTime TimeUtc);

    public static double Lhf(double cH,
                             IEnumerable<LiqEvent> events,
                             double currentPrice,
                             double advVolume,
                             DateTime nowUtc,
                             double lambdaDist = 0.002,
                             double lambdaTime = 0.001,
                             double eps = 1e-9)
    {
        double up = 0.0, down = 0.0;
        foreach (var e in events)
        {
            double dist = Math.Abs(e.Price - currentPrice);
            double dtSec = Math.Max(0.0, (nowUtc - e.TimeUtc).TotalSeconds);
            double w = Math.Exp(-lambdaDist * dist) * Math.Exp(-lambdaTime * dtSec);
            if (e.IsShort && e.Price > currentPrice) up += e.Size * w;
            if (!e.IsShort && e.Price < currentPrice) down += e.Size * w;
        }

        double num = (up - down);
        double den = Math.Max(advVolume, eps);
        return Math.Tanh(cH * (num / den));
    }
}

Atmospheric Layer (Storms)

The storm layer captures exogenous sentiment energy:

where Z_ssst is the z-scored sentiment index from social sources (e.g., Twitter).

Below is the equivalent C# implementation:

public sealed class ZScore  
{
    private readonly int _win;
    private readonly Queue<double> _buf = new();
    private double _sum, _sum2;
    private readonly double _eps;

    public ZScore(int window = 300, double eps = 1e-9)
    { _win = window; _eps = eps; }

    public double Update(double x)
    {
        _buf.Enqueue(x);
        _sum += x;
        _sum2 += x * x;
        if (_buf.Count > _win)
        {
            double y = _buf.Dequeue();
            _sum -= y; _sum2 -= y * y;
        }

        int n = _buf.Count;
        double mu = _sum / Math.Max(1, n);
        double var = Math.Max(0.0, _sum2 / Math.Max(1, n) - mu * mu);
        double sigma = Math.Sqrt(var);
        return (x - mu) / Math.Max(_eps, sigma);
    }
}

public static class Storms  
{
    public static double Alpha(double cS, double zScore) => Math.Tanh(cS * zScore);
}

Coupling Amplifier

Just as deep currents magnify surface waves, the coupling term G_t modulates how underflows amplify tides:

Below is the equivalent C# implementation:

public static class Coupling  
{
    public static double Gain(double ofp, double lhf, double g1, double g2, double gMax = 2.0)
    {
        double g = 1.0 + g1 * Math.Abs(ofp) + g2 * Math.Max(0.0, lhf);
        return Math.Min(g, gMax);
    }
}

The roaring ocean

Once all layers are computed, we integrate them into an event / loop that runs each market tick (or candle close). This determines whether to enter, exit, or stay out based on the Market Tides Composite Index and the state of each layer!

Below is the equivalent C# implementation:

public sealed class Logic  
{
    private readonly MtciEngine _engine;
    private readonly double _entry, _exit, _halt;

    public Logic(MtciEngine engine, double entryThreshold = 0.7, double exitThreshold = 0.3, double haltThreshold = 0.85)
    {
        _engine = engine;
        _entry = entryThreshold;
        _exit = exitThreshold;
        _halt = haltThreshold;
    }

    public enum SignalType { None, Long, Short, Exit, Halt }

    public SignalType Evaluate(double price,
                               double nrmaL, double nrtrL,
                               double nrmaS, double nrtrS,
                               double ofp, double lhf,
                               double alpha)
    {
        double mtci = _engine.Compute(price, nrmaL, nrtrL, nrmaS, nrtrS, ofp, lhf, alpha);

        // Storm halt condition — too much sentiment pressure
        if (Math.Abs(alpha) >= _halt)
            return SignalType.Halt;

        bool longTrend = (nrmaL > nrtrL) && (nrmaS > nrtrS);
        bool shortTrend = (nrmaL < nrtrL) && (nrmaS < nrtrS);

        if (longTrend && mtci >= _entry) return SignalType.Long;
        if (shortTrend && mtci <= -_entry) return SignalType.Short;

        if (Math.Abs(mtci) < _exit) return SignalType.Exit;

        return SignalType.None;
    }
}

Evaluation:

// Test: called once per candle update
void OnNewCandle(Candle c)  
{
    var nrmaL = nrmaLong.Update(c.Close);
    var nrmaS = nrmaShort.Update(c.Close);
    var nrtrL = nrtrLong.Update(c.Close);
    var nrtrS = nrtrShort.Update(c.Close);

    var ofp = Underflows.Ofp(paramsOFP, totalBids, totalAsks);
    var lhf = Underflows.Lhf(paramsLHF, liquidationEvents, c.Close, advVolume, DateTime.UtcNow);
    var alpha = Storms.Alpha(paramsStorm, sentimentZ);

    var signal = logic.Evaluate(c.Close, nrmaL, nrtrL, nrmaS, nrtrS, ofp, lhf, alpha);

    Console.WriteLine($"{c.Time}: Signal={signal}");
}

⚠️This article is for educational and engineering purposes only. It does not constitute financial advice, investment recommendations, or trading signals. Use the information at your own risk. Currency markets are volatile, and you should do your own research before making any financial decisions.

Currency markets often feel like standing on a shoreline. Slow tides rise and fall, smaller waves crash on top, and sometimes storms disrupt everything! This is the biases for an idea i had called the tides, or ocean model.

• The Long Tide: The big swells that lift or lower all boats. In markets, this is the slow trend captured by an adaptive moving average.

• The Short Tide: The quick in-and-out waves. In markets, these are the short-term reversals we track with a trailing reverse line.

• The Storm Surges: Sudden shocks from the weather. In crypto, this is Twitter sentiment, where one influential tweet can make or break a trade.

The goal: align trades with both tides, but pause or adjust when a storm blows in!

We’ll break this down into math, C# implementations, and how to combine them across timeframes for assets like ETH, IMX, and GODS.

System Architecture

At a high level, the model has three components:

1. Price Indicators (NRMA, NRTR)

   • Run separately on long intervals (daily, weekly) and short intervals (3m, 5m).
   • Each produces trend and reversal markers.

2. Sentiment Layer

   • Tracks influencer Twitter accounts for each coin.
   • Produces a normalized “storm surge” score.

3. Composite Signal Logic

   • Combines long tide, short tide, and sentiment into actionable trades.

Indicator Engineering

Nick Rypock Trailing Reverse (NRTR)
The short tide is modeled with NRTR, a trailing stop algorithm that flips trend when price crosses a reversal line.

Formulas:

• In uptrend:
  
• In downtrend:
  

C# Implementation:

public class NRTR  
{
    public double K { get; private set; }
    public double Trend { get; private set; }
    public double HPrice { get; private set; }
    public double LPrice { get; private set; }
    public double Reverse { get; private set; }

    public NRTR(double k, double initialPrice)
    {
        K = k;
        Trend = 1; // assume initial uptrend
        HPrice = initialPrice;
        LPrice = initialPrice;
        Reverse = initialPrice;
    }

    public double Calculate(double close)
    {
        if (Trend >= 0)
        {
            if (close > HPrice)
                HPrice = close;

            Reverse = HPrice * (1 - K * 0.01);
            if (close <= Reverse)
            {
                Trend = -1;
                LPrice = close;
                Reverse = LPrice * (1 + K * 0.01);
            }
        }

        if (Trend <= 0)
        {
            if (close < LPrice)
                LPrice = close;

            Reverse = LPrice * (1 + K * 0.01);
            if (close >= Reverse)
            {
                Trend = 1;
                HPrice = close;
                Reverse = HPrice * (1 - K * 0.01);
            }
        }

        return Reverse;
    }
}

Nick Rypock Moving Average (NRMA)
The long tide is modeled with NRMA, an adaptive EMA where volatility is defined by deviations from NRTR.

Formulas:

Where:

C# Implementation:

public class NRMA  
{
    public double K { get; private set; }
    public int Fast { get; private set; }
    public int Sharp { get; private set; }
    public NRTR nrtr { get; private set; }
    public double prevNRMA { get; private set; }

    public NRMA(double k, int fast, int sharp, double initialPrice)
    {
        K = k;
        Fast = fast;
        Sharp = sharp;
        nrtr = new NRTR(k, initialPrice);
        prevNRMA = initialPrice;
    }

    public double Calculate(double close, double[] recentCloses)
    {
        if (recentCloses.Length <= Fast)
        {
            prevNRMA = close;
        }
        else
        {
            double oscSum = 0;
            var count = Math.Min(3, recentCloses.Length);

            for (var i = recentCloses.Length - count; i < recentCloses.Length; i++)
            {
                double deviation = 100 * Math.Abs(recentCloses[i] - nrtr.Calculate(recentCloses[i])) / recentCloses[i];
                oscSum += deviation / K;
            }

            double oscAvg = oscSum / count;
            var NRratio = Math.Pow(oscAvg, Sharp);
            double F = 2.0 / (1 + Fast);

            prevNRMA += NRratio * F * (close - prevNRMA);
        }

        return prevNRMA;
    }
}

Sentiment Scoring from Twitter

Instead of monitoring the entire internet, the model watches curated influencer accounts per coin (e.g., Vitalik for ETH, Immutable devs for IMX, Gods Unchained accounts for GODS).

Pareto Principle in Sentiment Design

Not all voices on Twitter move markets equally. In fact, by the Pareto principle, roughly 20% of accounts generate 80% of meaningful price impact.

Instead of processing millions of tweets, the model only tracks curated influencer accounts for each asset:

• For ETH, that might mean Ethereum core devs and Vitalik.
• For IMX, Immutable team members.
• For GODS, the Gods Unchained project leads.

This drastically reduces cost and noise, while retaining the majority of predictive power.
The result is a lightweight, event-driven storm surge model instead of a full-blown NLP pipeline.

Formulas:

C# Implementation:

public class TwitterSentiment  
{
    private readonly Dictionary<string, int> _weights;
    private readonly List<(DateTime, int, int)> _events;

    public TwitterSentiment(Dictionary<string, int> influencerWeights)
    {
        _weights = influencerWeights;
        _events = new List<(DateTime, int, int)>();
    }

    public void AddTweet(string account, string text)
    {
        int polarity = ClassifyPolarity(text);
        if (_weights.TryGetValue(account, out int weight))
            _events.Add((DateTime.UtcNow, polarity, weight));
    }

    public double CalculateScore(TimeSpan halfLife)
    {
        double sum = 0;
        foreach (var (timestamp, polarity, weight) in _events)
        {
            double ageHours = (DateTime.UtcNow - timestamp).TotalHours;
            double decay = Math.Pow(0.5, ageHours / halfLife.TotalHours);
            sum += weight * polarity * decay;
        }
        return sum;
    }

    private int ClassifyPolarity(string text)
    {
        string lower = text.ToLower();
        if (lower.Contains("hack") || lower.Contains("exploit") || lower.Contains("lawsuit"))
            return -1;
        if (lower.Contains("launch") || lower.Contains("upgrade") || lower.Contains("partnership"))
            return 1;
        return 0;
    }
}

Multi-Timescale Integration

We maintain two indicator sets per asset:

• Long Tide: NRMA-long, NRTR-long → daily/weekly candles.
• Short Tide: NRMA-short, NRTR-short → 3m/5m candles.

Composite Signal Logic:

• Long if both long + short are bullish and sentiment ≥ 0.
• Short if both long + short are bearish and sentiment ≤ 0.
• No trade otherwise.

Example (Eth):

double ethLong = nrmaLong.Calculate(dailyClose, dailyRecentCloses);  
double ethLongRev = nrtrLong.Calculate(dailyClose);

double ethShort = nrmaShort.Calculate(min5Close, min5RecentCloses);  
double ethShortRev = nrtrShort.Calculate(min5Close);

double ethSentiment = twitterEth.CalculateScore(TimeSpan.FromHours(3));

if (ethLong > ethLongRev && ethShort > ethShortRev && ethSentiment >= 0)  
    Console.WriteLine("ETH Long");
else if (ethLong < ethLongRev && ethShort < ethShortRev && ethSentiment <= 0)  
    Console.WriteLine("ETH Short");
else  
    Console.WriteLine("No Trade");

Closing

By structuring the market like an ocean system, tides, waves, and storms. We get a model that's both intuitive and implementable.

• NRTR and NRMA provide the price structure.
• Twitter sentiment adds a low-cost shock filter.
• Multi-timescale integration ensures coherence.

This is not a trading strategy by itself, but a blueprint for engineers to test, refine and learn. There are many variables in the algorithms above which are purposefully not explained. I also did not provide weights for the social scoring algorithm which is likely better replaced with an ai driven sentiment model rather than a simple word database! These are issues left to the reader to solve.

⚠️This article is for educational and engineering purposes only. It does not constitute financial advice, investment recommendations, or trading signals. Use the information at your own risk. Currency markets are volatile, and you should do your own research before making any financial decisions.

On 3/10/2024 the Council of Mortals asked me to audit the sealed portion of the Gods Unchained client to verify if it was actually possible to use cards that where not in your sealed pool, in your sealed deck. This audit was limited in scope to sealed, and validation that the exploit found only affected sealed.

This post is disclosure of that process. It's important to note that before disclosure. This exploit was fixed on 3/20. It's unknown if the method proposed in this audit was used to fix the exploit. However, testing after the 3/20 patch, i can validate this exploit is no longer working at this time.

TLDR

Question: Could you save your sealed deck with cards not in your pool?
Answer: Yes, if you know the proto id of the card, or cards you want.

Question: Can you still do this?
Answer: No.

Exploit

This exploit could be preformed by capturing and saving requests from inside the client, and then replaying those same requests with the new proto ids you want within the time period it's still valid (about 120 seconds).

Note: Fiddler Everywhere was used to capture, modify, and replay the traffic for this audit.

While the scope of this audit was the sealed api, i did take the time to validate if the same injection method was usable in ranked / casual, however, in those modes there is an "ownership" check that prevents this type of injection. Sealed mode does not contain that check so that you can play in sealed with cards you don't own if they are also assigned in your random pool.

Solution

The active sealed sessions API call list's ALL of the cards (proto's) in our random pool. There needs to be a check on the Save Deck API call that double checks that the proto id's (cards) saved in the array are in fact also in the array of proto's (cards) in our pool. If proto's (cards) are contained that DO NOT match, then, AccessDenied should be returned and the deck should not be saved.

Details

Full disclosure this audit was preformed on my personal GU account, no games where played with this modified sealed session. Once proof was gathered, the sealed run was abandoned (RIP 5 gods). This can be verified with the sealed session id in the JSON listed below.

Get Sealed Session

This API call will list the active sealed session for a player. It also includes our card_pool which has a list of all proto id's (cards) that we were randomly assigned at the time of buy in.

→ GET gamemode.prod.prod.godsunchained.com/user/{guid}/gamemode/7/session

• Requires
  • guid
    This is a players id in game. It can be retrieved through various methods.

← Returns

{"id":"0072e0cb-7c09-4e45-8e27-0726368b2dff","user_id":436860,"buy_in_id":"dd58db39-9cb2-4598-85ec-60fc0c2b85e4","game_mode_global_id":7,"god_pool":["nature","death","magic"],"card_pool":[1132,2002,1605,87061,1159,1680,87056,1215,1605,2325,1604,2328,1260,1165,1130,1154,1673,1616,1032,1293,2003,1245,1295,1122,1248,1294,1122,1011,1532,1751,1083,1122,1292,2263,1182,87069,1243,1245,87067,1698,1564,87049,1570,2257,1168,1668,1753,1045,1092,1043,1092,2313,2257,1676,2311,1081,1101,1551,1081,2311],"deck_id":9864282,"god":"","properties":{"paid":true,"max_wins":7,"max_losses":3,"buy_in_cost":5,"buy_in_currency":"gods"},"win":0,"loss":0,"status":"started","created_at":"2024-03-10T21:01:36.781066Z","updated_at":"2024-03-10T21:49:26.542857Z"}

Save Deck

This will save a deck with the information contained in the payload. There is no validation made that cards saved are in the pool list above, at the the time of this audit. I did also test trying to use a god you where not assigned at the time of buy in, but this did not work, if you try and use god not assigned you assigned your first god in the list of gods.

→ PUT deck.prod.prod.godsunchained.com/user/{guid}/deck/{deckid}

• Requires
  • guid
    This is a players id in game. It can be retrieved through various methods.
  • deckid
    This is the deck id assigned to the current active sealed session. You can get this id from the "Get Sealed Sessions API" response.

Payload

{"id":9864282,"name":"Nature Deck","god":"nature","deck_type":"restricted","ids":[233795109,228897085,78293701,198293435,73982871,209542666,225424635,142817595,221197551,97683802,192815310,64983360,151796170,33781472,226470054,190607562,247505996,193939540,33781468,222887919,233179866,205775320,64892233,64906060,196212367,206068833,168162048,21083152],"protos":[2003,2311],"timestamp":1710104643994,"game_mode_id":7}

← Returns

9864282  

Set Deck

This is used to set the current deck used in sealed. It's mostly a hold over from in the UI from the other modes where you can change decks. You can't actually give a deck id other than the one originally assigned when the session is created.

→ PUT gamemode.prod.prod.godsunchained.com/user/{guid}/session/{sessionid}/deck

• Requires
  • guid
    This is a players id in game. It can be retrieved through various methods.
  • sessionid
    This is the session id assigned to the current active sealed session. You can get this id from the "Get Sealed Sessions API" response.

Payload

{
    "deck_id": 9864282
}

← Returns

null  

Her hands, once busy with love's labor, teaching young minds,
In the chill of life's harsh winters, she was that warmth that binds.
A guardian angel, through struggles, she did veer,
In her eyes, a spark of kindness, in her voice, love clear.

Her life, a tapestry of courage, stitched with patience, thread by thread,
In her grandchildren, her spirit echoes, in every step ahead.
Though her presence now is missing, in hearts, she'll always dwell,
For in every act of kindness, her story I continue to tell.

Since this is the first post, this update will also contain a short summary of the project. Roughly 2 weeks ago, i decided i wanted to build a robot from Gods Unchained. This is something i used to do for fun, though, previously i had to stop building them due to time constraints.

The original plan was to build a glorified RC car, with a camera, self-balancing, and an android controller. However, with the ability, and expressed interest from outside parties in bidding for the robot. It's overall design evolved from an RC car, to a more "alive" design using a series of AI models to govern it's actions.

The current plan is to use an Nvidia Jetson Nano, potentially combined with an Intel Neural Compute Stick 2 to provide enough computing power to run YOLO, Urban Sound, and Gesture models in real time. Will also be adding a speaker, a mic, and some small 6v solar panels on the top of the robot.

Updates

1. Jetson nano base image has been updated to support the intel ncs2, was erroring on boot without first unplugging the ncs2. However a hotplug change seemed to resolve this! Now works rebooting without any issues.

2. New hardware showed up this week!

   • Raspberry PI 5
     Decided not to use this over the Jetson Nano, mostly due to power draw concerns. We want to keep the power draw as low as we can for battery life, and the PI 5 can draw up to 3 amps more than the Jetson Nano at full load.
   • USB Audio Dongle
     This is a simple dongle from Amazon by Adafruit. No issues, or quality problems with it.
   • Olympus ME-52W Microphone
     This is a microphone designed for recording audio in a room, it's often used in Olympus audio recorders which are common in corporate, and government environments due to there quality.

3. Work has started on 3d modeling the motor casing for the robot. Progress can be seen in the image below.

Goals

The main goals for next week are to bring the 3d modeling for the motor casing closer to completion. It would be great to have our first test prints by next stream, or the latest being the stream after next. I would also like to get the Jetson Nano image completed by next stream so that testing of the 3d models can begin. Ideally, we will need to monitor memory, and overall resource usage on the jetson with all 3 models running at once. This way if any resource problems arise we can start to plan for them early on!

That's it for this week. Make sure to check out my stream on Twitch every Saturday at 1pm - 5pm, or follow me on Twitter for more updates as the build progresses!

Microsoft .NET provides a host of ways to train, and consume AI models. This includes both online (azure), and offline (ml.net). By default all code samples will be utilizing CPU pipelines for maximum compatibility. However, if you have a modern GPU that supports CUDA you should be able to utilize GPU pipelines as well as CPU pipelines with minimal code changes.

Requirements

First we need to create an empty C# .NET 6 or higher project in your editor of choice (mine is often Visual Studio).

Next, we need to install the packages we require, in this tutorial that's only one package. You can install this using nuget console, or just searching out the package by name using manage packages in your ide.

Install-Package Microsoft.ML  

Models

Not to be confused with AI models, most modern programming paradigms also have a concept known as "models". These models are structures meant to represent how pieces of data look.

When working with AI models you will almost always need a minimum of two models.

1. A model that represents the structure of our input data.

public class InputData  
{
    [LoadColumn(0)]
    public string Text;

    [LoadColumn(1)]
    public string Label;
}

Note: LoadColumn specifies the order in which we intend the data to be in.

1. A model that represents the structure of our output data.

public class OutputData  
{
    [ColumnName("PredictedLabel")]
    public string Prediction { get; set; }
}

Note: ColumnName in our model also represents the column in the output data that we want.

Training

Model training requires data that matches our input structure we specified above. Normally this data is supplied through a data set that's often in the form of a spreadsheet, or database. This typically requires sanitizing, or shaping the data before it's use. However, in this article we will just be hard coding a training set of data for the purpose of education.

var data = new List<InputData>  
{
    new InputData { Text = "Hello", Label = "Greeting" },
    new InputData { Text = "Bye", Label = "Farewell" },
    new InputData { Text = "Can you check order", Label = "OrderStatus" }
};

Next, we need to load our data into a format that the Microsoft.ML pipeline can consume for training.

var context = new MLContext();  
var trainingData = context.Data.LoadFromEnumerable(data);  

Next, we need to fit, and train our model with the data we going to be giving it. Further, because pipelines are designed to be generic. We also need to set various settings letting the pipeline know what we are training, and finally which output columns we should be populating our results.

var pipeline = context.Transforms.Conversion.MapValueToKey(inputColumnName: "Label", outputColumnName: "Label")  
.Append(mlContext.Transforms.Text.FeaturizeText(inputColumnName: "Text", outputColumnName: "Features"))
.Append(mlContext.MulticlassClassification.Trainers.SdcaMaximumEntropy("Label", "Features"))
.Append(mlContext.Transforms.Conversion.MapKeyToValue("PredictedLabel"));

var model = pipeline.Fit(trainingData);  

Consuming

Finally, we can start testing our new model! We can do this by first creating an engine for our training model. In this case, a prediction engine.

var engine = context.Model.CreatePredictionEngine<InputData, OutputData>(model);  

Next, we can create a sample input and pass it to our model for classification (prediction).

var sentence = new InputData { Text = "Can you check order 12345?" };  
var intent = engine.Predict(sentence);

Console.WriteLine($"Text: {sentence.Text}");  
Console.WriteLine($"Intent: {intent.Prediction}");  

Lastly, we can see that our sentence contains an entity, or in this case an order number. Once we determine that the intent of the sentence to get the status of that order, we can then work on extracting that entity ourselves.

if (intent.Prediction == "OrderStatus") {  
    var orderIdRegex = new Regex(@"order\s(\d+)");
    var match = orderIdRegex.Match(sentence.Text);
    if (match.Success)
    {
        Console.WriteLine($"Entity: {match.Groups[1].Value}");
    }
}

This is a basic explanation of how this might work in an intelligent application.

Intent

When you receive text you need to parse the biggest question will always be, "What is the intent of this message?". This can be further compounded when multiple intents are expressed in the same message as, "What are all of the intents of this message?". Especially when speaking through speech to text were we often try and cram as much information as we can in a short period of time.

The illustration above shows extracting multiple intents from a single message. The first intent is a greeting. This indicates a polite person with a positive mood, it might mean returning a greeting in response. The second intent is the actual purpose of the message. In this case someone is requesting a status update for an order.

Entities

Once you have established intent for a message. You might find that you need to extract more detailed information that should otherwise exist. This might be an email, url, social handle, number etc.. These bits of information only have a clear meaning when attached to there supposed intent.

This illustration shows that the message has given us a "greeting" and is looking for an "order status" update. This establishes the intent of our message. The second intent, which is also the primary purpose of the message, and contains 2 parts of information we might need.

1. The first is a number which because we know the intent is to get a status update for an order, this number should be our order id.

2. The second part of the information is the location of that order. In this case the message is saying on a website we should know about.

Events

Mapping a series of intent's to an event is a common way of dealing with "What to do" once you have extracted the intention of a message with it's corresponding entities. This can be done by tagging each intent with an easy to understand name which also represents the method(s) that should trigger when the matching intent is found.

The first intention we have found can be labeled as a "Greeting". This can be mapped to an "OnGreet" event which selects a proper greeting based on the current time of day. Such as, "Good morning", "Good afternoon", or "Good evening".

The second intention we have found can be labeled as "OrderStatus". This can be mapped to an "OnOrderStatus" event which then checks the matching API, using the extracted entities found in the intent. Then constructing a response with the correct order status information, or an error if the order, or status can't be found.

Steam Deck

The steam deck is a powerful, by default Linux based handheld gaming system released by Valve. The price (at the time of writing) can range from $399 to $649. There is also likely a wait time before shipment as there just being released.

To me, the most powerful thing about the steam deck, is the fact that SteamOS is actually just Archlinux with Valve/Steam's logo on it. More importantly we have full root access to OS out of the box! Bravo Valve!

Gods Unchained

Gods Unchained is a blockchain based trading card game from Immutable. Currently, you can only play Gods Unchained on a PC, Mac, or Linux (unofficial support). You can read more about the game here. I highly recommend you check it out if you like trading card games!

Below are the steps required to install gods unchained on the steam deck using steam, and proton 7. Please note that while this "can" be done using the virtual keyboard in desktop mode. This method WILL NOT be covered here. Instead, the steam deck charge power also doubles as a USB-C hub. It's assumed that you have connected a mouse + keyboard.

Desktop Mode

The steam deck has 2 modes. Desktop Mode, and Game Mode. By default the steam deck will boot in Game Mode. In order to enter Desktop Mode you need to:

1. While running in Game Mode. Hold down the power button for 2 - 3 seconds. This will open a menu on the steam deck.
2. Navigate to Switch to Desktop. This will cause the steam deck to reboot into a windows looking desktop.

On the desktop you will see an icon labeled "Return to Game Mode". You can click on this to return to previous mode you where in. If you have not yet connected a keyboard to the USB-C power port using a USB-C hub, you should do so now.

Download Immutable

By default the steam deck comes with Firefox installed. You can also install Chrome. Ideally you can install which ever browser you plan to use Metamask, or another browser extension with in order to access the Immutable X market place. Both browsers can equally be added as a "non-steam" application for use in Game Mode.

1. Open a web browser, and navigate to godsunchained.com.
2. Click the Play Gods Unchained button, and download the Immutable exe to your downloads folder.
3. You may wish to search for "gods unchained logo" using an image search in the browser of your choice while you download. You may need it, and a background image later for steam launcher.

Install Immutable

You can install immutable, and most applications in steam as non-steam games. This is a two step process that requires first adding the installer, then, removing it. Then adding the exe that was just installed onto your steam deck with the installer as it's own non-steam game.

1. Open Steam, it's icon should be located on the desktop next to the Return to Game Mode icon.
2. In the bottom left of the steam interface, click the Add Game button. Scroll to the Add Non-Stream Game option in the menu.
3. Click Browse in the Add Game interface. Then navigate to the Immutable exe in your downloads folder located at /home/deck/Downloads.
4. Click Add Selected Program at the bottom of the Add Game interface.
5. Navigate to the steam library in steam. Library -> Home and search for "Immutable" you should see the immutable exe you added before.
6. Right click the exe in the library and select Properties.
7. Click the Compatibility tab on the left hand side.
8. Check off "Force the use of" option.
9. Select Proton 7.0-N where N is the larger number in the list for 7.0. Other versions may work but this is the only version I have tested.
10. Close the Properties window using the X in the upper right. Then click the Play button for the Immutable exe in your steam library.
11. Follow the install steps, do not change any paths during install, just use the defaults provided by the installer.
12. Once the installer completes and your at the login screen. Close the Gods Unchained application clicking the X in the upper right corner. While you shouldn't have any issues playing from here, it's unlikely to save your login information while still using the installer thread.
13. Right click on the Immutable installer in the steam library and select the remove non-steam game option. You don't need the installer anymore.

Note: Your screen may flicker, or flash while the Gods Unchained login screen is loading the Palis animation for the first time. It's unknown if this is Proton, or the steam deck causing this, however, if you just wait, it will self correct. This is also true for the first run in Game Mode.

Add Gods Unchained

Now that gods unchained is installed! We need to tell steam where it's located. We can then tell steam which version of proton to use, optionally which icon, and background image to use, and then finally, play!

1. If you closed steam before. You will need to reopen it. It's icon should be located on the desktop next to the Return to Game Mode icon.
2. In the bottom left of the steam interface, click the Add Game button. Scroll to the Add Non-Stream Game option in the menu.
3. Click Browse in the Add Game interface. Then navigate to the Immutable launcher exe in your steam folder located at: /home/deck/.local/share/Steam/steamapps/compatdata/4117854237/pfx/drive_c/users/steamuser/AppData/Local/Programs/immutable-launcher/immutable.exe.
   Note: The numbers in the path above are randomly created at the time install. They won't be the same as what's above. You can sort the compatdata folder by date/time to help locate which numbered folder contains the launcher you installed.
4. Click Add Selected Program at the bottom of the Add Game interface.
5. Navigate to the steam library in steam. Library -> Home and search for "Immutable" you should see the immutable launcher exe you added before.
6. Right click the exe in the library and select Properties.
7. Click the Compatibility tab on the left hand side.
8. Check off "Force the use of" option.
9. Select Proton 7.0-N where N is the larger number in the list for 7.0. Other versions may work but this is the only major version I have tested.
10. If you downloaded an icon before you now navigate to the Shortcut Tab and change the game icon. You may wish to do this even if you did not download a logo as you can also change the Shortcut name from Immutable to "Gods Unchained".
11. Close the Properties window using the X in the upper right.
12. If you downloaded a background image. Right click on the grey space in the library with the Gods Unchained (or Immutable if you did not rename it) application and select "Set Background Image".
13. Exit steam in desktop mode. Then click the Return to Game Mode icon. While you can play in Desktop Mode, ideally, you do not want too.

You should now see Gods Unchained (or Immutable if did not rename) in your Stream Library, and your Recent Games list in Games Mode. Steam will not record time played in this mode :( but you can still use the steam overlay, and chat with friends while in game.

You can use the touch screen to play!

There are some minor issues:

1. 50% of the time holding down your finger on a card in your hand, or on the board will show the popup showing what that card is, and 50% of the time it will do nothing at all.
2. The options, and report bug buttons at the upper right are very hard to click with your finger.
3. Mana pips can some times take a few taps to trigger due to there small button size. All, in all however, the game is extremely playable with little to no lag with High settings.

Facebook is a veritable giant in the AI modeling world. It has trained models to locate fringe, angry, and emotionally fragile people. Then, rather than remove, or help those people. They have decided it was best to experiment with them. To see how far they could manipulate these people into following, and interacting with content that they curated just for them. Further, they experimented with how long they could entice users to remain engaged with content of the same type. The content they where curating was not harmless. It was specifically curated to target emotions that AI models had detected in the previous groups of people that where easiest to stimulate into interacting with.

Basically, through extreme research, facebook found out you can get people who are on the fringe edges of society to click on content that validates, or re-enforces there world view. They, also, found out you can manipulate those same people into repeatedly click on content that continues to validate there views more aggressively if there are fewer sources outside of facebook that they can find the same level of re-assurance that they are not alone. That means, crazier the content. The more likely it was only on facebook, and that meant the people looking for re-enforcement from that type of content, would remain on facebook longer. The more people they could target, the more data they built up, and in turn, the more accurate the there ability to create curated content streams that can be interacted with for longer, and longer.

Regardless of why facebook was created, or what it offers us today. The main reason facebook now exists is to build a massive empire of data. The reason facebook is one of the worlds largest contributors to the artificial intelligence modeling in the world is because they needed advanced enough methods to harvest that much data. They want to target people with high enough accuracy that advertisers will pay them top dollar to have there ads placed with the highest chance for interaction. Regardless of what that interaction is! In the end, facebook is nothing more than a system for stimulating hate, fear, and depression because it's easy to make money.

Social media as a concept is not wrong. Companies, like facebook, who then use that information to target the easiest to manipulate among us, for profit! IS. NOT. RIGHT.

Modeling the ball

My tool of choice for modeling is, well, my web browser. I have found that Tinkercad has been one of the least complicated modeling tools i have been able to learn. Modeling is not my day job, nor should i ever expect it to be! There is some serious limits with what Tinkercad can do in relation to SketchUp, or similar much more complex tools. However, this works for me.

I started with taking a 3d sphere in tinker cad, and expanding to a reasonable size. In this case, reasonable means i could at least fit a single Raspberry PI zero, and a battery with some left over space for servos and wires. To simulate this i created a square box with the height and width to fit all of the above hardware. I then expanded the sphere to contain the box in the center. This was enough that any future size needed could be obtained though scaling the model.

I had to hollow out the sphere while leaving enough of a wall not to sacrifice too much integrity. Followed by cutting the sphere in half for easy access to it's inside. The original Tocker did have what appeared to be a horizontal cut up to his face in which case the cut line simply vanishes. Obviously i needed a full cut line, and it was going to be a problem horizontal if i also wanted solid eye sockets. So i decided i needed to go with a vertical cut.

Deciding how re-attach the ball was going to be a challenge. Normally i depend on a typical dowel rod style attachment setup in my designs. While effective, it also tends to help hold the shape of objects that are tossed around. However, being i was likely to need constant access to the inside of the ball, i decided that dowels would most likely break.

Steam punk style braces where considered, and honestly i might still add them anyway because they look cool. However, ultimately i went with a screw design. Being able to screw, and unscrew the ball felt like the perfect medium for what i was looking for. After searching Thingiverse before trying to embed the nut, and bolt myself into the ball. I managed to find this. After modifications i was able to expand the screw ball to match the sphere i had just modeled exactly. Through some test prints, the ball was able to screw, and unscrew perfectly (provided it was printed without supports near the screw grooves).

Modeling the features

Features, consist of 4 separate models. Once they where each created they could be merged, or wrapped with the ball.

The eye sockets

The eyes from my perspective where simplistic. The previous ball i had created before finding the the screw ball was resized, duplicated and hollowed out a second time to match the size of the camera lenses i was planning to use. The incredibly difficult part was calculating and then measuring to the exacting placement with the slight offsets for each eye to provide a clean widescreen merged image, in addition to being used as separate sources.

The face plate

The face plate was one of the more difficult things for me to model. Like I've stated before modeling is not my job, and i am not a professional. It took me some time to wrap my head around the shapes i needed to combine to create the face plate. More difficult was how to actually wrap the face plate around a circular surface area.

The antenna

The antenna was pretty easy after having completed the other two models already which where far more challenging and educational. More or less the antenna is just 4 triangles formed into 2 diamonds all merged together. I then duplicated it and used the second to hollow out the first so that a small antenna, and circuit board, and 2 wire can fit inside.

The beak

I had tried a few variations on the beak. The first was using half of the diamond from the antenna as a beak triangle. This worked well enough, but since i planed to add a speaker for audio. It made more sense to open the mouth. So i cut the triangle in half, and carefully split it until it formed an open looking mouth, with, enough of a hole for audio to pass though from a speaker behind it.

What's next

While part of the goal of this project has been to bring to life a Tocker from Team Fight Tactics. The ultimate goal has been to create a telepressence unit that can travel with me. Providing a birds eye shoulder view of what i see and do. Automatically classifying objects around it, able to direct, and follow it's own curiosities. While also providing a pleasing interface for on looking humans to interact with the environment. Stay tuned for part 2!

If this is being read by anyone on the pi-top team. Then please consider reselling, or at the very least creating a newer more compatible pi-top for tinkers. I would love to continue pushing what they can do. Thank you for your work non the less.

A few years ago I had made a post about the pi-top and a child-hood dream I had of creating a modular PC for developers. With the joy, and success I had creating the previous pi-top. I decided to build another, this time creating in the form of a cluster of pi's contained inside the pi-top known as the pi-top cluster. This time around i wanted to expand on what the cluster could do by upgrading it with a new raspberry pi 4 and adding hardware specifically to help with offloading execution of tensorflow, and yolo models in real time with an IR camera.

The Idea

My day, to day job(s), consist of programming in JavaScript, and C# as well as managing a large farm of Servers, Web containers, Redis nodes, SQL servers, Database containers, Elastic pools and Storage pools in Microsoft Azure, Amazon Web Services, and physical on-site servers.

Most of the side jobs i find beyond the above work tend to revolve around AI work in tensorflow, and caffe such as simplified predictors for logging, load balancing in more rare cases price prediction. With more advanced methods for image classification, object detection, brand detection, speech to text, and text to speech.

The goal this build was to create a system that could both train, and execute most of the models that i work with in relation to face detection, face identification, object detection, image classification, speech to text, and text to speech. The Neural Compute Stick 2 from Intel can do most of this on it's own though does depend on the system it's attached.

While the controller (pi4) is being used for Camera input. Ultimately the idea will be to remove the camera on the controller, and instead use 2 camera's each on it's own pi zero w creating a left, and right eye for robotics work. One eye would ideally be an IR camera while the other would be a more traditional camera. These eyes will stream back to the controller over wifi using ffmpeg, rtms, and nginx.

Hardware

• Pi-Top Original Laptop Shell (not sold anymore?)
• Pi-Top Proto
• Raspberry PI 4 (4 GB)
• ClusterHat
• 4x Raspberry PI Zero W
• Neural Compute Stick 2
• IR Camera (720p - 60 FPS)
• 5x SD Card (Class 10 - 32 GB)
• Raspberry Pi 4 Model B Fan
• Micro HDMI Adapter (Type-A F - Type-D M)
• USB Type C Cable (1ft)
• 2x USB Disk Drive (64 GB)
• USB 2.0 Hub (4 Port)
• USB 2.0 Extension Cable (1ft)
• USB Audio Adapter
• Noise Canceling Microphone

Design

The design follows much of the original design issues i had when creating the cluster version. You can read more about the issues faced in that build here. Similar to the previous build. The primary issue with this upgrade was space. Fitting everything together while also allowing the pi-top lid to slide close was a tall order... One i was not able to meet this time unlike the previous build. This turned out however to be for the best since the second issue this upgrade faced was distribution of heat in the case. Had the lid been left closed for too long devices would have started to overheat. Finally, there was also the change to USB Type-C for power, and Micro HDMI for video in the Raspberry PI 4.

I will be creating a future blog detailing the software being used here, a long with issues that occurred getting everything to work together. This blog will also include source code used to create a distributed ai system over ip as well as the 2 eye system explained above in the idea section. Stay tuned to this blog for more information if this sounds interesting to you.

Thank you for reading!

Update: The Pi-Top has reached out to me and provided me with a free v1 to continue future projects with. Thanks Pi-Top team!! <3. I will be considering what to do with the new v1... perhaps something more solar driven this time!