Patent Architecture Map

Visual guide to how the 19 MicroStax patents map onto the control-plane pipeline, runtime components, and user workflows.

This page is the visual companion to the patent family guide. Use it when you want to understand the novelty of the system quickly: which patents sit where in the pipeline, which runtime components they affect, and which user workflows they unlock.

1. Patent Pipeline Map

Click top-right to expand

The order matters:

  • 01, 02, 03, and 05 decide what should exist
  • 06, 10, and 11 decide how sparse environments behave at runtime
  • 12, 15, 14, and 16 decide whether environments can relocate safely across sovereignty zones
  • 07, 04, 08, and 09 decide whether those environments can be replayed, audited, and safely promoted
  • 13, 17, 18, and 19 decide how the system is verified, visualized, and billed

2. Five Patent Layers

Click top-right to expand

This is the clearest way to understand the portfolio:

  • Layer 1 makes sparse environments possible
  • Layer 2 makes them deterministic
  • Layer 3 makes them mobile and residency-compliant
  • Layer 4 makes them replayable and governable
  • Layer 5 makes them auditable, visual, and economical

3. Component Map

Click top-right to expand

The portfolio is not concentrated in one subsystem. It spans:

  • planning
  • runtime identity and routing
  • replayable execution state
  • validation and promotion evidence

4. Artifact Map

PatentMain artifact or mechanism
01difference graph
02ancestry chain and resolution graph
03provisional provisioning plan
04snapshot graph and replay package
05optimization record
06provider mapping and routing artifacts
07conflict graph and conflict report
08executable environment graph and execution state
09mirror session and diff report
10routing context identifier and propagation record
11canonical identity and resolved identity record
12sovereignty decision artifact
13audit envelope and integrity manifest
14relocation token and custody record
15resource demand vector and quota reservation
16handover plan and healing artifact
17trust metric and render-state artifact
18counterfactual closure and cost attribution
19usage record and graph-epoch reconciliation

This artifact trail is where much of the novelty lives. The system keeps turning graph state into reusable machine-readable control artifacts rather than discarding decisions after provisioning.

5. Product Workflow Map

User workflowPatent support
baseline create01, 02, 08
overlay create01, 02, 05, 06, 11, 12
route requests into overlay06, 10, 11
env relocate across zones12, 14, 15, 16
env snapshot create04, 08
env replay04, 08
env diagnose and trust inspection17, 13, 08
governance-safe promotion07, 09, 08, 12
behavioral diff review09, 11, 10
cost and ROI analysis18, 19, 05
long-horizon audit forensic13, 04, 08

This is why the platform feels integrated. The same patent family supports CLI workflows, dashboard visibility, and operator review paths.

6. Novelty Summary

The platform is novel not because any one feature is individually impossible to imagine. The novelty is in the control-plane composition:

  • sparse realization is graph-derived, not manually selected
  • inheritance is lineage-aware, not a loose proxy convention
  • routing uses explicit provider and identity artifacts
  • snapshots preserve replay meaning, not only data state
  • runtime execution persists state back into the graph lifecycle
  • validation and promotion consume graph-aware evidence rather than ad hoc checks

That is what makes MicroStax feel like a next-generation environment system instead of a simpler wrapper around Kubernetes objects.

Patent Architecture Map | MicroStax Documentation