Platform architecture and web engineering for enterprise B2B SaaS. Boston, Massachusetts. Founder of Kinetic Gain LLC, where I build governance tooling for the answer-engine and agent era.

Background across IBM, CyberArk, Alteryx, Digital.ai and Gryphon.ai, in platform engineering, identity and privileged access, and analytics workflow.

Open to Director of Web Engineering, Principal Platform Engineering, and VP Platform Architecture roles. East Coast US, remote friendly. LinkedIn · kineticgain.com

Selected public source repos, linked directly:

• Protocols and specs: Protocol Suite · Docs Hub · AEO Protocol · Agent Cards · MCP Tool Card · AI Tutor Card
• MCP and evidence: Unified MCP server · Permission Broker · Audit Stream · Embedded runtime · Reliability Toolkit · Decision Intelligence
• Integrations and operator tools: AEO TypeScript SDK · MCP AEO server · MCP AI Tutor · Operator Console · Governance Dashboard · Flightdeck
• Applied systems: RAG Sentinel · Policy Lab · Redaction Gateway · Compliance Ledger · Portfolio Command Center
• Aerospace Suite drafts: ML assurance card · MRO AI sign-off card · Dataset provenance · Assurance crosswalk · Fleet PR gate

Browse every public repository in the dated A–Z index, including archived work. That account-wide index is broader than the curated Kinetic Gain estate; private repos are excluded.

One stdio MCP server for all 12 Kinetic Gain Protocol Suite specs, with 75 callable validation, inspection and workflow tools. Published v0.10.0 on npm and the official MCP Registry; AGPL-3.0.

npx -y mcp-kinetic-gain@0.10.0 validate <files...>

Claude Desktop, one entry:

{
  "mcpServers": {
    "kinetic-gain": {
      "command": "npx",
      "args": ["-y", "mcp-kinetic-gain@0.10.0"]
    }
  }
}

Three tools that show the shape of it:

• aup_check_compliance compares eight disclosed fields in a Classroom AI AUP and Student AI Disclosure; its result is not a live authorization grant.
• decision_card_validate checks an AI Procurement Decision Card's schema and conditional rules; validation does not authorize a tool call.
• defensetech_vault_resolve_3axis previews the most restrictive vault policy from supplied CUI, export-control and foreign-person inputs; it does not verify those inputs.

Version 0.10.0 hardens the optional live audit tools: they require a configured bearer token, reject remote plaintext, and fail closed on malformed requests or responses. The default stdio server remains a local preview, not a buyer-authorized enforcement point. A signed Decision Card gate for one private HTTP tool is under review and is not in the published npm package or MCP Registry record. The aerospace tools are under review in the same server, not in the published package.

The specs are v0.1 drafts. Nothing here has been certified or attested by a third party, and I do not claim otherwise. Where you see regulatory names such as FERPA, HIPAA, DFARS or NYC Local Law 144, they mark which obligation a field is modelled against. They are not a compliance claim about your use of it.

Vertical reference implementations ship with synthetic fixtures only. No PHI, no student records, no real claimant data. Tools report conformance against a JSON Schema, which is a structural check, not a legal opinion.

Every repo carries its own SECURITY.md. That is where the scoped, checkable version of any claim lives.

17 named platforms · 107 live properties · 17 open specs · 17 verticals

Counts are platform cluster sizes; a repo may belong to several platforms, so they sum to 321 membership-slots.

Browse the complete public repository index, including archived projects, or use GitHub's live repository list. The index is account-wide; the platform counts above are overlapping curated memberships.

Those figures regenerate from kinetic-gain-canonical.json every six hours. They are cluster sizes, not a repo total, because one repo can belong to several platforms. The raw public-repo count is deliberately not a headline here: it drifts, and a wrong number costs more than a missing one.

Claims on this page are meant to be checkable in about a minute.

• The published version is checkable. npm view mcp-kinetic-gain version; compare it with the official Registry record.
• The tests are runnable. Clone mcp-kinetic-gain, then run npm ci and npm test; check its current CI result before relying on a release.
• The specs are real. Each is a public repo with a JSON Schema and test vectors.
• The disclosures are live. Any Kinetic Gain domain serves its own /.well-known/ documents.
• The numbers reconcile. The estate block above is generated, not typed.

Dependabot on 410 repos · CodeQL on 98 · OpenSSF Scorecard on 52 (strict subset of CodeQL) · SHA-pinned actions across 558 uses: lines (measured 2026-06-04).

Platform engineering, identity and privileged access, and analytics workflow, across IBM, CyberArk, Alteryx, Digital.ai and Gryphon.ai. That history is why the Kinetic Gain work sits where it does: governance, evidence and trust boundaries rather than features.

Two of the surfaces exist because I lived the problem. cert.kineticgain.com and jml.kineticgain.com are the CyberArk certification-review and the joiner-mover-leaver lines from that history turned into working software.

Polyglot by choice, and the language is picked for the problem rather than for the list. Rust for hot paths and cryptographic primitives, Python for the audit-stream services, TypeScript for the operator surfaces, Go and Elixir where the concurrency model earns it.

Concrete, live, and checkable. Not a portfolio of screenshots.

The languages are ranked by how many repositories actually lead with them across the estate, not by preference. The tooling is what genuinely ships and deploys the work.

Languages

Frontend

Backend and data

Cloud, infra and CI/CD

AI and protocol

Open to Director of Web Engineering, Principal Platform Engineering, and VP Platform Architecture roles at enterprise B2B SaaS companies. East Coast US time zone. Remote friendly.

LinkedIn · kineticgain.com · Medium · All repositories