Define the evidence boundary
Preserve project-local requirements, reported checks, delivery state, and recoverable context. Evaluate the open framework locally, in your cloud, or air-gapped—independent of model or IDE.
Agents proliferated. Org-level accountability did not.
As AI-assisted work spreads across repositories and teams, access and spend records answer only part of the review. Requirements, observed checks, retained knowledge, and exception decisions need their own inspectable trail.
usage may be recorded — delivery evidence still needs its own contract
Usage records are not delivery evidence
Seat and token reports can show who used a tool and how much it cost. They do not, by themselves, bind a requirement to the repository checks reported for a delivery.
One team is not the organization
A team-local record cannot answer an organization-wide question unless projects use compatible ownership, evidence, and handoff contracts.
Knowledge stops at project boundaries
Useful discoveries remain local unless they meet an explicit validation and recall policy. Sharing everything would create a different governance failure.
Governance across time, not governance of access
Access governance and work evidence answer different questions. TRW focuses on the second: preserving requirements, reported checks, delivery state, and recoverable context across sessions without replacing your coding client or assurance stack.
Access tells you the bill. Work tells you what you bought.
| Dimension | Host-locked access governance | TRW work governance |
|---|---|---|
| Unit of analysis | Users, seats, spend — activity measured by the host | Requirement paired with a content-bound, reporter-supplied build receipt |
| What the record contains | That a tool was used, with its activity and cost metadata | The claimed result, scope, and receipt metadata—not independent execution of the check |
| Vendor coupling | Usually scoped to activity visible within one host | Above any IDE, model, or host via MCP — governance is not hostage to one vendor |
| Where it runs | Often a vendor-managed service | Open framework on your infrastructure—local, your cloud, or air-gapped |
What you can evaluate today
These surfaces are available now, with their boundaries stated directly. Use them as the starting inventory for security and procurement review.
Org & roles
Single-org team workspace — invite teammates by email with a role, create sub-teams, add and remove members
Owner / admin / member, with cross-tenant privilege-escalation guards
Org / team / membership entities; architecture designed for N-level org hierarchy
Org-scoped analytics summary
Evidence & data rights
Persisted, org-scoped audit trail of org and membership activity
Configurable memory provenance can add a SHA-256 content hash and Ed25519 signature; legacy, disabled, or fail-open records may remain explicitly unsigned (the platform audit trail is persisted without content hashing today)
GDPR JSON export and erasure
Identity & deployment
Per-org API keys; JWT / OAuth / 2FA authentication
trw-mcp and trw-memory run repo-local; off-machine platform telemetry is off by default while local tool telemetry remains enabled
On the developer’s machine, in your own cloud, or fully air-gapped
Source-available BSL-1.1 codebase with OWASP-focused security checks—readable for vendor review
Run TRW in your environment
The open framework runs on infrastructure you control today. The hosted platform is currently TRW-managed; an in-perimeter platform deployment is not a current offering or commitment.
Air-gapped
AVAILABLE NOWOffline install from embedded wheels with no PyPI access; hosts pre-stage Python dependencies and keep networked tools disabled.
On-prem / your cloud
AVAILABLE NOWOpen framework on your own AWS, VPC, or on-prem host. Repo-local memory.
Hosted platform BYOC
NOT CURRENTNot currently offered. The deployment model is still under evaluation; do not plan a rollout around this surface.
TRW-managed SaaS
OPT-INThe hosted platform, run by TRW. Opt-in; org-scoped audit recorded server-side.
Engineering evidence your assurance stack can inspect
TRW can supply an engineering-side record for broader assurance workflows. Each mapping is an evaluation prompt—not a certification, legal conclusion, or automatic compliance.
Coding clients produce the work. TRW records selected requirements, reported checks, and handoff state. Your assurance process decides how that evidence maps to policy. TRW does not replace either layer.
EU AI Act
Maps toAligns with audit-trail and transparency readiness. Whether AI-assisted coding is high-risk is an open question we do not assert.
NIST AI RMF
Maps toMaps to Map / Measure / Manage review questions through risk-scaled run records, requirements traceability, and persisted audit events—a readiness signal, not a certification.
ISO/IEC 42001
Maps toAligns with the AI-management-system evidence expectations — run governance, role ownership, documented reversion. TRW supplies the underlying record, not the certificate.
Questions a security and procurement review will ask
Yes, for the open framework. It runs repo-local on infrastructure you control and supports offline installation for air-gapped environments. Keep explicitly networked tools disabled there. Hosted-platform deployment inside your environment is not a current offering or commitment.
The open framework is repo-local. Without a platform URL, automatic TRW platform sync and off-machine telemetry egress stay off; local tool telemetry remains enabled, and explicitly invoked network tools are separate. The TRW-managed SaaS is opt-in and records org-scoped audit and telemetry server-side.
A single-org team workspace with an owner / admin / member role model, sub-teams, per-org API keys, and a persisted org-scoped audit trail—on a data model designed for N-level hierarchy. If enterprise identity federation (SSO / SAML / OIDC, SCIM) is a hard requirement, talk to us about fit for your environment.
The open framework, yes—it is repo-local and runs on your infrastructure today. Hosted-platform BYOC is not a current offering or commitment.
We assert no certification. TRW can provide an engineering-side record for your assurance process. We use NIST AI RMF, ISO/IEC 42001, and EU AI Act control families as evaluation prompts—not legal compliance or high-risk classification. Not legal advice.
Isolation is enforced at the application layer, with cross-tenant privilege-escalation guards on role boundaries. We document the isolation model in plain terms rather than implying more than it guarantees.
We make no blanket claim. Memory provenance is configurable: enabled records can carry a SHA-256 content hash and Ed25519 signature, while disabled, legacy, or fail-open records may remain explicitly unsigned. The MCP learn path can keep an advisory, fail-open hash-chained provenance log. The platform audit trail is persisted without content hashing today.
Org rollout is a design-partner motion scoped per case, so the honest answer is a conversation rather than a number. Talk to us about org rollout fit and we will scope it to your case.
No. Coding clients and models produce the work. TRW records selected requirements, reported checks, and handoff state through MCP. Your GRC and audit process decides how to evaluate that evidence. TRW replaces neither layer.
Define the evidence boundary before you expand the rollout
Start with a scoped evaluation: choose the projects, evidence boundary, deployment surface, identity requirements, and exception policy. We will document what is available now, what remains local to the open framework, and what requires a design-partner engagement.