Partner pilot · TRU Studio 0.3.6

Your first record, on your own edge.

This guide covers installation, connection to your organisation's assigned NEO edge and one synthetic Studio action. Your originals stay on your computer. The action's 32-byte commitment enters the edge; the edge's period commitment goes to the existing NEO rail.

Official downloads and checksums · First connected test · Troubleshooting

1. Install or upgrade

No Python installation, AI subscription or model API key is required. Use the deterministic Learn Guide for the first test. Close all running copies of Studio before upgrading. Back up the entire existing application data folder first; replace the application, not that folder.

These are unsigned pilot builds. macOS has an ad-hoc signature, without Apple notarization; Windows has no publisher signature. Your IT team may need to approve the specific app. Verify the download hash first and use your normal per-application approval process. Do not disable security protection globally. If policy blocks the app, report that before the test.

Compare the complete SHA-256 against the release manifest:

Windows PowerShell: Get-FileHash .\TRU-Studio-0.3.6-Windows-x64-setup.exe -Algorithm SHA256
macOS: shasum -a 256 TRU-Studio-0.3.6-Mac-Apple-Silicon.zip
Linux: sha256sum TRU-Studio-0.3.6-Linux-x64.deb

Substitute your actual filename. Open Studio and check the version and source commit at the bottom of the page. Select Skip AI setup and open my Studio if offered. The Partner guide in Studio opens this guide locally, including when offline.

2. Connect your organisation

For the first session, give your Cotrugli contact your OS/processor, organisation name, technical contact and whether your network permits the assigned HTTPS endpoint or requires a VPN. Your organisation keeps its own identity and credentials; do not reuse another partner's files.

The operator supplies a configuration for the existing connector: rail-edge.json, its trusted CA certificate when needed, and a separate authentication file. These are private connection files, supplied separately from the public installer. They must refer to a reachable, provisioned edge authorised for your assigned provider. A private cluster hostname alone is not an Internet connection.

Close Studio. Open the application data folder:

1. Place the supplied rail-edge.json in that folder. Keep the existing config.json, books and wallet files.
2. Put the CA and authentication files at the exact paths in that configuration. Paths must be absolute; on Windows, JSON backslashes must be escaped or use forward slashes. The authentication file contains the assigned user:password, never a shared demo credential.
3. On macOS/Linux restrict the authentication file to your user: chmod 600 /absolute/path/to/edge-auth. On Windows store it in your own profile and restrict access to your user and the administrators responsible for the machine. Do not put it in a shared or synchronised folder.
4. Reopen Studio. Open Rail evidence from the Studio navigation. Confirm the expected provider and endpoint, and “edge reachable”. Opening this page checks status; it does not create a test action.

A local self-declared name is not verified membership. The operator must check the member/provider mapping and access rights before promoting the connection beyond the synthetic pilot. Use the existing enrolment and Chamber process for membership, wallet or business authorisations.

3. Run one connected test

1. Use synthetic content. Keep the AI model unconfigured for this first check. On the Studio page, select Learn Guide and ask learn: agents once.
2. Open Rail evidence. One new action should appear. Note its local sequence, commitment and provider.
3. Select Refresh from the edge to match the saved action with its edge record. Refresh reconciles records and can send eligible unsent actions; it holds uncertain submissions instead of blindly repeating them.
4. Allow the normal DLT closure process, which can take up to about an hour in this pilot. Refresh later to retrieve the confirmation. Do not ask again just to obtain a faster confirmation: that would create a new action.
5. Close and reopen Studio. Check that the same action, commitment and status remain. Refresh should not create a second record for that action.
6. Return the version/commit, OS, assigned provider, local sequence, edge sequence and displayed status to your agreed Cotrugli contact. Report only these diagnostic references, not credentials or private originals. The operator completes independent strict proof verification before claiming verified inclusion.

4. Originals and a later dispute

Studio keeps the action envelope, question and answer in rail-edge/actions.jsonl in your local data folder. Outgoing commitments and retrieved confirmations are under rail-edge/outgoing/ and rail-edge/confirmations/. Keep the complete folder and your organisation's normal backups; a hash cannot reconstruct a lost original.

The intake carries audit metadata and the 32-byte action commitment, not the question or answer. The binary rail receives the edge's period commitment. If you separately enable a hosted AI model, that provider receives the requests sent to it; “originals stay local” describes the evidence path, not a promise that an external AI service sees nothing.

In a dispute, parties provide the originals and documents requested by the Chamber within its existing deadlines. The evidence allows comparison with the committed material. A matching hash proves correspondence with that material, not that every statement in it is true. No new dispute procedure, automatic legal compliance or automatic payment is created by installing Studio.

5. If something does not work

Scope of this first test: the installed Studio records its own actions. A hospital application, Result workflow or Villanova service must use the existing agreed edge/Co-Tru interface for its own events; installing Studio does not automatically capture those applications. A successful Studio connection is the first acceptance step, followed by one agreed real process.