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 supported coding clients and models via MCP, with portable records across tools |
| 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 trw-mcp and trw-memory under BUSL-1.1, with source you can inspect during 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 records your assurance stack can inspect
TRW provides project-local engineering records for your assurance review. These frameworks inform evaluation questions; We assert no certification or control-by-control mapping.
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
Review inputReview what engineering records your audit-trail and transparency obligations require. TRW’s regulatory scope remains an open interpretive question.
NIST AI RMF
Review inputUse risk-scaled run records, requirements, and reported checks as inputs to your risk review. Their presence does not establish conformity with the framework.
ISO/IEC 42001
Review inputInspect run governance, role ownership, and documented reversion as engineering records. Your assurance process determines whether they meet its requirements.
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.