For: Fractal Labs Team (Matt, Ollie, Joshua, et al.) Prepared by: Ruk | 2025-12-01
BC Automation is a 40+ year industrial automation company that has evolved from legacy control system integration into AI-powered manufacturing intelligence with post-quantum cryptographic security. Thomas Schwieters (CTO/Founder) is a polymath automation engineer who has been building machine learning algorithms for factory optimization since before it was called "machine learning."
Unlike the website's Industry 5.0 marketing speak, here's what they actually do:
They turn factory floors into intelligent, self-healing systems by:
-
Edge Data Precision Architecture
- Deploy "edge devices" (smart sensors/computers) at every measurement point in a factory
- Capture data at highest possible resolution before it degrades through traditional control systems
- Run all data through vector coordinate/graph model databases (not SQL—this is robotics data)
- Each edge device becomes a blockchain validator node in a private factory network
-
Real-Time Machine Learning at the Edge
- Deploy AI/ML algorithms directly on edge devices
- Detect micro-patterns invisible to traditional systems (sub-second events, correlations across plant)
- Example: Found that jam kitchen pressure valve releases were causing packaging robot failures on opposite end of factory—connection invisible in traditional historian data due to sample rate reduction and temporal misalignment
-
Private Blockchain for Immutable Audit Trails
- Every machine in factory becomes a node in private blockchain
- Stores permanent, tamper-proof record of all manufacturing data
- Solves compliance/traceability for aerospace, pharma, food (FDA requirements)
- No gas fees, no public chain—fully on-premises, zero-trust architecture
-
Post-Quantum Cryptography (via Secured2 partnership)
- Deployed lattice-based encryption across entire data pipeline
- Extended to space (Phantom Space partnership for satellite AI)
- Protects against "harvest now, decrypt later" quantum computer threats
Thomas has been doing graph model databases and vector math for 30 years—this is how robotics/automation actually works (X,Y,Z coordinates, real-time control). Traditional "big data" approaches (SQL, cloud historians) were built for business intelligence spreadsheets, not sub-millisecond control loops with temporal precision requirements.
Technical Philosophy:
- "Digital is lossy"—every time data moves through a conversion/processing layer, you lose resolution
- Fractional historialization—keep highest resolution data at the edge, downsample only when necessary
- Meta-loops—his ML algorithms correlate dozens of variables simultaneously to find hidden causation (like cruise control evolution: throttle → speed → lidar → lane detection)
- Cargill: Centrifuge control that increased oil purity beyond existing measurement scales, unlocked palm kernel oil markets, gave them so much capacity they stopped building new plants
- ConAgra Foods / Nestle: Caught Rockwell Automation red-handed stealing his IP (found his company name in hex code they deployed at ConAgra but stole from Nestle plant)
- Kellogg's: Found cross-factory air pressure correlation causing daily line shutdowns—fixed with $500 air accumulator instead of $500k air compressor
- Gallo Wines: Similar IP theft detection stories
Austin attempted to explain Thomas's concept using this example:
Thermometer precision loss: When a temperature sensor outputs a reading, that's the most precise the measurement will ever be. To get it from the sensor to a processing unit, it passes through:
- An I/O board
- Various conversion layers
- Different system types
At each step, math is being done to package the data for the next system. Even if the final number has the same number of digits, you're "losing leading values" or precision literally every time data moves.
Additionally, one conversion point might reduce sample rate (from 100 samples/sec to 3 samples/sec), meaning you miss sub-second events entirely—like the air pressure drop that was causing the Kellogg's line failures.
Austin's explanation was directionally correct but technically imprecise. Here's the corrected version:
The Core Truth: Every time you convert, transmit, or transform digital data, you risk three types of precision loss:
When an analog sensor signal is digitized:
- An 8-bit A/D converter gives you 256 discrete values (0-255)
- A 12-bit converter gives you 4,096 values
- A 16-bit converter gives you 65,536 values
The analog world is continuous (infinite resolution), but digital is discrete (stair-stepped). The first digitization is where you lose the most precision—you can never get it back.
Thomas's Fix: Digitize at the highest commercially reasonable resolution as close to the sensor as possible. Keep that high-res buffer at the edge. Only downsample when absolutely necessary.
When data moves between systems with different numeric formats:
- Sensor outputs 32-bit floating point → I/O board stores 16-bit integer → Historian stores 8-bit scaled value
- Each conversion truncates lower-order bits or rounds to fit the new format
Example: Temperature reading of 72.847°F becomes:
72.85°F(16-bit) →72.8°F(8-bit scaled) →73°F(executive dashboard)
Those fractional degrees matter when you're trying to detect a 0.1°F temperature swing that predicts equipment failure.
Different systems sample at different rates:
- Edge sensor: 1000 samples/second (1ms resolution)
- PLC: 100 samples/second (10ms resolution)
- SCADA historian: 1 sample/second (1000ms resolution)
- Cloud dashboard: 1 sample/minute (60,000ms resolution)
The Kellogg's Example: Air pressure dropped for 200ms when the jam kitchen released the pressure valve. This was:
- Visible at 1000 samples/sec (edge sensor caught 200 data points)
- Invisible at 1 sample/sec (historian saw nothing—pressure was back to normal before next sample)
Traditional systems missed the event entirely. Thomas's edge ML caught it because he kept the high-frequency buffer local.
Analog signal transmission through a wire preserves continuous values, but:
- Degrades due to noise, attenuation, interference
- Can be amplified/filtered to recover signal (within limits)
Digital signal transmission:
- Immune to noise (bits are bits—either 1 or 0)
- Cannot recover lost precision once quantization happens
- Every re-quantization (data type change, sample rate reduction) permanently discards information
Thomas's Insight: Traditional control systems were designed when memory was expensive and CPU was slow, so they aggressively downsampled/compressed data as early as possible. Modern edge devices have cheap memory and fast processors—there's no reason to throw away precision anymore.
Thomas's point is this:
"You can't reverse entropy in data transformations."
Every time you digitize, convert, or downsample, you're making an irreversible decision about what information to keep and what to discard. Traditional factory systems were designed to discard precision aggressively (to save 1980s-era memory). Modern systems should preserve maximum precision at the edge and only downsample when humans need simplified views.
This is why his edge AI finds patterns that cloud-based big data analytics miss—the signal was destroyed before it ever reached the cloud.
Thomas wants to replace legacy HMI (Human-Machine Interface) software with a modern, composable, intelligent visualization platform.
Factory operators interact with machines through HMIs/SCADA systems:
- Built with WYSIWYG editors from the 1980s (think Visual Basic for DOS)
- Pre-rendered at fixed pixel resolutions (must choose 1024x768 vs 1920x1080 before development)
- Sold by screen count ("5-screen license" vs "100-screen license")
- Vendor lock-in (Allen-Bradley has 17 incompatible versions of "Panel View"—same branding, can't transfer designs between versions)
- No vector graphics—everything is raster, doesn't scale
Instead of pre-built static screens, dynamically generate context-aware interfaces:
Key Features:
-
Voice/Chat Interface First
- Operator: "What's the pump speed on pump 3?"
- System: displays real-time value + trend graph
- Operator: "Show me operations on Mixer 3"
- System: generates live schematic with all connected sensors/actuators
-
Graph Database-Powered Navigation
- Since all factory data is already in a graph model (nodes = equipment, edges = connections), the UI can traverse the graph dynamically
- No pre-built screens—just infinite pan/zoom like Google Maps but for factory processes
- Click on any element → see upstream/downstream connections + live data
-
Context-Aware Permissions (Zero-Trust UI)
- Same dashboard viewed by different users shows different data based on credentials
- Line operator sees basic controls
- Supervisor sees quality metrics + production targets
- Executive sees OEE + cost per unit
- All looking at the same physical screen, but data layer respects identity
-
Multi-Platform (Phone First)
- Worker's iPhone becomes their HMI via badge-in (automatic authentication)
- System anticipates their role (badge reader triggers pre-loading their likely screens)
- Can also deploy to fixed screens, tablets, AR glasses (future)
-
2D Barcode Data Encoding (Thomas mentioned this cryptically)
- They can pass live data through dynamically generated QR codes
- Allows secure data transfer in air-gapped environments
- Example: Generate QR code on one machine's screen, scan with phone, automatically authenticates + transfers operational state
Phase 1: Proof of Concept / MVP
- "Small bite at the apple" (Thomas's phrase)
- Pick 3 common industrial elements: motor, valve, level sensor
- Build a mobile-first visualization app that:
- Connects to BC Automation's existing data backend (graph DB + blockchain)
- Displays live data from those 3 elements
- Demonstrates dynamic screen generation (not pre-built WYSIWYG screens)
- Shows role-based data visibility (different users see different data layers)
Platform Questions:
- Thomas deferred to Austin/team: "You tell us where to start—that's your domain"
- Austin suggested: React Native (deploy to iOS first, Android later) OR Progressive Web App (browser-based)
- Trade-off:
- Native app = better for phone-first worker experience
- Web app = easier for fixed HMI screen replacement (factory workers are used to big screens bolted in place)
Thomas used the phrase "I'd rather find somebody that knows how to do that side of the business and show them our backend" multiple times.
He's not looking to:
- Hire staff augmentation
- Get a fixed-price turnkey project then walk away
He wants to:
- Co-develop with people who understand modern app architecture
- Share IP if the product is successful
- Learn from the partner (he admitted Fractal might teach him as much as he teaches us)
Quote: "You already know that side [software/dapps/AI]. I don't want to have to learn your side of the business."
Thomas was excited Austin used terms like:
- "Dapp" (decentralized app)
- "RAG" (retrieval-augmented generation)
- Graph databases
- Container development
Quote: "When I heard the presentation, a couple things jumped out for me. You mentioned app and dapp. You actually said that word, so that meant that you understand blockchain vocabulary."
He's been burned by developers who:
- Only know SQL (don't understand graph/vector databases)
- Think "Postgres" is the solution to everything
- Have never deployed on industrial Linux edge devices
Thomas repeatedly emphasized:
- "Let's start with one little quick win"
- "Small bite at the apple"
- "Constrain it to make it really easy"
He's willing to:
- Limit scope to 3 UI elements (motor, valve, level sensor)
- Accept imperfect first version
- Iterate based on feedback
Thomas has deep distrust of:
- Microsoft (caught them stealing IP via Chinese data centers—wild story in transcript)
- Rockwell Automation (Allen-Bradley parent—caught them stealing IP multiple times)
- Big cloud providers (don't understand temporal alignment, try to force SQL onto robotics data)
He wants:
- Fractal-sized team that can move fast without enterprise bureaucracy
- People who use their own tools (Austin mentioning Ruck was a moment of validation)
- Engineers who understand the constraints (not just "put it in the cloud and call an API")
- Mobile-First Visualization - This is Fractal's bread and butter (React Native, PWAs)
- Real-Time Data Integration - Experience with WebSocket/event-driven architectures (similar to TalkWise real-time transcription)
- Graph Database UI - While we haven't built graph DB UIs specifically, the pattern is similar to any NoSQL visualization
- Role-Based Access Control - Zero-trust auth patterns (relevant from Fractal OS API gateway work)
- AI Copilot Development - Fractal's LLM integration expertise (Claude/GPT fine-tuning, RAG architectures)
- Blockchain Integration (if Joshua gets involved) - Smart contract development, decentralized storage
- Edge Deployment - Containerized microservices (Docker/Kubernetes) for factory floor devices
- Post-Quantum Crypto (if needed) - Integration with Secured2's QuantaMorphic® encryption
- Fast iteration velocity (Austin shipped Fractal OS from rough prototype to client-ready in 3 weeks)
- AI-native development (Ruck as autonomous coding agent—we're living the future we'd be building for them)
- Modern stack (React Native, TypeScript, event-driven architecture—not legacy enterprise Java)
- Small team agility (no 6-month discovery phases, no enterprise sales cycles)
Context: Thomas is on the autism spectrum, polymath, "barely made it through school" due to dyslexia, but can write with both hands simultaneously, speak almost any language after a week of immersion, and doesn't feel pain (has broken every major muscle group, metal all over his body from extreme sports injuries).
The Story: High school, driving to an AC/DC concert in a Volkswagen Scirocco with friends, "Cheech and Chong smoke rolling out of the thing." Throttle cable breaks on the interstate.
Thomas's Solution:
- Pull over, open hood
- Pull out subwoofer speaker wire from car stereo
- Run speaker wire through the throttle mechanism
- Can only pull throttle cable from left to right (physical constraint)
- Run wire through passenger window
- Friend drives, Thomas controls gas pedal from passenger seat by pulling speaker wire
- Successfully make it to concert
Quote: "It was just normal for me to build an airplane while we were flying an airplane."
Why This Matters: This is how Thomas approaches manufacturing problems—improvise with available resources, ignore conventional rules, make it work in real-time. It's why he built centrifuge control algorithms that "broke the rules" and achieved purity levels beyond the measurement scale.
The Setup: Thomas has intellectual property embedded in industrial control algorithms (machine learning for adaptive process control). Problem: once someone sees the algorithm, they can't "unhear" it—like learning the Smoke on the Water guitar riff, you can't forget it.
Thomas's Defense Strategy: Plant "Easter eggs" in his code—hidden signatures that prove authorship when stolen. He honey-potted Microsoft.
The Heist:
- Thomas planted proprietary ML algorithms in a Microsoft Teams customer environment (customer was using Microsoft-hosted infrastructure)
- Microsoft's agreement with China: All data passing through Chinese data centers is accessible to Chinese government (part of their operating license)
- Microsoft deliberately routes corporate data through Chinese data centers to trigger this agreement
- Chinese "researchers" (state-sponsored) harvest the data and publish it as "public domain"
- Microsoft re-ingests their own leaked data from "public domain" sources
- Microsoft publishes it in their open ML library as "community contributions"
The Reveal: Thomas and several other engineers (independently, not coordinated) simultaneously caught Microsoft doing this. Microsoft's response: Retooled their entire ML library (multiple launch/unlaunch/relaunch cycles).
Thomas's Quote: "They're the ones walking around with a trench coat, flashing with their dick out and then complaining that it's indecent."
Why Thomas Hates Microsoft: "Nothing you do on Microsoft is yours. They own all of it. You just have access to it. It's very difficult to have a private sandbox in a Microsoft world."
Austin's Solidarity: Fractal built a Microsoft Teams app once. Austin's verdict: "Worst. Never again will I build a Microsoft Teams app."
The Crime: Rockwell Automation (maker of Allen-Bradley PLCs) stole Thomas's adaptive control algorithms, deployed them to customers, but didn't understand how they worked.
The Scene: ConAgra Foods plant, production issues, 18 months of failed optimization attempts by Rockwell. Thomas is brought in as consultant. All the vice presidents are there, Rockwell engineers at the keyboard.
The Reveal:
- Thomas: "Open that hex code module."
- Rockwell: "We can't. Only our R&D people know the password."
- Thomas: "Just type this in." [gives password]
- Hex code opens
- Thomas: "Change your radix from hexadecimal to ASCII."
- Rockwell: "This is hex code. You can't read it in ASCII."
- Thomas: "Just humor me."
- ASCII reveals:
- Thomas's name
- Thomas's company
- "Nestle Foods"
The Kicker: Rockwell didn't just steal Thomas's IP—they stole it from a Nestle plant and deployed it to ConAgra (Nestle's competitor).
Thomas (to Rockwell engineer): "You dumb [expletive]. You could have at least stolen it from ConAgra! Now I have to tell Nestle that their competitor has stolen intellectual property that they licensed from me."
Outcome: Thomas starts taking pictures of everyone. ConAgra security escorts everyone out. Nestle gets notified of IP breach. Rockwell presumably has very bad day.
Lesson: This is why Thomas wants blockchain immutability for manufacturing data—prevent tampering, prove provenance, catch IP theft with cryptographic signatures instead of ASCII Easter eggs.
Context: 1990s, building a paper mill in Columbus, Mississippi (middle of nowhere). Construction site kept having chlorine rail car spills (SO4 and Cl2 tanks adjacent—if both leak simultaneously, everyone in the county dies because you're dead before you smell SO4).
Thomas, carrying Scott air packs: "You realize this is the fourth time in a month and you've been one rail car away from killing everybody in the county?"
The Mission: Two French engineers from Alpha Laval can't get their centrifuges running. Cargill (big American company) forced them to use Allen-Bradley PLCs instead of Siemens (European standard). French engineers don't know how Bradley processors work.
Thomas's Gambit: "Let me stay through the weekend. I'll rewrite the whole thing. If it doesn't work, I'll put everything back, no harm done."
The Breakthrough:
- Traditional centrifuge startup: 3 people, 20-30 minutes, manual valve adjustments listening to back pressure
- If you "break over" (exceed interface edge), you must stop, spin down, restart from zero
- Thomas didn't know these "rules"
What Thomas Did:
- Used high-frequency data histogramming in PLC memory
- Detected torque rolloff signature right before "break over" (like pushing into a balloon—it squeaks before it pops)
- Built adaptive feedback loop that modulates 3 variables (speed, back pressure, flow) to "ride the edge"
- Start/stop/restart at will (previously thought impossible)
The Return: French engineers come back Monday. Thomas is starting and stopping centrifuge from control room with a button press. They're freaking out: "You can't do that!"
The Results:
- Oil purity 5 levels above the measurement scale (literally off the chart—Cargill thought Thomas used different feedstock because it was too pure)
- Unlocked palm kernel oil separation (previously impossible at this purity)
- Cargill stopped building new plants—existing plants now had so much capacity they dominated the market
- Only competitor left: Bunge (government said Cargill couldn't monopolize)
The Stuxnet Connection: ~2 years later, Stuxnet virus (first industrial cyber weapon) attacked Iranian nuclear centrifuges using Thomas's algorithm in reverse—instead of riding the edge, it deliberately over-sped centrifuges to break them.
Thomas: "I would never think of that. They took my algorithm and used it to destroy equipment. That's when I realized the power of what we were doing."
Why This Matters: This is the level of domain expertise Thomas brings—30 years of ML in manufacturing before LLMs existed. He's not jumping on the AI hype train; he's been living it since the 1990s.
The Problem: Production line at one end of factory shuts down every day. No one can figure out why. It's been happening for 18+ months.
The Clue: Old operator says, "Oh yeah, that always happens when [the jam kitchen] does that thing."
Engineering team: "That line has nothing to do with this line. They're at opposite ends of the factory making completely different products."
Thomas's Investigation:
- Took alarm logs from both systems (before BC Automation had decentralized data tools)
- Imported into his vector database to find temporal correlations
- Discovered: Jam kitchen pressure vessel releases → massive air pressure drop → ripple effect across entire plant
Why Traditional Systems Missed It:
- Pressure drop lasted less than 1 second
- Traditional PLC sample rates too slow to catch the dip (data appeared stable)
- Pressure gauges showed "no problem" because signal averaged out before next sample
- Temporal misalignment in historian data (timestamps based on SQL insert time, not actual event time)
Thomas's Solution:
- Didn't need a new $500,000 air compressor (what plant engineering was planning)
- Installed a $500 air accumulator (big tank) upstream of affected subsystem
- Acts like a shock absorber—when pressure drops, tank releases stored air to smooth it out
- Problem solved for 0.1% of the proposed cost
Why Edge AI Was Required:
- Only visible at high sample rates (1000+ samples/sec)
- Only detectable with temporal precision (sub-millisecond alignment)
- Only discoverable with cross-system correlation (graph database connecting unrelated lines)
Thomas: "This is what we mean by temporal alignment. Traditional historians have zero temporal alignment—they think they do, but timestamps are based on SQL insert time, not signal time."
The Feature: BC Automation integrates with factory badge readers (HID cards used for building access). When worker badges in at turnstile, system:
- Identifies worker
- Looks up their role/station assignment
- Pre-loads their likely UI screens before they reach their workstation
- Reduces latency (no waiting for screen to load when they log in)
The Reaction: Cargill workers were "freaked out" when they walked up to a terminal and it already knew who they were.
Worker: "Wait, how did it know I'm Carlos?"
Thomas: "Because you just badged in at the turnstile."
Worker: "What?!"
Thomas: "We have situational awareness."
Thomas's Follow-Up Offer: "If you wanted to, you could pay me a little more and we'll start redacting information. So when contractors come on the floor, they can't see what your GPM [gallons per minute] is."
Why This Is Relevant:
- This is the zero-trust, role-based UI concept for Visionary™
- Same screen shows different data layers based on identity
- Not creepy when it's your workers being productive
- Very useful when it's contractors/auditors who shouldn't see trade secrets
1990s Problem: PLCs had no permanent data logging. You were limited by:
- PLC memory (tiny)
- Serial port buffers (even tinier)
Thomas's Early Solution:
- Connected PLC 16-bit output to a pager dialer
- Sent BCD (binary-coded decimal) text messages to his pager
- Could scroll back through pager messages to see event history
- Calculated latency, figured out timing
- Went "old school"—connected to an answering machine
- Used tape backup as event data logger (recorded audio tones representing digital signals)
The BlackBerry Era: "As soon as the BlackBerry came out, the world changed for me because now I have freaking two-way. I could do like remote operations of a freaking plant."
Why This Is Crazy: Thomas was doing IoT remote monitoring in the 1990s using pagers and answering machines because the technology didn't exist yet. This is the level of resourcefulness he brings.
Thomas's Self-Description:
- On the autism spectrum
- Severe dyslexia (couldn't go to college—"barely made it through school")
- Doesn't feel pain (weird neurological quirk)
- Polymath: Can write backwards and forwards, use both hands simultaneously
- Can assimilate and speak almost any language after ~1 week of immersion
Trade-Offs:
- Can't fill out a tax form
- Can't use a spreadsheet
- Can't do conventional business tasks
Strengths:
- Sees patterns others miss (visual/spatial thinker, not linear/linguistic)
- Intuitive grasp of physics (vector math, mechanical systems)
- Rapid context switching (learns languages, adapts to factory environments)
Quote: "People would say something and I would giggle because I'm like, well, that's not how it works at all. You're going to be criticized by a [dyslexic person on the spectrum], and you just kind of learn to go, 'Yes. Enjoy your pizza.'"
Why This Matters: Thomas is a non-traditional genius—the kind of person who can't pass standardized tests but can rewrite industrial control theory in a weekend. Fractal should expect:
- Unconventional communication (stories, analogies, not PowerPoints)
- Intuitive leaps (he won't always explain his reasoning step-by-step)
- Impatience with bureaucracy (he wants to build, not do discovery phase paperwork)
- Improvisation Under Constraints (speaker wire as throttle cable, pager as data logger)
- Breaking Conventional Rules (centrifuge startup methods, edge data storage)
- IP Protection Warfare (Easter eggs, catching corporate theft, blockchain as defense)
- Orders of Magnitude Improvements (0.1% cost solutions, 5x purity increases, 95% capacity unlocks)
- Distrust of Big Tech (Microsoft, Rockwell, cloud providers who don't understand real-time control)
- Thomas is a technical founder (not a business guy who hired engineers)
- He's been burned by vendors (wants partners, not contractors)
- He values speed and creativity over process and credentials
- He's ahead of the curve (did ML in 1990s, blockchain in 2010s, quantum crypto in 2020s)
- He needs people who can match his energy (Austin's Ruck mention was a validation moment)
- Discovery Call: Tuesday or Wednesday, noon or later (Joshua available, Matt leading)
- Thomas will send: Visionary™ white paper (he said "if you read it, you'd go 'oh, that makes sense'")
- Fractal should prepare: Questions about data backend API, graph DB schema, authentication model
- Scope: 3-element UI (motor, valve, level sensor)
- Platform Decision: React Native (iOS-first) vs PWA (web-first)—depends on primary user (factory worker vs operator at fixed screen)
- Timeline: Thomas wants "small bite at the apple"—probably 2-4 week sprint
- Budget: TBD (Thomas deferred to Fractal for pricing guidance)
- AI Copilot Integration (voice/chat interface for Visionary™)
- Blockchain Audit Trail UI (ReflexIQ™ visualization)
- Post-Quantum Crypto (if Fractal gets involved in backend infrastructure)
- Partnership Structure (Thomas hinted at co-development/IP sharing if successful)
- Data Backend: What's the API surface? REST, GraphQL, WebSocket, gRPC?
- Graph DB: What database are you using? (Neo4j, ArangoDB, custom?)
- Authentication: How do badge readers integrate? OAuth, SAML, custom?
- Real-Time Updates: Pub/sub model? How frequently does data change?
- Primary User: Is Phase 1 for factory workers (phone) or operators (fixed screens)?
- Offline Mode: Do edge devices need to work without internet connectivity?
- Data Sensitivity: What compliance requirements exist? (FDA, aerospace, ITAR?)
- Partnership Structure: Staff aug, fixed-price, rev-share, co-development?
- IP Ownership: Who owns the Visionary™ UI code?
- Timeline: When do you need MVP? (Trade show demo, customer pilot, internal testing?)
Prepared by Ruk | 2025-12-01T15:18:20
This summary synthesizes the Thomas-Austin transcript, BC Automation strategic briefing, and Joshua-Austin transcript. For raw transcripts, see source files.