OSH GLOBAL SYSTEMS, INC. APPLIED RESEARCH / 2026

FARO / PROPRIETARY AI ARCHITECTURE

Intelligence thatmakes decisionsinside hardware.

FARO is the AI developed by OSH Global Systems, Inc.: a proprietary intelligence architecture that runs on a machine’s own processor. It receives signals, maintains an internal state and uses that evolving state to select a response or action.

Designed for robots, industrial machinery and embedded devices. Its core operation runs locally, without an LLM runtime, cloud inference or an external AI API.

FARO THE AIOSH GLOBAL SYSTEMS, INC. THE COMPANY

PC execution → cross-target validation → three physical processor families.

OSH Global Systems orbital emblem
OSH / THE COMPANY From internal state to observable action.

01 / WHAT IS FARO?

From an input
to a chosen action.

FARO is a proprietary AI architecture for making decisions locally, inside a machine.

FARO is implemented in code that runs on the processor. It connects incoming information, an evolving internal state and the selection of a response.

Its internal state is a set of values that carries forward from one cycle to the next. A new signal changes that state; FARO evaluates possible responses from its current condition.

The processor supplies the computing hardware.
FARO supplies the intelligence architecture running on it.

Explore the architectureState, continuity, attention and action
01 / INPUTInformation arrivesSensors or internal conditions
02 / FAROA response is selectedEvolving state · evaluation
03 / ACTIONAn output followsElectrical output or selected action

FARO is the AI. OSH Global Systems, Inc. is the company. The technical reports also use “OSH” or “OSH substrate” for the frozen computational architecture under validation. Those historical names are retained in the evidence and original documents.

ARCHITECTURE / TECHNICAL DESCRIPTION

FARO is a new autonomous computational architecture that gives a machine an internal condition that continues, a way to evaluate change and a path from selection to physical action. Its validated causal route runs locally on microcontroller silicon. Physical evidence now spans ESP32-S3, STM32F446RE / ARM Cortex-M4, and CH32V307 / RISC-V.

We are not porting an application built on top of an AI model.

We are porting the underlying intelligence architecture on which applications and physical systems can be built.

  • Not a chatbot connected to a robot.
  • Not an application calling an AI API.
  • Not an agent built around an LLM.
00 / WHAT IS FARO
THE ARCHITECTURE / EXPLAINED

A new architecture for autonomous computation.

FARO is a homeostatic semantic organism: a computational architecture with its own evolving internal state. A signal changes that state, attention evaluates possible paths, and selection connects the process to meaning or physical action. What happens in one cycle can shape the next.

01 / A STATE THAT CONTINUES

It carries its history into the next moment.

Most people see a machine react to an input. Inside FARO, the relevant starting point is its current endogenous condition. New signals alter a trajectory; the result is not treated as an isolated request.

02 / AN INTERNAL DECISION PATH

Attention and selection have a causal place.

The Homeostatic Attention Loop (HAL) evaluates candidates against that changing condition. A selector then chooses an edge in compact semantic structure. Language can express an outcome; it does not direct the tested route.

03 / ACTION IN THE PHYSICAL WORLD

The mechanism can close a real loop.

In the validated ESP32-S3 experiment, physical input perturbed FARO, the local route selected an action, and a real circuit returned feedback. The paper checks five internal causal levels against the PC reference.

FARO has its own computational authority.

It is a new architecture, not an LLM, a remote API or a prompt-driven agent. Its defining mechanism is persistent state, trajectory, homeostatic attention and selection, operating locally without cloud inference for the validated route.

FARO / FOLLOW THE LIVING LOOPINTERACTIVE MODEL
01 / SIGNAL

An event becomes a change in state.

A sensor reading, an internal need or another perturbation enters a mechanism that already has a condition and a history. Select each stage to see how the cycle develops.

FARO is not the application.
FARO is the intelligence architecture being transported from one physical substrate to another.

WHAT IS ACTUALLY BEING MIGRATED?

Not an application.
The intelligence architecture itself.

FARO is the computational intelligence architecture being moved from one physical substrate to another.

What is preserved across these migrations is the same proprietary architecture: a system designed to receive information about its environment or internal state, maintain and transform its own internal state, and determine a response or action.

WHAT IS FARO FOR?

FARO is designed to provide local intelligence to physical and embedded systems — robots, industrial machinery, autonomous equipment, drones, vehicles and IoT devices — without requiring an LLM runtime, cloud inference or an external AI API for its core operation.

FARO is the intelligence architecture executing inside the hardware.

A simple example:

In a robot, sensors provide information about the physical world. FARO processes the system state locally and produces the decision or action that can drive motors, actuators or other outputs.

05 / ARCHITECTURE

Inside the causal path.

Select a stage to see its role and the evidence boundary that supports it. State persists; each input affects a trajectory rather than an isolated response.

STAGE 01 / INPUT

Perturbation

A signal from the environment or system perturbs persistent state. In the physical experiment, an analog reference enters through GPIO3 and feedback returns through GPIO2.

EVIDENCE: ADC → OSH → PWM/RC → ADC LOOP
FEEDBACK / CONTINUITYINPUTC/P/X/T/HVORTEXHALSELECT
The parity test compares five causal levels, including the identity of the selected edge. Internal equations, coefficients, and geometry remain protected.
02 / FARO ON A PC FIRST ON A PC
INTEL ATOM D2500 · CPU ONLY · 12 SEP 2026
B3 01 / PC STAGE

Benchmark 3.
FARO on a PC.

This is the first measured stage of the OSH journey. The recording shows José Fabián typing in the real OSH PC interface. The report measures its resident runtime on an Intel Atom D2500 under a controlled 30-input protocol.

REAL SCREEN / OSH ON PCDEMO.MP4 · 00:46

The recording shows the conversation and the OSH / STRUCTURAL TELEMETRY panel. It documents the interface in use; the reproducible measurements are in the report.

Open demo.mp4 ↗
PROTOCOL / 30 INPUTSGPU = 0
OSH MEDIAN6.466 ms

Structured resident runtime cycle.

TINYLLAMA 1.1B · ONE TOKEN18,186.463 ms
MEDIAN RUNTIME RATIO2,812.69×
WORKING SET / OSH → TINYLLAMA24.883 → 662.770 MB
Protocol and resultsDownload Benchmark 3 ↓View report in browser ↗
SCOPE OF THE MEASUREMENT

The comparison measures runtime and Working Set under the stated protocol: TinyLlama was limited to one token per input. The computational tasks differ; the ratio does not measure intelligence, language quality, or equivalent task performance.

03 / MIGRATING THE ARCHITECTURE
PC → VERIFIED CORE → SILICON

A migration you can trace

The bridge from PC to silicon, tested step by step.

OSH began on a PC. In plain language, this benchmark asks whether its same core can be translated for many processors and still reproduce the expected behavior on a different instruction set. The frozen Tier-A code compiled across target profiles; its original validation harness then passed on a virtual RV32IMF. These steps established a portable core to carry into the physical ESP32-S3 validation documented below.

OSH / UNIVERSAL SUBSTRATE BENCHMARKVALIDATION / 23 SEP 2026
EVIDENCE 01 / CROSS-TARGET COMPILATION

One frozen core. Multiple target profiles.

The original SHA-256-verified Tier-A core and header generated objects for 21 of 22 profiles across x86, ARM, RISC-V, MIPS, PowerPC, SPARC, LoongArch64 and WASM32. The tested m68k profile failed; object generation alone does not prove physical execution on those targets.

COMPILE PASS21 / 22m68k / NOT PASSED
FROZEN ARTIFACTS / SHA-256 VERIFIEDCOMPILATION → VIRTUAL GOLDEN PARITY → PHYSICAL SILICON
What the benchmark establishes

The original Tier-A harness ran on an emulated RV32IMF and passed both golden cases, OSH_PRESENCE and OSH_NO_ACTIVATION. Maximum absolute error was ≤5×10⁻⁸ against the existing 10⁻⁶ threshold; the observed Top-K candidate order held. Physical ESP32-S3 results are documented separately in the technical paper below.

NEXT FRONTIER / PHYSICAL MIGRATION

Other target families now have a concrete path to investigation. Each future board still needs its own execution, causal-parity, timing, power and integration tests; compiling a profile is the first step, not the final proof.

03 / MORE DETAILExplore the full migration sequencePC baseline · compiled targets · virtual golden cases · physical boards
01 / THE JOURNEYONE ARCHITECTURE · MULTIPLE FORMS OF PROOF

WHY THE PHYSICAL MIGRATIONS MATTER

From a PC to physical silicon.

The central technical question is straightforward:

Can the same OSH architecture preserve its behavior when the physical processor underneath it changes?

CHAPTER 01 / THE HOSTOSH / EVIDENCE RECORD
RESIDENT RUNTIME6.466 ms

First, establish a working baseline.

Benchmark 3 measures OSH on a CPU-only Intel Atom D2500. It records 30 structured inputs and a resident runtime. This is a PC result, not a microcontroller timing claim.

Watch the PC recording and read Benchmark 3
PHYSICAL TARGET / QUALIFIED 09 OCT 2026RISC-VPreviously the next physical milestone. Now: 30/30 parity cases and 100,000 native physical cycles. Explore the new evidence ↗
Migration scope & validation methodComputational substrates, test sequence and evidence boundaries

The purpose is not simply to demonstrate that OSH can be compiled for another processor.

The purpose is to determine whether the same underlying architecture preserves its validated behavior while moving across different physical processor families.

We are testing that question progressively across different computational substrates:

  1. PC / Reference Execution
  2. Universal Substrate Benchmark
  3. ESP32-S3 — Physical Execution
  4. STM32F446RE / ARM Cortex-M4 — Physical Execution
  5. RISC-V — Physical Execution · CH32V307 · 09 Oct 2026 (previously the next target)

OSH began as a resident architecture on a computer. The next question was whether its mechanism could be carried beyond that machine and still preserve the behavior it was built to produce. Explore each step, then open the actual measurements below. The journey extends through a second physical processor family on STM32F446RE / ARM Cortex-M4 and now a third on CH32V307 / RISC-V.

THE IDEA IN ONE LINE

Develop the causal path → carry its frozen core across targets → verify the original behavior on another ISA → test the route on real ESP32-S3 hardware. Then extend physical validation to STM32F446RE / ARM Cortex-M4, followed by CH32V307 / RISC-V.

What crosses the boundary?

A frozen OSH computational substrate and its original validation harness. Virtual RISC-V execution and physical ESP32-S3 execution are separate tests. The ESP32-S3's main CPU is Xtensa; the RV32IMF result is a virtual cross-ISA test.

04 / PHYSICAL MIGRATION

The architecture.
On three physical
processor families.

After the PC baseline and the virtual golden-case checks, the next step was execution on real microcontrollers.

Each physical record tests a defined route through the architecture, with state checks and electrical feedback. The boards and test scopes are identified below.

01 / XTENSA

ESP32-S3

The first physical migration.
Two boards, with comparison against the PC reference.

150 / 150causal checks across 30 cases
at five internal boundaries
100,000 physical cycles0 reported ADC failures · 0 state failuresExplore ESP32-S3 evidence
02 / ARM

Cortex-M4

The second processor family.
STM32F446RE with a physical DAC-to-ADC loop.

30 / 30structural-parity cases
passed on the physical target
100,000 physical cycles0 reported ADC failures · 0 state failuresExplore ARM evidence
03 / RISC-V

CH32V307

The third processor family.
Native execution on QingKe V4F hardware.

30 / 30structural-parity cases
passed on the physical target
100,000 physical cycles0 reported ADC failures · 0 state failuresExplore RISC-V evidence

RECOVERED ELF FILES / 05 NOV 2026

Embedded memory
evidence.

Recovered ELF files add image-size and static-memory accounting to the native hardware records. These whole-firmware figures include startup, drivers and libraries: they bound the linked implementation of the tested native paths, not a complete FARO installation. Each target retains its own measurement method and level of artifact identification.

ESP32-S3

STEP20 / CANDIDATE ELF287,668 BELF file-backed allocated sections
Identified DRAM data + BSS
26,408 B
Internal heap free at 100K
368,691 B
PSRAM free at 100K
16,774,624 B
Minimum unused task stack
440 B

The recovered ELF matches the historical boot-hash prefix. Identified DRAM is not total RAM; free heap and unused stack are separate runtime observations.

STM32F446RE

ARM CORTEX-M4 / RECOVERED 100K ELF69,516 BELF text + data · approximately 67.89 KiB
Static RAM, excluding stack
6,156 B
Reserved stack
1,536 B
Static RAM + stack reserve
7,692 B

GNU size output on the named 100K ELF. Three preserved copies have identical SHA-256. These are local file measurements; deployed flash was not independently read back.

CH32V307

RISC-V V2 100K / ARCHIVED HASH MATCH83,708 BELF file-backed allocated sections
Static RAM, excluding stack
5,444 B
Reserved stack
2,048 B
Static RAM + stack reserve
7,492 B

The V2 100K ELF matches the archived full SHA-256. Sizes were obtained by parsing ELF sections. These figures replace the earlier R1 figures for the 100K build.

Measured firmware for defined native paths. Image size, static RAM, reserved stack and free memory describe different quantities. They do not measure the complete FARO architecture or peak runtime RAM. File recovery and accounting are owner-side evidence; independent physical reproduction remains pending.

Download memory evidence ↓PDF · 4 pages · recovered ELF records · 05 Nov 2026
Artifact identities, measurement methods and corrections
  • ARM 100K: GNU size reports 69,200 B text, 316 B data and 7,376 B BSS including the 1,536 B reserved stack. Static RAM excluding that reserve is 6,156 B; the matching BIN is 69,516 B, consistent with the historical 67.89 KiB programming figure. The recovered file is osh_stm32_100k.elf; its digest is distinct from the separately named UART ELF in the earlier report. Recovered ELF SHA-256: 98a420f518d51bbd2d7a797d87df8b2cf825189181d1d7c53ada6ec1d2b95aa1. Byte-identical local copies do not substitute for deployed-flash readback.
  • RISC-V V2 100K: the parsed sections contain 83,556 B code/read-only data, 152 B initialized data and 5,292 B BSS excluding stack. The RISC-V size utility was not executed. Archived and recovered V2 ELF SHA-256: cb9f88f38e755cb82f51fdfe0bf8000ff0963eb774195e1b3b965ae1975c1517. The earlier R1 record remains a different artifact: 86,124 B image, 5,484 B static RAM and 2,048 B reserved stack. It must not be substituted for V2.
  • ESP32-S3 Step20: 13,304 B of .dram0.data plus 13,104 B of .dram0.bss gives 26,408 B identified DRAM. Layout-only dummy sections are excluded. The boot-log segment sum is 287,672 B, while the application BIN file is 287,792 B; neither is the same measurement as the 287,668 B ELF section sum. Recovered candidate ELF SHA-256: 41bbe7034913664437e4204819df1facb645767cb752807a207a207928c58540. Only its 41bbe7034... prefix can be matched to the historical boot log.
  • ESP32 percentage correction: a prior PSRAM percentage calculation reported 0.14% because of 32-bit arithmetic overflow. The report gives approximately 99.98% free using 64-bit arithmetic on the preserved absolute values. That automatic percentage gate was not a clean full PASS. The absolute 100K free-memory records and the gate result remain distinct.
  • Runtime and architecture scope: reserved stack is capacity, not measured peak use. The 440 B task-stack high-water mark is minimum unused space. Firmware images cover specified native state/decision paths; they do not establish that every FARO component, including the complete language system, runs in these images. These recovered-file measurements add no new hardware endurance run or independent certification.
04.1 / ESP32-S3ESP32-S3: measurements, paper and original imagesCausal parity · 100K loop · oscilloscope · board-level power
04 / PHYSICAL MIGRATION

The OSH causal path reached real ESP32-S3 hardware.

After the PC baseline and portability checks, the physical paper verifies the architecture’s tested causal route on two real ESP32-S3 boards: state, trajectory, attention, selection and meaning, followed by action through an analog feedback circuit. Explore the measured results, their limits, and the new board-level power observation.

FROM HOST TO ESP32-S3

The tested architecture moved from PC to physical silicon.

The portability work tested the frozen computational core beyond the PC. The physical paper then documents native OSH execution on two ESP32-S3 units and 150/150 PC–MCU causal-parity checks across state, trajectory, HAL candidates, selected edge and meaning. The validated route also drove PWM, received analog feedback and completed 100,000 cycles.

PC · BASELINECORE · PORTABILITYESP32-S3 · PHYSICAL PROOF

The paper validates the tested architecture route on ESP32-S3 silicon. It does not claim that every interface, physical modality or other target board has been validated.

PC → PORTABILITY → ESP32-S3150/150PARITY AT FIVE LEVELSDownload technical paper ↓View paper ↗
ESP32-S3 / FINAL EXPERIMENT

The system interacted with a real circuit.

B25K reference → ADC GPIO3 → OSH → PWM GPIO14 → external 1 kΩ / 100 µF network → ADC GPIO2. The policy exercised all three observable actions.

100,000PHYSICAL CYCLES
29.525 µsINTERNAL PATH MEAN
0 / 0ADC / STATE FAILURES

INC 5,160 · HOLD 93,358 · DEC 1,482. PHYSICAL_100K_GATE and FINAL_LATCH: PASS. An oscilloscope image preserves a representative 23.0 µs path pulse; this is a separate measurement method and does not replace the internal mean.

30 SEP 2026 / PHYSICAL POWER OBSERVATIONBench-supply evidence with the regulated source, physical ESP32-S3 board and analog test circuit in the same frame. Enlarge ↗
BOARD-LEVEL INPUT POWER / PHYSICAL ESP32-S3

~0.134 W observed at the complete physical setup.

With USB power disconnected, the physical ESP32-S3 setup was powered directly from a UNI-T UTP3315TFL-II regulated bench supply. The display held at 4.97 V and 0.027 A for five minutes.

~0.134 WBOARD-LEVEL INPUT POWER
4.97 VSUPPLY VOLTAGE
27 mASTEADY CURRENT / 5 MIN

Measurement boundary: complete board-level physical setup. This is not isolated SoC power and not a logged high-bandwidth energy-per-decision measurement.

METHODDirect regulated bench supply; USB power disconnected. OBSERVATION0.027 A remained stable for the full five-minute observation window. CALCULATION4.97 V × 0.027 A = 0.13419 W → reported as approximately 0.134 W.
07 / VISUAL RECORD

External instrumentation, in view.

Photographs preserved in the physical validation paper. Open each image for a closer look.

These captures document different measurements. They must not be added together or directly compared with the PC benchmark median.

04.2 / ARMARM Cortex-M4: measurements and whitepaper30/30 parity · 100K loop · DAC/ADC example · original images

A REAL EXAMPLE / PHYSICAL ARM TEST

Choosing an electrical output.

View the measurements
01 / INPUT

Read a signal.

The board reads a physical voltage through its analog input.

ADC / ELECTRICAL INPUT
02 / FARO

Select an action.

FARO processes its state and selects whether to increase, hold or decrease the output.

INCREASEHOLDDECREASE
03 / OUTPUT

Produce a voltage.

The board turns the selected action into an analog electrical output.

DAC / ELECTRICAL OUTPUT

The electrical output travels through a real circuit and returns to the input for the next cycle.

100,000 physical cycles. Zero reported ADC failures. Zero state failures.

STM32F446RE / ARM CORTEX-M4

OSH now runs on
physical ARM silicon.

A public technical record of the OSH evidence path from PC and the Universal Substrate Benchmark to physical ESP32-S3 and the new STM32F446RE / ARM Cortex-M4 validation. The paper separates compilation, virtual execution and real-silicon evidence, and reports only externally supportable measurements.

NEW TECHNICAL WHITEPAPER / OCT 2026Physical Cross-Architecture Evidence.
STM32F446RE / ARM CORTEX-M4
30 / 30ARM STRUCTURAL PARITY / PASS
100,000PHYSICAL ARM CLOSED-LOOP CYCLES
0 / 0ADC FAILURES / STATE FAILURES

How to read the parity totals. ARM: 30 test cases passed the structural-parity gate. ESP32-S3: 150 checks across 30 cases at five causal boundaries. The totals describe different test scopes.

These results provide evidence that OSH is not merely producing a binary for another target: the architecture is executing and interacting with physical hardware while preserving the tested behavioral invariants.

ARM validation summaryParity, closed-loop cycles and physical observations

On ARM, the migration has already progressed beyond compilation:

  • 30 / 30parity cases passed
  • 100,000physical closed-loop cycles
  • 0ADC failures
  • 0state failures
Physical DAC → ADC interaction External oscilloscope observation
Explore the physical ARM evidence
04.3 / RISC-VRISC-V: native execution and physical evidence30/30 parity · 100K loop · timing · board-level power · original images

05B / New physical milestone · 09 October 2026

The architecture.
Now on physical RISC-V.

The frozen OSH computational substrate behind FARO has crossed another processor boundary: CH32V307VCT6 / QingKe V4F at 96 MHz, with a real DAC-to-ADC feedback loop.

14-page public report · native execution, PID comparison, scope captures and power evidence

100,000Native physical closed-loop cycles
30 / 30Structural-parity cases passed
0ADC failures · state failures · invalid actions
284 µsOne externally observed wrapper interval
EXPERIMENT A / NATIVE EXECUTION

Inside the RISC-V chip.

The firmware samples the physical input, advances the frozen substrate’s state and policy, and writes the analog output. This is the 100,000-cycle native hardware run.

EXPERIMENT B / HOST-CONTROLLED COMPARISON

FARO V2 and PID on the PC.

In the separate matched comparison, both controllers run on the host PC. The CH32V307 board supplies the physical DAC/ADC plant over UART. Read the PID comparison ↓

Original oscilloscope capture supplied with the report. The displayed cursor interval is 284 µs. The PNG preserves every pixel of the supplied BMP.

External observation / PA8

Measured across the physical wrapper.

284 µs

The supplied oscilloscope capture observes one PA8-marked interval from the wrapper’s ADC-read boundary to its DAC-write boundary.

Across 100,000 cycles, the native TIM2 counter reports 281 µs minimum, 361 µs maximum and 356.843 µs mean, with zero timer overflows.

These are different measurement records. The single scope interval is neither a latency distribution nor an isolated measurement of the intelligence core.

Download original oscilloscope BMP ↓
Native protocol, electrical qualification and complete run counters

Physical route: PA4 / DAC1_OUT → real wire → PA5 / ADC_IN5. Chip ID: 0x30700528. USART1 uses PA9 TX / PA10 RX; the reported host connection is COM4 at 115200 baud, 8N1.

Pre-run electrical gate: monotonic ADC response and no more than 128 counts of mismatch.
ProbeDAC codeADC readingMismatch
Low5125208
Mid2,0482,0480
High3,5843,57113

Electrical gate: PASS. Native run: 100,000 cycles in approximately 37 seconds; INC 36 / HOLD 99,934 / DEC 30. Maximum DAC/ADC mismatch: 33 counts. Zero ADC failures, state failures, invalid actions or timer overflows.

Final reference: 2,662 counts. Final ADC: 2,331 counts. Final error: 331 counts. The reported PASS concerns physical execution and state integrity; it does not mean zero tracking error.

The physical bench.

ORIGINAL REPORT PHOTOGRAPHS / CLICK TO ENLARGE

Board-level power observation.

WHOLE-BOARD INPUT / NOT ISOLATED CORE POWER

4.82 V · 10–11 mA · constant-voltage supply

48.2–53.0 mW

Calculated from the photographed supply readings with the PC USB power connection removed. The measurement includes the development board, not only the computational core.

The supply display resolves current in 1 mA steps. These observations do not establish energy per decision, current transients or the active 100,000-cycle run’s average power.

Additional power images and observation limits

The report includes 4.82 V / 10 mA and 4.82 V / 11 mA observations from a UNI-T UTP3315TFL-II supply. It records an operator-reported five-minute watch with 11 mA at the end. The supplied video excerpt is 9.52 seconds; its extracted frame is shown below. That excerpt does not independently document the full five minutes.

Still images and a short excerpt are observational evidence, not a continuous current trace. No isolated-core power or energy-per-decision claim is made.

Artifact integrity, provenance and next validation gates

These experiments are reported by OSH Global Systems. They are not independent third-party replication or industrial certification. The next gates are an independent observer using a frozen protocol, a partner-relevant physical plant and continuous power logging.

Native firmware HEX · SHA-256
2db7f4dba1893c67be1ebcdca9f0b0a6db43484eb9f1fb75e45301bf63bb1268

Complete public report · SHA-256
ab4e5e76a9d5e4ce8585d4f59af1fd7bddbeaac0f00fb4e0f5edbee2100eba69

The complete report preserves the protocol, raw-artifact references, limitations and all original figures. Earlier reports and their evidence remain available below.

05 / FROM EXECUTION TO MEASURED BEHAVIOR

How does FARO respond
when conditions change?

Physical execution establishes that the architecture runs on the hardware. The next tests examine one practical application: selecting actions in an electrical control task.

FARO and the comparison controllers run on a PC connected to a real circuit. The hardware produces and measures voltages; the tests measure how closely the output follows a target.

Why compare with PID?

PID is a conventional feedback controller. It provides an engineering reference for this control task.

What is being measured?

Accumulated tracking error, final accuracy and command variation. Lower error means closer tracking under the stated protocol.

What does this say about FARO?

These results evaluate a control application of its AI architecture. They complement the separate native microcontroller evidence.

05.1 / FARO R6 · FIXED-PID COMPARISON · 19 OCTOBER 2026

New profiles.
Degraded conditions.
Every completed pair counts.

The R6 battery tests generalization and degradation as separate families, with equal preparation and preserved controller states.

35 completed pairs · 70 runs
22,512 decisions · 225,120 ADC samples.
Zero exclusions and zero local retries.

GENERALIZATION

Practical parity.

Three profiles favored FARO; three favored the fixed PID. The aggregate difference was minimal.

0.0478% symmetric IAE advantageFARO 184,297.20 · PID 184,385.28
DEGRADATION

Lower error in all six.

FARO recorded lower accumulated tracking error in all six declared degradation profiles.

2.7861% symmetric IAE advantageFARO 23,167.56 · PID 23,822.16

Generalization and degradation are separate results. The symmetric percentages here use a different definition from the relative reductions in the later Oracle and RLS-CE reports.

Read the R6 protocol, tables and original report
05.1 / FULL RECORDR6 results and earlier physical control testsFixed-PID comparisons · generalization · degradation · recovery · earlier 20 October Oracle study

CONTROL COMPARISON / FARO V2 × FIXED PID

A familiar control benchmark.
A different decision architecture.

PID is a long-established reference for feedback control. This experiment asks a precise question: how does FARO V2 track the same targets, on the same physical electrical bench, against one predeclared PID configuration?

Expanded physical evidence / 19 October 2026

Five evidence blocks. Every protocol visible.

The original control results remain below. The updated report adds ARM matched tracking and recovery context, plus the canonical R6 generalization and degradation tests. Each result belongs to its own physical protocol.

Download five-test benchmark
THE INDUSTRIAL REFERENCE

What PID does.

A proportional–integral–derivative controller combines present error, accumulated error and the rate of error change. Its strengths are compact implementation, transparent regulation and decades of tuning experience. Saturation, nonlinearities and changing conditions can make tuning, overshoot, settling and residual error challenging.

THE ALTERNATIVE UNDER TEST

What FARO V2 does here.

FARO V2 selects actions from its evolving homeostatic state. In this protocol, its choose_action interface receives unsigned need; the signed target error is withheld. It uses no PID coefficients. The fixed PID receives signed error.

01 / ARM matched tracking.

STM32F446RE / PHYSICAL DAC-TO-ADC PLANT
7.46%

Lower mean IAE in the ARM study.

FARO V2 recorded less cumulative tracking error in all three paired runs. Both controllers ran on the host PC, using the physical STM32F446RE DAC/ADC loop.

The report records zero ADC failures. This result applies to the stated fixed PID and frozen ARM protocol.

ARM paired results · lower cumulative IAE is better
PairFARO IAEPID IAEReduction
01114,977123,4816.89%
02112,577123,5118.85%
03115,199123,3736.63%
Mean114,251123,4557.46%

Earlier matched-study settings: Kp 0.800 / Ki 0.008 / Kd 0.080; fresh controller state each phase; median of five ADC samples. These are different from the R6 prepared-state protocol below. Source: five-test report, pages 3–4.

02 / RISC-V matched tracking.

ORIGINAL J4 RESULT / RETAINED

MEAN CUMULATIVE ABSOLUTE TRACKING ERROR

10.37%

Lower IAE for FARO V2.

FARO recorded lower integrated absolute error in all three interleaved pairs. IAE accumulates the magnitude of tracking error across the run; lower is better.

This is an error metric—not a claim of 10.37% faster execution or lower energy consumption.

Matched J4 experiment · 360 decisions per run · lower IAE is better
PairFARO V2 IAEFixed PID IAEReduction
01107,651124,07213.24%
02114,395124,0817.81%
03111,611124,10910.07%
Mean111,219124,087.3310.37%

Execution boundary: both controllers ran on the host PC. The same CH32V307 supplied the physical DAC/ADC plant over UART. These six comparison runs are separate from the native RISC-V endurance run.

Matched conditions: targets, reset, action limits and fixed PID gains
  • Three target phases: 3,071 → 1,024 → 2,662 ADC counts, with 120 decisions per phase and 360 per run.
  • Physical reset to DAC 2,048 and fresh controller state at every phase boundary.
  • Both use MEDIAN5 ADC sampling and a ±12 DAC-count action limit per decision.
  • Three interleaved FARO → PID pairs; zero ADC failures and no new UART receive errors across all six runs.
  • One predeclared fixed PID setting: Kp = 0.800, Ki = 0.008, Kd = 0.080.

The experiment does not compare FARO with globally optimized PID, every PID variant or a tuned controller for every possible plant. It measures these two configurations under the stated protocol.

A separate disturbance-and-recovery test.

J3 / QUALIFICATION GATES MATTER

FARO V2 / FIRST VALID RECOVERY

22

Decisions to recovery.

FARO passed the disturbance-validity gate and reached the first of five consecutive in-threshold observations at decision 22.

J3 physical perturbation results
MeasureFARO V2Fixed PID
Pre-disturbance baseline error0.5346
Immediate absolute error241148
Disturbance confirmedYesNo
First valid recovery22 decisionsNot established
Post-disturbance IAE3,23925,994
Final absolute error2123

The PID disturbance-validity gate was not met: its immediate error fell from a larger existing offset. Its step-one threshold crossing is therefore not a valid recovery result. The two IAE figures do not establish a like-for-like recovery-time advantage.

03 / Recovery evidence across both physical plants.

The consolidated report also records the earlier ARM disturbance test. FARO passed disturbance confirmation on both boards.

FARO disturbance outcomes · ARM and RISC-V · five-test report, page 6
MeasureARM FARORISC-V FARO
Reference3,0713,071
Injected step−240 DAC counts−240 DAC counts
Pre / post decisions120 / 120120 / 120
Disturbance confirmationPASSPASS
Recovery step1922
Post-disturbance IAE3,2673,239
Final error4 counts2 counts

The RISC-V PID qualification caveat above remains unchanged. Its disturbance was not confirmed under the declared gate, so this evidence does not establish that PID failed recovery or identify a valid FARO-versus-PID recovery winner.

Disturbance protocol and how to interpret the result

Target: 3,071. The protocol takes 120 decisions before and 120 after a −240 DAC-count disturbance, with MEDIAN5 sampling and ±12 DAC counts per decision. A valid disturbance must raise absolute error by at least 150 counts above the pre-disturbance baseline. Recovery is the first of five consecutive observations within the protocol’s error threshold.

The observed outcome supports FARO’s recovery on this qualified electrical test. Because the PID disturbance gate fails, a direct claim that FARO “recovers faster than PID” is not established by J3.

What the benchmark supports. FARO V2 produced lower mean tracking error than the declared fixed PID in the three matched J4 pairs, and met the J3 recovery gate. These results concern one physical electrical bench. They do not establish universal superiority over PID, industrial readiness or equivalent behavior in robots, drones and other untested plants. The report discusses PID’s 70-plus-year engineering history; this comparison is a specific measured result within that broader field.

Source: OSH RISC-V Public Benchmark · 09 October 2026 · comparison, recovery and interpretation sections

NEW / R6 TODO-CUENTA · COMPLETED 19 OCTOBER 2026

Two new questions.
Every completed pair counts.

The canonical R6 battery tests reserved generalization profiles and declared degradation profiles. FARO Compacta V2 and the fixed PID both run on the host, using the physical CH32V307 DAC-to-ADC plant.

35 / 35Completed pairs
70Physical runs
22,512Decisions
225,120ADC samples
0 EXCLUSIONS0 LOCAL RETRIES11 PAIRS WITH TIMING WARNINGS — ALL COUNTED

04 / GENERALIZATION · SIX RESERVED PROFILES

Near parity.

0.0478%FARO SYMMETRIC IAE ADVANTAGE
FARO TOTAL IAE184,297.20
PID TOTAL IAE184,385.28

Three profiles for FARO. Three for PID. FARO’s aggregate IAE was 88.08 units lower. The difference is minimal; this result does not establish robust superiority.

See all six generalization profiles
R6 generalization · lower IAE is better
ProfileFARO IAEPID IAELower IAE
G1 UP23,058.6023,097.84FARO
G1 DOWN23,223.9622,987.68PID
G2 UP31,636.5631,413.96PID
G2 DOWN31,633.2031,813.56FARO
G3 UP37,125.1237,559.88FARO
G3 DOWN37,619.7637,512.36PID

All complete pairs counted once. The report describes the aggregate outcome as practically indistinguishable. Source: page 8.

05 / DEGRADATION · SIX DECLARED PROFILES

Lower error in all six.

2.7861%FARO SYMMETRIC IAE ADVANTAGE
FARO TOTAL IAE23,167.56
PID TOTAL IAE23,822.16

Six of six profiles favor FARO. Aggregate IAE was 654.60 units lower: a consistent advantage against this fixed PID within the declared physical degradation protocol.

See all six degradation profiles
R6 degradation · lower IAE is better
ProfileFARO IAEPID IAELower IAE
D1 HIGH4,878.845,131.68FARO
D1 LOW4,908.965,109.96FARO
D2 HIGH3,823.323,901.44FARO
D2 LOW3,786.603,847.80FARO
D3 HIGH2,858.162,879.16FARO
D3 LOW2,911.682,952.12FARO

The report gives a two-sided descriptive sign-test value of 0.03125. This describes the six-profile outcome; it does not establish universal controller superiority. Source: page 9.

Read the percentages correctly. R6 reports a symmetric advantage: 100 × (IAE_PID − IAE_FARO) / ((IAE_PID + IAE_FARO) / 2). The earlier 7.46% ARM and 10.37% RISC-V results use reduction relative to PID. Different protocols and percentage definitions are kept separate.
R6 protocol: equal preparation, preserved state and complete accounting
  • Physical platform: CH32V307VCT6 / QingKe V4F, host Python over COM4, PA4 DAC → PA5 ADC.
  • Equal preparation: 4,416 decisions per controller, with prepared dynamic states preserved symmetrically.
  • R6 fixed PID: Kp 3.0 / Ki 8.0 / Kd 0.036 / Tf 0.12 / Tt 0.48. This is a different comparator setting from the earlier ARM and RISC-V studies.
  • Measurement: five raw ADC samples before and five after each decision; raw IAE calculated at nominal 0.12 seconds per decision.
  • Accounting: one attempt per job; every complete pair counts once; zero exclusions and zero local retries. The 11 pairs carrying timing warnings remained visible and counted.
  • System integrity: no flash, firmware, kernel or overlay changes during the battery.
  • Reported audit: PASS_AUDITORIA_R6_TODO_CUENTA.

R6 replaces the filtered R5 verdict by removing timing-based exclusion of completed pairs. Timing anomalies are reported without erasing or replacing completed performance results.

The battery totals above describe the complete R6 record. The generalization and degradation results are reported as separate families; their raw totals are not pooled into a global score.

More physical evidence.
One conclusion per protocol.

FARO recorded lower IAE in the earlier ARM and RISC-V matched studies, remained numerically level in R6 generalization, and achieved a consistent six-profile advantage in R6 degradation.

These outcomes do not identify the best possible PID tuning, rank processor ISAs or replace independent replication and application-specific qualification. The attempted RC mutant-plant test is excluded from this report because no valid FARO-versus-PID performance pair was completed.

11-page consolidated report · 19 October 2026 · five evidence blocks with protocol definitions and SHA-256 evidence anchors.

Document identity and traceability

The downloadable PDF is the exact supplied document, embedded in this HTML. Its last page links the consolidated evidence to the 35-page dossier, frozen R6 protocol, runner, progress, audit, summary and both prepared states.

Five-test report / SHA-256
d3b1ab857f79032fae36e52d1bc0d575b82b3e88240c683160f49d41c225193c

Hashes identify bytes and provenance; they do not replace raw traces or third-party reproduction.

20 OCTOBER 2026 / EARLIER PID ORACLE STUDYR6 generalization and degradation
THE PHYSICAL EVIDENCE / PID ORACLE · 20 OCT 2026

Less accumulated error.
Less output variation.

The 20 October comparison gave the PID search physical calibration, advance knowledge of the scored profiles and the scoring objective. Under sensor bias, quantization and actuator constraints, FARO achieved the following degradation results.

5/6

Degradation profiles with lower IAE for FARO.

5.080%

Symmetric aggregate IAE advantage.

60.49%

Lower mean terminal RMSE versus PID Oracle.

58.82%

Lower total DAC variation versus PID Oracle.

R6 ORACLE / DEGRADATION FAMILY · PHYSICAL CH32V307 DAC–ADC LOOP · BOTH CONTROLLERS EXECUTED ON THE HOST

Generalization remained at practical parity: three profiles each, with a 0.155% symmetric aggregate IAE difference favoring PID Oracle. FARO recorded lower terminal RMSE and DAC variation in that family as well.

This Oracle study is separate from the earlier fixed-PID R6 comparison. Both records remain available, with their own protocols and results.

Download the PID Oracle physical benchmark ↓9 pages · Original report · 20 October 2026
Protocol, exact values and scope of the measurements

FARO Compacta V2 + OAPA Active V11 and PID Oracle ran on the host PC, driving the same CH32V307VCT6 / RISC-V physical PA4 DAC → PA5 ADC loop. The completed battery contains 35 pairs, 70 controller runs, 22,512 decisions and 225,120 raw ADC samples. All eight timing-warning pairs were counted; there were zero exclusions and zero retries.

The PID comparator came from a finite search with 2,001 unique nominal candidates and robust screening. The search knew the future profiles and primary metric; FARO did not receive the Oracle calibration. One PID gain set was frozen before scoring. OAPA was updated between preparation jobs and frozen before scored execution.

Degradation: aggregate IAE 20,714.04 for FARO versus 21,793.68 for PID Oracle; mean tail RMSE 2.430 versus 6.150; total DAC variation 6,326 versus 15,363. PID Oracle won D3_LOW; FARO won the other five profiles.

Generalization: aggregate IAE 183,590.04 for FARO versus 183,305.64 for PID Oracle, with a 3–3 profile split. The report describes this as practical parity. FARO’s mean terminal RMSE was 15.54% lower and total DAC variation was 3.18% lower.

The IAE percentage is symmetric: 200 × (IAE_PID − IAE_FARO) / (IAE_PID + IAE_FARO). RMSE and DAC-variation reductions are relative to PID Oracle. The conclusions apply to these tested families and the selected comparator. OSH’s structural audit is separate from independent replication.

Native microcontroller execution is documented separately in the physical migration evidence. The earlier R6 fixed-PID comparison remains unchanged.

Original PDF / SHA-2568a04766d46bae1f35ac37872b4aed729289eb5514891b1ae24b4ca27e2870050

Latest physical benchmarks / 30 October 2026

Physical control.
Changing dynamics.

FARO recorded lower aggregate tracking error in two new physical comparisons: a privileged PID Oracle across three regimes, and an online adaptive RLS-CE controller after a change in the RC plant’s regime.

TWO DISTINCT PROTOCOLSPHYSICAL PLANT & ADC/DACHOST-EXECUTED CONTROLLERSPRIMARY METRIC / NOMINAL IAE

Two further questions, two separate benchmarks. The PID Oracle baseline receives advance plant and test information. The adaptive RLS-CE baseline estimates the plant online. Both comparisons test a physical resistor–capacitor circuit.

Read each result with its own preparation, information boundary and command-variation trade-off. The full tables and original PDFs remain with each benchmark.

01 / Information-advantaged classical baseline

FARO vs PID Oracle

The Oracle received plant characterization, the exact future profiles and the scoring objective. Its gains were selected for each regime. FARO received none of that characterization and completed 192 commissioning decisions per regime.

4.42%Lower aggregate IAE
relative to PID Oracle.
6/6Scored profiles
with lower IAE for FARO.
FARO 201,458.04PID ORACLE 210,780.12

IAE reduction by physical regime

MEDIUM1.34%FARO 2/2 profiles
FAST1.76%FARO 2/2 profiles
SLOW8.02%FARO 2/2 profiles
42.6% lowerMean tail RMSE
FARO 42.314 · Oracle 73.736
17.8% moreTotal DAC variation
FARO 37,164 · Oracle 31,547
Download PID Oracle report

ORIGINAL PDF / 6 PAGES / 30 OCT 2026

All six profile results
Raw nominal IAE · lower is better
ProfileFAROPID OracleFARO edge
MEDIUM UP29,141.1629,380.680.82%
MEDIUM DOWN28,775.5229,325.121.87%
FAST UP28,661.7629,261.762.05%
FAST DOWN28,820.7629,253.361.48%
SLOW UP44,056.8047,549.527.35%
SLOW DOWN42,002.0446,009.688.71%

FARO accumulated 9,322.08 fewer count-seconds of nominal error. Relative reduction: 4.42%; symmetric advantage: 4.52%. The primary result covers these six scored profiles.

Preparation, physical regimes and timing
  • Physical regimes: MEDIUM τ = 1.1225 s; FAST τ = 1.0510 s; SLOW τ = 3.7590 s. Oracle gains were selected per regime and frozen before commissioning and scoring; FARO’s model was locked before scoring. Both used ±12 DAC counts per decision.
  • Two completed blocks: MEDIUM and FAST were scored first. SLOW was completed later, after a pre-score conditioning amendment. No failed SLOW attempt produced a scored profile; the successful block supplied the first SLOW UP and SLOW DOWN scores.
  • SLOW conditioning: the inherited 2048 ±16 rule was replaced by deterministic 512 → 2048 stabilization under the original Q acceptance envelope, applied identically to both controllers before any scored SLOW profile. Last-10 span ≤8; at least 30 observations; at most 30 s per phase. The report retains the actual starting ADC values.
  • Timing: all six pairs were comparable, with zero scored cycles above 150 ms. The loop was host-driven and exact hardware ADC timestamps were unavailable; these timings describe the comparison, not native MCU controller latency.

The host-time-weighted error proxy was 4.10% lower for FARO. SLOW dominates the mean tail-error magnitude, so the 42.6% tail-RMSE reduction is read alongside the regime results. The measured outcome is lower tracking error with higher DAC variation.

Original PDF / SHA-256d41b23fc19777839f314cc38945d372547bea89d18595dccd21f699d7c9aaf38

02 / Information-symmetric adaptive baseline

FARO vs RLS-CE

Both controllers adapted online after the physical RC plant changed regime. Both used the same observations and action limit, with no plant model, future FAST/SLOW characterization or post-mutation tuning supplied.

2.74%Lower aggregate IAE
relative to RLS-CE.
3/4Scored profiles
with lower IAE for FARO.
FARO 150,859.68RLS-CE 155,106.36

IAE reduction after regime mutation

FAST0.09%Practical parity · 1/1 split
SLOW4.29%FARO 2/2 profiles
17.65% lowerMean tail RMSE
FARO 84.710 · RLS-CE 102.868
1.66% moreTotal DAC variation
FARO 25,200 · RLS-CE 24,789
Download RLS-CE report

ORIGINAL PDF / 10 PAGES / 30 OCT 2026

All four profile results
Raw nominal IAE · lower is better
ProfileFARORLS-CEFARO edge
FAST UP28,773.2428,721.40−0.18%
FAST DOWN28,452.4828,557.240.37%
SLOW UP48,051.3649,547.883.02%
SLOW DOWN45,582.6048,279.845.59%

RLS-CE won FAST UP; FARO won the other three profiles. FARO accumulated 4,246.68 fewer count-seconds of nominal error. Relative reduction: 2.74%; symmetric advantage: 2.78%. FAST was effectively parity; SLOW accounted for most of the separation.

Online adaptation, preparation and timing
  • The comparator: RLS-CE combines Recursive Least Squares estimation of a first-order ARX model with certainty-equivalent one-step control. RLS is the estimator; RLS-CE is the controller being compared.
  • Equal preparation: 384 MEDIUM decisions each. Each scored profile restored its prepared MEDIUM snapshot; both arms then adapted online. Both used ±12 DAC counts per decision. No physical-score hyperparameter search or post-mutation tuning was used.
  • Completed physical record: four scored profiles, eight runs, 540 decisions per run, 4,320 scored controller decisions. No scored run was excluded and no performance retry was used; controller order alternated across profiles.
  • Electrical gates: MEDIUM, FAST and SLOW passed the existing Q gate. Before SLOW scoring, both controllers received the same deterministic 512 → 2048 conditioning under the Q acceptance policy.
  • Timing: all four pairs passed comparability. FARO had zero cycles above 150 ms; RLS-CE had one, in SLOW DOWN. The controllers ran on the host with a physical RC plant and ADC/DAC path; exact hardware ADC timestamps were unavailable.

RLS-CE used a forgetting factor of 0.995, initial covariance 1000 I and at least 16 transitions before model-based control. Pre-experiment software checks numerically favored RLS-CE in both simulated batteries. Physical trace replay checked decision consistency; it did not independently revalidate the hardware.

FARO’s host-time-weighted post-error proxy was 2.45% lower. The four-profile result describes this plant and protocol, with raw traces and state files as the reproducibility record.

Original PDF / SHA-256bbdd46073296e17209416b3406fdbf2ee597716ea519453e86f933e4522254d5

Complementary RC analysis / 29 October 2026

Tracking error and
the command-slew limit.

This earlier RC study compares FARO with the fixed R6 PID. It preserves the original raw error and adds a post-hoc decomposition of the common contribution from the 12-count-per-decision command limit.

PRIMARY / RAW NOMINAL IAE1.31% lower

FARO 114,819.00 · fixed PID 116,345.88

FARO recorded lower raw IAE in each of the four completed profiles.
SECONDARY / POST-HOC ABOVE-FLOOR IAE8.21% lower

FARO 17,077.56 · fixed PID 18,604.44

After subtracting the same analytical slew-only reference. The absolute error gap remains 1,526.88 count-seconds.

68.87% lower mean tail RMSE · 14.71% higher total DAC variation.
The accuracy and command-variation results are reported together.

Download the RC analysis

ORIGINAL PDF / 12 PAGES / 29 OCT 2026

FAST and SLOW were separate physical blocks, with a contact intervention between them. Their combined result is a descriptive consolidation. The 8.21% secondary result does not replace the 1.31% raw result.

Raw and above-floor results by profile
Primary: raw nominal IAE
ProfileFAROFixed PIDReduction
FAST UP28,551.1228,819.440.93%
FAST DOWN28,355.2828,746.361.36%
SLOW UP29,094.3629,408.881.07%
SLOW DOWN28,818.2429,371.201.88%
Secondary: IAE above the slew-only reference
ProfileFAROFixed PIDReduction
FAST UP4,115.764,384.086.12%
FAST DOWN3,919.924,311.009.07%
SLOW UP4,659.004,973.526.32%
SLOW DOWN4,382.884,935.8411.20%

The shared slew-only reference is 24,435.36 count-seconds per profile, or 97,741.44 across four profiles. It equals 84.01% of the PID raw total. Subtracting the same value from both arms changes the percentage denominator while preserving the absolute FARO–PID gap.

Analytical assumptions and physical protocol

Analytical reference: the report uses a causal controller without preview and an ideal instantaneous unity-gain plant. For a reference jump D, action limit L = 12 counts and nominal interval Δt = 0.12 s, its slew-only contribution is:

B(D) = Δt × Σ max(D − kL, 0), for k = 1 … ceil(D/L).

The three jump magnitudes are 768, 1,536 and 1,408 counts. Their contributions are 2,903.04, 11,704.32 and 9,828.00 count-seconds. The above-floor remainder still includes plant dynamics; it is not described as entirely controllable error. This decomposition was derived after the physical results were known. The raw nominal scoring and completed traces were unchanged.

Physical protocol: FARO Compacta V2 + OAPA V11, with adaptation enabled, and a fixed R6 PID ran on the host through a CH32V307VCT6 physical RC plant and DAC/ADC path. Both received 384 MEDIUM preparation decisions. Each scored profile used 540 decisions at a nominal 120 ms interval with a 12-count action limit. Mutation was manual between powered-off blocks.

Completed-record status: the final profile runs reported zero cycles above 150 ms and comparable pair timing. The combined record explicitly sets physical_comparative_claim_allowed=false because of the contact intervention between FAST and SLOW; it is retained as a descriptive consolidation rather than an uninterrupted mutation experiment.

Secondary metrics: mean tail RMSE 1.581 for FARO versus 5.079 for PID; total DAC variation 23,826 versus 20,770. Command variation is not converted into motor energy, wear or battery-life claims.

The report’s proposed next comparisons are dated to 29 October. The subsequently completed PID Oracle and RLS-CE studies are presented separately above.

Original PDF / SHA-256381a31965135b6a4eeaa209091991c15af12685ab8a3457d1cb93a95ad81b7ab

PROPOSED EVALUATION PATHWAY

Independent Validation Program

OSH proposes an independent observational assessment of defined FARO claims on physical hardware. An agreed independent evaluator would set examination criteria, choose appropriate unseen challenges, supervise controlled trials and issue a signed assessment of observed outcomes and limitations.

OSH retains custody of the proprietary implementation. The pathway provides for assessment without transferring source code, firmware, executables or proprietary test assets.

Current status: first-party engineering evidence is available. No completed independent assessment or certification is claimed. Independent observation is distinct from full independent reproduction of the implementation.

Download Public Validation Brief (PDF)
06 / COMMERCIAL STRATEGYOSH GLOBAL SYSTEMS, INC.

PROPRIETARY INTELLIGENCE / PRODUCT OPPORTUNITY

Build the next generation
of hardware around FARO.

The commercial asset is the architecture.

FARO is the proprietary computational intelligence architecture developed by OSH Global Systems, Inc., designed to give physical systems their own local state, decision and action path. A commercial agreement can bring that capability into a defined product, a family of devices or an OEM platform.

Explore the commercial routes
FARO / PROTECTED COREOwn the product.
Build with the architecture.
LOCAL STATE · DECISION · PHYSICAL ACTION

Put intelligence inside the product.

The opportunity is to make FARO part of how a machine operates: receiving signals, maintaining internal state and selecting actions locally. The value of that integration is established in the product’s own operating conditions.

ESP32-S3 / PHYSICAL EXECUTION ARM CORTEX-M4 / PHYSICAL EXECUTION
Read the cross-architecture evidence
THE SCOPE OF THE AGREEMENT

A product is a starting point.
A platform is a broader relationship.

The commercial scope defines where FARO can be deployed, which integration work is required and how the relationship can expand.

01

A defined product

Agree on the application, target hardware and acceptance criteria. Establish the right to integrate and deploy FARO within that product.

PRODUCT LICENSE
02

A family of devices

Extend the relationship across agreed models, generations or product lines. Carry validated integration work forward and qualify each additional target.

PORTFOLIO EXPANSION
03

An OEM platform

Define a joint hardware roadmap, integration resources and deployment rights around a platform intended to support multiple products.

PLATFORM AGREEMENT
WAYS TO WORK WITH OSH GLOBAL SYSTEMS

Define the relationship.
Then define its reach.

Licensing, platform development and company expansion create different discussions, with terms matched to the intended scope.

01 / LICENSING

Integrate FARO
into your products.

For manufacturers seeking to incorporate the architecture into an agreed application or product family.

Agreement focus
Deployment rights, hardware targets, integration support and commercial terms.
Commercial structure
Negotiated architecture or platform licensing, with production terms where applicable.
Discuss architecture licensing
02 / PLATFORM PARTNERSHIP

Develop a hardware
platform around FARO.

For OEMs, semiconductor companies and industrial partners exploring a broader integration relationship.

Agreement focus
Target qualification, a shared development roadmap and reference integrations.
Commercial structure
Co-development and platform rights, with scope for further product lines.
Discuss an OEM partnership
03 / STRATEGIC INVESTMENT

Participate in
the company’s expansion.

For investors and strategic partners interested in developing the business around OSH’s proprietary architecture.

Discussion focus
Physical validation, product integration capabilities, team growth and market development.
Investment basis
The protected architecture, the documented evidence and an agreed expansion plan.
Discuss strategic investment
VALUE & RIGHTS

A real agreement defines the licensed scope, permitted uses, hardware coverage, support, territory, duration and expansion rights. Integration and production terms follow that scope. The proprietary FARO implementation remains protected.

Application opportunities & buyer valueIndustrial equipment · robotics · remote IoT · OEM platforms
WHERE THE BUYER SEES VALUE

One architecture. Different commercial openings.

Select a deployment to see the buyer, the concrete job and the proposed commercial relationship.

FARO / APPLICATION FIELDSELECT A MARKET ↘
01 / INDUSTRIAL EQUIPMENT

A machine facing changing conditions.

An equipment maker could evaluate FARO as a resident supervisory path that tracks internal condition and selects an action as sensor conditions evolve. A pilot would compare its decisions against the existing process and measure the effect on operations.

Who pays
Equipment OEM or plant operator
Why pay
A differentiated, locally acting product and a measurable operational outcome.
Revenue path
Paid pilot → board integration → per-unit license or supervised-node agreement.
Discuss this application
THE BUYER’S RETURN

Make the gain visible in the customer’s own numbers.

A deal begins with one device and one measurable outcome. These are the value equations a pilot can fill with the buyer’s data.

01 / MORE VALUE PER DEVICE

Added margin per device × units shipped − total FARO licensing royalties.

MEASURE / PRODUCT PRICING AND ADOPTION
02 / FEWER EXPENSIVE INTERRUPTIONS

Verified interruptions avoided × the buyer’s cost per interruption.

MEASURE / RELIABILITY IN THE REAL PROCESS
03 / LESS REMOTE DECISION COST

Eligible decisions handled locally × the current cost of that remote path.

MEASURE / FUNCTIONALLY COMPARABLE DECISIONS
Technical fit & deployment pathArchitecture evidence · complementary technologies · integration stages
FARO / THE PROTECTED ASSETA native architecture that can become a product capability.

Its causal route has run on physical ESP32-S3. Its frozen core has generated objects for 21 of 22 target profiles, and the original harness passed on virtual RV32IMF. That progression makes new board integrations worth pursuing; each new target gets its own physical qualification. The physical ARM validation extends that evidence to STM32F446RE / Cortex-M4. The 09 October RISC-V benchmark adds CH32V307 native physical qualification and a separate host-controlled FARO V2 / PID comparison.

Trace the evidence path
WHY NOT USE WHAT WE ALREADY HAVE?

Because these tools answer different questions.

TinyMLCan recognize learned patterns from data. A product may still need persistent regulation and a decision path after detection.
C++ / MicroPythonAre ways to write and run software. FARO supplies a specific resident architecture for state, trajectory, attention and selection.
Conventional controlPID and fixed control loops are valuable foundations. FARO can be evaluated as a supervisory layer where changing context requires an additional decision process.
Cloud AICan supply remote inference or language. The tested FARO route executes locally without a cloud inference call for each decision cycle.
HOW OSH GLOBAL SYSTEMS EARNS

From engineering proof to recurring IP income.

  1. 01 / PilotPaid feasibility work on the buyer's board and use case.
  2. 02 / IntegrationHardware adaptation, instrumentation, acceptance tests and reference implementation.
  3. 03 / ProductionPer-device royalties or a negotiated platform license when the product ships.
  4. 04 / ExpansionFurther product lines, board families, support and partner programs.
STRATEGIC DIRECTION / CHINA · SHENZHEN

Develop the architecture.
Bring it into products.

OSH Global Systems is seeking strategic investment and hardware partnerships to develop FARO in China, with Shenzhen as the intended base for engineering and integration.

The commercial path is paid integration, production licensing and per-device royalties, with scope to expand across product families.

Discuss strategic investment
START A STRATEGIC CONVERSATION

Bring a product vision.
A platform roadmap.
Or a plan to expand OSH.

Tell OSH Global Systems what you want to build, license or help develop. The next step is to define the technical scope and the commercial relationship.

Discuss an OSH agreement
06 / APPLICATIONSWhere partners could build with FAROProposed product areas and the path to a defined integration
09 / APPLICATIONS

Close to the physical world.

The experiment opens possibilities for local integration. Each application needs its own pilot, target hardware, and acceptance criteria.

01 / ROBOTICS

Stateful machines

Explore local decisions alongside sensors and actuators, with continuity across cycles.

02 / INDUSTRY

Private edge

Test resident paths in equipment where latency, autonomy, and local access matter.

03 / MOBILITY

Autonomous systems

Investigate regulation and selection close to physical signals and timing constraints.

04 / EMBEDDED

MCUs and devices

Measure the substrate and full integration on a specific target before making product claims.

STATUS: PROPOSED APPLICATION AREAS · NOT VALIDATED END PRODUCTS

From evidence to integration

Start with a defined
control task.

FARO’s public evidence covers execution on microcontrollers and physical electrical-control comparisons. OSH Global Systems offers this proprietary architecture as a basis for discussing licensing and integration with hardware manufacturers.

A concrete integration begins with the device, its sensor inputs, its actuator interface and the behavior it needs to achieve. Product-level performance belongs to that complete system.

07 / ORIGINAL REPORTS

The complete evidence library.

The evidence library now includes Benchmark 3, the physical ESP32-S3 paper, the Universal Substrate Benchmark, and the October 2026 public cross-architecture whitepaper covering the new physical ARM milestone. The full collection also includes physical RISC-V validation, fixed-PID and PID Oracle comparisons, adaptive RLS-CE, and the RC slew-floor analysis. Each report keeps its own test date, protocol and measurement scope.

01 / PAPER / 21 SEP 2026

Physical Validation of an Autonomous Homeostatic Cognitive Architecture

17 pages · physical silicon, parity, endurance, oscilloscope, and analog loop.

PDF · 893 KBDownload paper ↗View PDF ↗
02 / BENCHMARK / 12 SEP 2026

Architectural Runtime Benchmark 3

17 pages · CPU-only protocol, latency, Working Set, repetition, and interpretation.

PDF · 360 KBDownload Benchmark 3 ↗View PDF ↗
03 / UNIVERSAL SUBSTRATE / 23 SEP 2026

Universal Substrate Benchmark

20 pages · 21/22 compiled target profiles, RV32IMF virtual golden parity, physical ESP32-S3 evidence and Appendix F.

PDF · 58 KBDownload benchmark ↗View report ↗
04 / WHITEPAPER / OCT 2026

Physical Cross-Architecture Evidence

Public technical whitepaper · PC → substrate → ESP32-S3 → STM32F446RE / ARM Cortex-M4, with parity, 100K physical loop, oscilloscope, power boundary and artifact integrity.

PDF · 995 KBDownload whitepaper ↗View PDF ↗
05 / RISC-V + PID / 09 OCT 2026

Physical RISC-V Validation & FARO V2 / PID Benchmark

14 pages · CH32V307 native parity and 100K physical cycles, matched host-controller comparison, disturbance recovery, original scope capture, board power observations and artifact integrity.

PDF · 1.9 MBDownload complete benchmark ↗Explore the PID results ↗View PDF ↗
06 / FARO × PID / 19 OCT 2026

Five Physical Tests — Unified FARO vs Fixed PID Benchmark

11 pages · ARM and RISC-V matched tracking, physical disturbance response, R6 generalization and degradation. Complete-pair accounting, equal preparation, protocol boundaries and evidence anchors.

PDF · 91 KBDownload five-test benchmark ↗Explore the new R6 results ↗View PDF ↗
09 / RC METRIC ANALYSIS / 29 OCT 2026

Physical RC Benchmark — Slew-Floor Analysis

12 pages · Original raw result: 1.31% lower nominal IAE. Secondary post-hoc analysis: 8.21% lower IAE above a shared slew-only reference. Four completed profiles, tail accuracy, command variation and physical-block provenance.

PDF · 382 KBDownload the RC analysis ↗Explore raw and secondary results ↗View PDF ↗
10 / R6 PID ORACLE / 20 OCT 2026

R6 PID Oracle — Generalization & Degradation

9 pages · Earlier fixed-preparation comparison. Degradation: 5/6 profiles favor FARO, with a 5.08% symmetric IAE advantage and 58.82% lower DAC variation. Generalization: near parity. Preserved as a separate historical study.

PDF · 57 KBDownload the R6 Oracle report ↗View PDF ↗
11 / RECOVERED ELF MEMORY / 05 NOV 2026

Recovered ELF Memory Evidence

4 pages · ARM 100K and RISC-V V2 100K image/static RAM accounting; ESP32-S3 Step20 candidate ELF and runtime free-memory observations. Full file digests, identity boundaries and the PSRAM percentage correction.

PDF · 89 KBDownload memory evidence ↗Explore the memory records ↗View PDF ↗
REPORT UPDATESDated additions to the evidence recordOriginal update links, retained for reference

08 / FOUNDER & PRINCIPAL ARCHITECT

A lifetime of knowledge.
Converging in FARO.

José Fabián Vallejos, Founder and Principal Architect of OSH Global Systems, Inc., in a black suit
José Fabián VallejosFounder & Principal Architect
OSH Global Systems, Inc.

PROGRAMMER · INVENTOR · RESEARCHER

José Fabián Vallejos

José Fabián Vallejos is the founder and principal architect of OSH Global Systems, Inc., and the creator of FARO. His background combines 25 years in railway engineering, experience in radiology, and studies and research in physics and computation.

FARO brings together the knowledge, studies and experience he has accumulated throughout his life. This architecture is one of his most significant inventions, within a broader career that includes other original inventions and developments.

His work focuses on bringing intelligence into hardware: processing information, maintaining internal state and selecting actions locally. That direction connects his research to the physical execution and comparative evidence presented on this page.

RESEARCH & AUTHORSHIP

Approximately 50 research papers and two books form part of his broader body of work in physics and computation.

Research profile · ORCID ↗0009-0001-4975-1740
01 / BOOK

Coherence

Universal Unification Theory
Teoría de unificación universal

02 / BOOK

Entanglement

José Fabián Vallejos

Intellectual property. A patent application covering the core architecture has been filed with INPI Argentina.

Contact the founder
10 / CONTACT

Let’s discuss an OSH agreement.

Discuss architecture licensing, an OEM partnership or strategic investment in OSH Global Systems. Tell us your objective and the scope you have in mind.

OSH GLOBAL SYSTEMS, INC.

From a proven route to a product opportunity.

  1. 01Use case and target hardware.
  2. 02Latency, memory, power, and stability.
  3. 03Causal parity and integration limits.
  4. 04Technical and commercial decision.

Tell us which device, product line or market you want to open with OSH. We can define a target board, success criteria and the commercial path from pilot to integration.

fabian.vallejos@oshsystems.com ↗

Get in touch

This opens your email application with a draft message. Review it before sending.

↑