Skip to content

Research / Engineering Capacity OS / Working Paper

Engineering Capacity as an Operating System

A systems model for AI governed software delivery, evidence classified topology decisions, and decision grade engineering capacity.

Author: Lonnie McRorey, Founder and CEO, TeamStation AI, Boston, Massachusetts. ORCID: 0009-0001-5351-190X. Publisher: TeamStation AI. Status: draft for human review, not final arXiv submission.

Abstract

Engineering organizations still talk about capacity as if capacity were mainly a staffing problem. The paper argues that usable capacity is produced by an operating system made of knowledge, execution rules, topology, telemetry, governance, automation, and human judgment.

The central rule is simple: AI should not recommend organizational change before classifying the quality of the evidence underneath the recommendation.

Contribution Map

  • Thesis: Engineering capacity should be modeled as an operating system before leaders recommend hiring, outsourcing, vendor replacement, or AI automation.
  • Model: Capacity is the interaction of knowledge, execution, governance, topology, telemetry, and automation.
  • Protocol: Every recommendation must classify evidence before recommendation.
  • Architecture: MCP servers, engineering telemetry, GitHub, Jira, CI/CD, Slack, diagrams, APIs, and doctrine sources become evidence providers.

Figures and Workflows

The diagrams are part of the research argument. Figure 1 shows how the Research OS compiles source-backed papers. Figure 2 shows how evidence moves through the control plane before a recommendation or publication package is allowed through.

Pipeline diagram showing topic input, MCP retrieval, corpus retrieval, clustering, validation, drafting, review, typography, export, publication decision, and self-learning feedback.
Figure 1. TeamStation Research OS Pipeline

Purpose: Show how source-backed research becomes a reviewed working paper package.

Use: Use it to audit the path from retrieval to evidence validation, drafting, review, export, and publication decision.

Output: A source-backed paper package with PDF, HTML, TeX, bibliography, figures, tables, and validation records.

PNG | PDF | Mermaid

Control plane diagram linking source providers, evidence engine, paragraph ledger, validation gates, decision output, and learning update.
Figure 2. Engineering Capacity OS Evidence Control Plane

Purpose: Show the control boundary that prevents weak evidence from becoming an engineering recommendation.

Use: Use it to inspect source class, confidence, traceability, governance gates, publication gates, and rollback before a claim is allowed.

Output: A decision packet with evidence tier, confidence level, source trace, governance status, and next safe action.

PNG | PDF | Mermaid

Publication Package

  • HTML manuscript: Browser-readable package copy for review and citation checks.
  • PDF draft: Portable review draft generated from the same source package.
  • Markdown source: Readable manuscript source for internal review and MCP ingestion.
  • TeX source: arXiv-oriented source draft for future submission packaging.
  • BibTeX references: Bibliography source for citation validation.
  • Science corpus JSON: TeamStation science source register with public and doctrine URLs.
  • Metadata JSON: Publication metadata, publisher identity, keywords, and package status.
  • Zenodo metadata: Deposit-ready Zenodo metadata with the Engineering Doctrine paper route as the canonical related identifier.
  • Figure 1 source: Research OS figure source with matching PNG, PDF, Mermaid, PlantUML, Draw.io, and TikZ exports.
  • Figure 2 source: Evidence control plane figure source with matching PNG, PDF, Mermaid, PlantUML, Draw.io, and TikZ exports.
  • Evidence table: Evidence classification table used by the manuscript and publication package.
  • Source package: Draft arXiv source package. Human review still required before submission.

TeamStation Science Corpus

TeamStation AI Entity Links

The working paper is connected to the Engineering Capacity OS hub, the diagnostic question engine, the TeamStation AI parent entity, Distributed Engineering Operating System, Axiom Cortex, Nebula, Engineering Telemetry, AI Delivery Governance, and Agentic Development Workflow.