Michael Anthony

Blaze Balance Engine SaaS new update

by

Blaze Balance Engine SaaS beta update:

We’re now deep into the controlled Shopify connection architecture phase, and the product has moved from “concept shell” into a real Laravel beta with safety-gated infrastructure.

The current beta is focused on proving the connection, tenant, OAuth, and token-vault architecture before allowing any live customer data flow.

What is working now:

The Laravel beta app is live in its private beta environment.

The users table has been repaired and confirmed working.

Core tenant tables are present:

  • tenants

  • workspaces

  • shopify_stores

  • tenant_user

The encrypted Shopify token vault table is present:

  • shopify_oauth_tokens

The token vault smoke test passed earlier with columns, indexes, foreign keys, and empty vault posture verified.

The encrypted token service stub has been tested using fake sample data only.

The token storage approval gate is working as a non-persistent review flow.

The OAuth exchange dry-run receipt room is installed.

The OAuth exchange approval and state-binding stub is installed.

The OAuth state nonce generator preview is installed.

The OAuth state vault design room is installed.

The latest migration approval gate is now installed for the future Shopify OAuth state vault.

Where we are now:

Blaze can now preview the future Shopify OAuth state lifecycle without storing anything yet.

That includes:

  • issuing a future state receipt

  • binding state to tenant/workspace/store/operator context

  • showing fingerprint-only receipts

  • previewing one-time-use state consumption

  • previewing replay rejection

  • previewing expired state rejection

  • previewing session mismatch rejection

  • previewing rollback posture

  • showing the future migration structure before it is created

This is intentionally not live OAuth yet.

No real Shopify tokens are stored.

No authorization codes are stored.

No raw OAuth state is displayed.

No raw token is displayed.

No encrypted token is displayed.

No Shopify API writes are enabled.

No webhooks are enabled.

No tenant enforcement is enabled.

No migration has been run for the future OAuth state vault yet.

That is the point of this stage: we are building the lock system before opening the door.

The latest beta room previews the future shopify_oauth_states table, including:

  • state fingerprint

  • payload hash

  • signature hash

  • session fingerprint

  • tenant binding

  • workspace binding

  • Shopify store binding

  • operator user binding

  • expiry window

  • consumed-at marker

  • replay tracking

  • callback receipt reference

  • redacted metadata only

The goal is to make Shopify OAuth state one-time-use, auditable, replay-resistant, tenant-bound, and safe before enabling any real exchange path.

What is still left before first test users:

  1. Create the actual OAuth state vault migration file.

The next step is to move from migration preview to migration-file draft. This still should not automatically run anything. It should prepare the migration file, show the pretend command plan, and keep approval separate.

  1. Run a controlled migration after review.

After the migration file is reviewed, we can run a controlled migration for the future shopify_oauth_states table.

No migrate:fresh.

No migrate:refresh.

No seed reset.

Just the specific approved migration path.

  1. Seed or create the first tenant/workspace/store records.

Right now the tenant tables exist, but the tenant, workspace, and Shopify store rows are still empty. Before real test users, Blaze needs a clean first tenant record, workspace record, store record, and tenant-user link.

  1. Connect OAuth state persistence to the future callback flow.

Once the state vault table exists, the system can move toward a real persisted OAuth state flow:

  • issue state

  • store only safe hashes/fingerprints

  • bind to tenant/workspace/store/operator/session

  • reject replay

  • reject expiry

  • consume once

  • write a safe callback receipt

  1. Keep OAuth exchange behind a separate approval gate.

Even after state persistence works, OAuth exchange should remain disabled until specifically reviewed and unlocked.

The exchange path should only activate after:

  • state vault is working

  • callback validation is working

  • tenant binding is working

  • token vault is ready

  • rollback plan is documented

  • operator approval is explicit

  1. Enable encrypted token storage only after state exchange is proven.

Token storage is its own separate gate.

The system should not persist live Shopify access tokens until:

  • OAuth exchange is working safely

  • state replay protection is working

  • token vault insert path is tested

  • token redaction is verified

  • revocation and rotation notes are ready

  1. Add first read-only Shopify data bridge.

The first real data connection should stay read-only.

The goal is not “AI writes to Shopify.”

The first goal is:

  • read store status

  • read basic shop metadata

  • read product/order/inventory signals where allowed

  • normalize them into Blaze signals

  • show explainable recommendations

  • keep human review in the loop

  1. Prepare the first tester flow.

Before inviting first test users, we still need:

  • tester login flow polished

  • workspace selection flow

  • first tenant dashboard

  • safe empty-state screens

  • reviewer/tester explanation copy

  • clear “read-only beta” disclosure

  • operator-only areas separated from tester areas

  • backup/rollback checklist

  • error logging and smoke-test checklist

The important part:

Blaze is not being rushed into live OAuth or token storage.

The current architecture is being built like an airlock:

Observe. Preview. Approve. Migrate. Bind. Validate. Persist safely. Read only. Then invite testers.

This is the right path for a serious SaaS product, especially one that will eventually connect to commerce systems like Shopify.

The beta is not ready for public users yet, but it is getting close to first controlled test-user readiness.

Right now, the remaining work is mostly about moving from preview rooms to controlled persistence, then from controlled persistence to read-only real data, then from read-only real data to private tester onboarding.

We are not building an AI that secretly takes action. We are building a control room that explains what it sees, records what it recommends, and keeps humans in the approval loop.

https://www.kickstarter.com/projects/blazeai/blaze-balance-engine-saas

https://beta-blaze.420bt.com

2 views

Add a comment

Replies

Be the first to comment