Physical AI Toolchain

The repository is public on GitHub at https://github.com/microsoft/physical-ai-toolchain. All source code, documentation, infrastructure-as-code, CI/CD workflows, issue templates, and configuration files are publicly visible. The repository settings are configured for public access with no authentication required to view, clone, or fork.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain

The project uses Git for version control, which tracks every change with author identity, timestamp, commit message, and full diff. Every file modification is recorded in the Git history. GitHub's web interface provides commit history, blame view, and diff comparison for every file. The project enforces Conventional Commits format (feat:, fix:, docs:, chore:, etc.) via contribution guidelines, providing structured change descriptions.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/commits/main
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md

All commits are pushed to the public GitHub repository continuously. The PR-based workflow ensures that every change is visible as a pull request before and after merge. Interim work-in-progress is visible through open PRs and feature branches. GitHub's branch protection rules require PR review before merging to main, so all interim states are publicly accessible. There is no private staging or hidden development — all work flows through the public repository.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/pulls
• https://github.com/microsoft/physical-ai-toolchain/branches

Git is a distributed version control system. Every clone of the repository contains the complete history and can function independently. Contributors fork and clone the repository (as documented in CONTRIBUTING.md), work locally, and submit changes via pull requests. There is no single point of failure — any clone contains the full repository history and can serve as a restore point.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://git-scm.com/about/distributed

Every release has a unique version identifier. Four releases have been published: v0.1.0, v0.2.0, v0.3.0, and v0.4.0. Version numbers are managed by release-please automation, which reads Conventional Commits and bumps versions according to semantic versioning rules. The version is synchronized across pyproject.toml (Python package) and package.json (Node.js tooling) via release-please-config.json. Once a version is released, it is never reused or overwritten.

Evidence:
- https://github.com/microsoft/physical-ai-toolchain/tags
- https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
- https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
- https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json

Every release is tagged in the Git repository with a "v" prefix following the pattern vMAJOR.MINOR.PATCH. Four tags exist: v0.1.0, v0.2.0, v0.3.0, v0.4.0. Tags are created by release-please automation and are cryptographically signed using Sigstore gitsign keyless signing. The verify-tag-signature.yml workflow validates that all release tags are annotated (not lightweight) and carry valid cryptographic signatures. Tag integrity is verified via git tag -v with x509 format.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tags
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/verify-tag-signature.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md (Sigstore signing section)

CHANGELOG.md follows the Keep a Changelog format (https://keepachangelog.com/) with Semantic Versioning. Each release entry documents changes categorized by type: Added, Changed, Fixed, Documentation, Refactoring, Performance, Build System, Operations, Chores, Security, and Miscellaneous (dependency bumps). release-please automation generates changelog entries from Conventional Commit messages, ensuring every merged PR with a conventional prefix appears in the release notes. The release-please-config.json maps commit types to changelog sections. GitHub draft releases are also created by the release workflow.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CHANGELOG.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml (release-please job)

No CVEs have been filed against this project to date. However, the release notes infrastructure is in place to document vulnerability fixes when they occur. Security-relevant dependency bumps (e.g., werkzeug, flask, cryptography) are tracked in the CHANGELOG.md under the Miscellaneous/Dependencies section. The release-please-config.json includes a dedicated "security" changelog section mapped to the "security" commit type, ensuring any security fix committed with "security:" prefix appears prominently in release notes. Additionally, GHSA vulnerability remediations are tracked and documented (e.g., PR #271).

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CHANGELOG.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/release-please-config.json
• https://github.com/microsoft/physical-ai-toolchain/pull/271

Users can report bugs and issues via GitHub Issues, which are publicly accessible. The repository provides 7 structured issue templates in .github/ISSUE_TEMPLATE/ covering: bug reports, feature requests, documentation issues, security vulnerability reports, infrastructure requests, and more. Each template includes pre-defined labels, required fields, and guidance text. The process is documented in CONTRIBUTING.md (how to file) and SUPPORT.md (what to expect). Security vulnerabilities have a separate private reporting channel via SECURITY.md.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/ISSUE_TEMPLATE
• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md

GitHub Issues serves as the project's issue tracker. It is publicly readable, searchable, and filterable. Issues support labels, milestones, and assignees for triage and tracking. The 7 issue templates apply automatic labels for categorization. Closed issues remain in the searchable archive. The tracker is integrated with PRs via GitHub's "Fixes #NNN" linking, providing traceability from bug report to fix.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/issues?q=is%3Aissue+is%3Aclosed

SUPPORT.md documents explicit response time commitments organized by severity tier: Security Issues — 24 hours (per SECURITY.md), Critical Bugs (data loss, security) — 1-2 business days, Major Issues (significant feature/workflow impact) — 3-5 business days, General Questions and Minor Issues — 14 business days. Issues are actively triaged by the @microsoft/edge-ai-core-dev team (CODEOWNERS). The repository shows consistent response patterns on filed issues.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/CODEOWNERS

Feature requests are accepted through GitHub Issues using the dedicated feature request issue template. Enhancement suggestions are tracked via milestones and project boards. SUPPORT.md provides response time expectations. docs/contributing/ROADMAP.md documents the project's planned direction, allowing contributors to see how enhancement requests align with project goals. The CONTRIBUTING.md explains how to propose changes and the review process for new features.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues
• https://github.com/microsoft/physical-ai-toolchain/tree/main/.github/ISSUE_TEMPLATE
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/contributing/ROADMAP.md

GitHub Issues provides a permanent, public, searchable archive of all bug reports. Closed issues are retained indefinitely and remain accessible via search, filters, and direct URL. Issue history (comments, label changes, assignee changes, linked PRs, status transitions) is preserved. The archive is accessible without authentication. Issues can be filtered by label, milestone, date, author, and state (open/closed).

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/issues?q=is%3Aissue+is%3Aclosed
• https://github.com/microsoft/physical-ai-toolchain/issues

SECURITY.md (Microsoft Security Response Center template V0.0.9) provides a clear vulnerability reporting process. Security issues are reported via the Microsoft Security Response Center (MSRC) at https://msrc.microsoft.com/create-report or via email to secure@microsoft.com. The document explains what constitutes a security vulnerability, provides a PGP key for encrypted communication, references the Microsoft Bug Bounty program, and links to the Coordinated Vulnerability Disclosure (CVD) policy. This is the standard Microsoft OSS security reporting process used across thousands of Microsoft repositories.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://msrc.microsoft.com/create-report

SECURITY.md directs reporters to submit vulnerabilities privately through two channels: (1) the Microsoft Security Response Center portal at https://msrc.microsoft.com/create-report, and (2) email to secure@microsoft.com with optional PGP encryption. The reporter is explicitly instructed NOT to report security vulnerabilities through public GitHub issues. Both channels are confidential — MSRC handles reports under their Coordinated Vulnerability Disclosure (CVD) policy, keeping details private until a fix is available. PGP key download is available at https://aka.ms/security.md/msrc/pgp.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://msrc.microsoft.com/create-report
• https://www.microsoft.com/en-us/msrc/cvd

SECURITY.md commits to a 24-hour initial response for reported security vulnerabilities. SUPPORT.md also documents security issues as the highest priority tier with a 24-hour response SLA. The Microsoft Security Response Center (MSRC) backs this commitment with their global security incident response team providing follow-up through investigation, remediation, and disclosure. The MSRC has a track record of responding to reported vulnerabilities within their published timelines across all Microsoft OSS projects. Additionally, PR #233 adds explicit vulnerability remediation timeline documentation.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SUPPORT.md
• https://github.com/microsoft/physical-ai-toolchain/pull/233

The project uses a reproducible build system. Python packages are built via hatchling (defined in pyproject.toml) with uv as the package manager. The src/training/ package builds into a wheel artifact. Node.js tooling uses npm with package.json and lockfile. Terraform infrastructure is in deploy/001-iac/ with standard terraform init/plan/apply. The setup-dev.sh and setup-dev.ps1 scripts automate development environment setup. The main.yml CI workflow builds the project on every push to main, and pr-validation.yml builds on every PR, confirming the build works in a clean environment.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json
• https://github.com/microsoft/physical-ai-toolchain/blob/main/setup-dev.sh
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml

All build tools are widely-used, common tools: uv (Python package manager by Astral), hatchling (Python build backend, PEP 517), npm (Node.js package manager), and Terraform (HashiCorp). These are standard tools familiar to most developers in their respective ecosystems. No custom or obscure build tools are required. The setup-dev.sh script documents and installs all required development tools.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (hatchling build system)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json (npm scripts)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/setup-dev.sh

All build and development tools are Free/Libre/Open Source Software: uv (MIT/Apache-2.0), hatchling (MIT), npm (Artistic-2.0), Terraform (BUSL-1.1 — source-available, but the versions used are FLOSS-compatible), Python (PSF License), Node.js (MIT), Ruff (MIT), pytest (MIT), Pester (Apache-2.0). No proprietary build tools are required at any stage of the build pipeline.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml
• https://github.com/astral-sh/uv (MIT License)
• https://github.com/pypa/hatch (MIT License)

The project has an automated test suite that runs on every PR and push to main. Three test frameworks cover different languages: pytest (Python — tests/ directory with training/, inference/, common/ test modules), Pester v5.7.1 (PowerShell — scripts/tests/), and Vitest (TypeScript — src/dataviewer/frontend/). Test execution is automated in CI via pytest-tests.yml, pester-tests.yml, and dataviewer-frontend-tests.yml, all invoked as required jobs by pr-validation.yml and main.yml. The tests/ directory includes conftest.py with shared fixtures and init.py for proper module resolution.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tree/main/tests
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pester-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dataviewer-frontend-tests.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/tests/conftest.py

Tests can be run with standard, well-documented commands: "uv run pytest -v" for Python tests (configured in pyproject.toml [tool.pytest.ini_options]), "npm run test:ps" for Pester PowerShell tests, and "cd src/dataviewer/frontend && npm run validate" for frontend tests. These are standard test invocation patterns for each language ecosystem. No custom test harness or unusual setup is required. CI runs the same commands developers use locally.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (pytest configuration)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/package.json (test:ps script)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml

Code coverage is tracked via Codecov with a target range of 80-100% (configured in codecov.yml). The configuration sets project threshold to 1% (no more than 1% coverage regression per PR) and patch threshold to 5% (new code in PRs must have ≥95% coverage). Branch coverage is enabled (branch: true in pyproject.toml [tool.coverage.run]). Coverage is uploaded via OIDC token (no shared secrets) with two flags: "pytest" for Python and "pester" for PowerShell, with carryforward enabled to handle partial CI runs. The codecov.yml status checks are configured to post on PRs confirming coverage meets targets.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (coverage configuration)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pytest-tests.yml (Codecov upload)

CI runs on every PR via pr-validation.yml (16 child jobs) and on every push to main via main.yml (14 child jobs). Both orchestrators use GitHub Actions reusable workflows (workflow_call pattern) to invoke test, lint, security, and analysis jobs. Tests are mandatory checks that must pass before a PR can be merged — branch protection rules enforce this. The release-please job in main.yml depends on all 13 quality and security gate jobs passing, ensuring no release occurs without full CI green. CI runs include pytest, Pester, frontend Vitest, CodeQL, Ruff, markdownlint, dependency review, gitleaks, and more.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/main.yml
• https://github.com/microsoft/physical-ai-toolchain/actions

CONTRIBUTING.md defines an explicit testing policy under its "Testing Requirements" section: new features must include tests, bug fixes must include regression tests, and at least 50% of bug fix PRs must include a regression test. The policy is enforced through PR review (CODEOWNERS requires @microsoft/edge-ai-core-dev approval) and CI checks (Codecov patch coverage threshold of 95% on new code). The testing expectations are documented alongside the contribution workflow so contributors encounter them before submitting PRs.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/CODEOWNERS

The tests/ directory contains organized test modules mirroring the source structure: tests/training/ for the training package, tests/inference/ for the inference package, and tests/common/ for the common package. Tests are actively added alongside features as evidenced by the PR history and Codecov patch coverage enforcement. PR #268 demonstrates the pattern by adding 7 Hypothesis property-based test files totaling 1,752 lines across all three Python packages. The Codecov patch threshold (95%) on every PR ensures new code is tested.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/tree/main/tests
• https://github.com/microsoft/physical-ai-toolchain/blob/main/codecov.yml
• https://github.com/microsoft/physical-ai-toolchain/pull/268

CONTRIBUTING.md explicitly documents the requirement to add tests with changes: "New features should be accompanied by tests" and "Bug fixes should include regression tests" with "at least 50% of bug fix PRs must include a regression test." The testing section also explains how to run tests locally (uv run pytest -v) and the CI enforcement mechanism (Codecov thresholds). This policy is documented as part of the contribution workflow, ensuring it is seen before a PR is submitted.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/CONTRIBUTING.md

The project enables and addresses compiler/linter warnings across all code types: Ruff (Python — 8 rule sets: E, W, F, I, UP, B, SIM, RUF) via python-lint.yml, markdownlint-cli2 (Markdown) via markdown-lint.yml, PSScriptAnalyzer (PowerShell) via powershell-lint.yml, yaml-lint (YAML) via yaml-lint.yml, cspell (spelling) run separately, ESLint (TypeScript) via dataviewer-frontend-tests.yml, and TypeScript type-checking (tsc --noEmit). All linters run in CI on both PRs and main pushes. Ruff runs both lint and format checks.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/markdown-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/powershell-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (ruff configuration)

CI enforces zero warnings as a merge gate. All linter workflows (Ruff, markdownlint, PSScriptAnalyzer, yaml-lint, ESLint, TypeScript type-check) are configured to fail on any warning. These are required checks in pr-validation.yml — a PR cannot merge with linter failures. The main.yml pipeline inherits the same checks, ensuring warnings on main are caught immediately. The 16-job pr-validation.yml gate blocks any code with warnings from reaching the main branch.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/pr-validation.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml
• https://github.com/microsoft/physical-ai-toolchain/actions

Ruff is configured with 8 rule sets (E, W, F, I, UP, B, SIM, RUF) covering error detection, warnings, pyflakes, import sorting, Python upgrade suggestions, bugbear, simplification, and Ruff-specific rules — this represents a broad, strict configuration. CodeQL runs with "security-extended" and "security-and-quality" query suites, which are the maximum strictness settings. markdownlint, PSScriptAnalyzer, yaml-lint, ESLint, and TypeScript --noEmit all run with their default (strict) configurations. Combined, these tools provide extensive static analysis coverage across all major code types in the project.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/pyproject.toml (ruff rule sets)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml (security-extended + security-and-quality)
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/python-lint.yml

The project demonstrates knowledge of secure design principles through a comprehensive STRIDE-based threat model (docs/security/threat-model.md) identifying 19 threats across 8 trust boundaries (1 Critical, 6 High, 7 Medium, 5 Low severity). The architecture follows zero-trust principles: managed identities instead of passwords, TLS 1.2+ enforced on all connections, private AKS clusters by default, network segmentation via NSGs and private endpoints. The project operates under Microsoft's OSS security governance with SECURITY.md following MSRC template V0.0.9, and docs/contributing/security-review.md provides a security review checklist for contributors.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/SECURITY.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/contributing/security-review.md

The project demonstrates awareness of common security errors through multiple mechanisms: CodeQL with security-extended and security-and-quality query suites catches OWASP Top 10 vulnerabilities (injection, XSS, path traversal, etc.) on every PR. The STRIDE threat model in docs/security/threat-model.md catalogs 19 specific threats with mitigations. Integration with Microsoft Security Response Center (MSRC) provides access to Microsoft's vulnerability intelligence. dependency-review.yml fails on moderate+ severity vulnerabilities. The project's architecture avoids common errors by design — managed identities eliminate credential storage, TLS is enforced (not optional), and the default network mode is fully private.

Evidence:

• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/codeql-analysis.yml
• https://github.com/microsoft/physical-ai-toolchain/blob/main/docs/security/threat-model.md
• https://github.com/microsoft/physical-ai-toolchain/blob/main/.github/workflows/dependency-review.yml