MEMBER GUIDE / 17 OCTOBER 2026
One organisation.
One record.
One checked proof.
Start with the existing Studio package. Your first session checks your own connection and evidence path; it does not require a customer or an AI subscription.
Connection is coordinated individually. Installing Studio does not automatically enrol your organisation, grant a mandate or provide a shared public edge.
1. Prepare your first session
Give your existing Cotrugli contact your organisation name, technical contact, operating system and CPU architecture, approved network route, and one process you want to record. Start with a synthetic contribution, without patient or customer data.
We coordinate an assigned organisation/provider identity, an authorised edge endpoint and private connection settings. Keep credentials and private network details out of public issues.
2. Install the current package
Choose Windows, Mac or Linux ↓
The current release checked for this proposal is Studio 0.3.6: Windows x64, macOS Apple Silicon or Intel, and Linux x64. Use the download page and its manifest as the release authority. Verify the published SHA-256 and follow your organisation’s approval process for unsigned software; do not disable system protection globally.
Skip AI setup for this evidence test. An OpenAI or other AI key is not required.
3. Apply your private connection
Close Studio. Follow the maintained installation and Rail evidence guide. Your operator supplies rail-edge.json, the authentication file and any required CA separately. Use the assigned endpoint and identity; do not copy another member’s credentials.
- Windows:
%APPDATA%\tech.cotrugli.tru-studio - macOS:
~/Library/Application Support/tech.cotrugli.tru-studio - Linux:
~/.local/share/tech.cotrugli.tru-studioor the configured XDG data home.
Preserve existing configuration, books and wallet files. Authentication and CA paths must point to the supplied local files. Reopen Studio and check the expected provider and endpoint in Rail evidence.
4. Record one synthetic action
Use the maintained guide’s Learn example, such as learn: agents. Keep the local original and its identifier. In Rail evidence, Refresh may send eligible unsent actions; it is not a purely read-only command. If an earlier submission is uncertain, follow the hold/recovery procedure instead of recreating the action.
5. Wait for the normal confirmation
Final DLT confirmation can take up to about an hour in the current process. Record the local/book time separately from later finality. Do not resend an action merely because its final proof is pending.
| Status | What it tells you |
|---|---|
| RECORDED | The action is recorded locally. |
| SENT | The submission reached the intake stage. |
| ON_EDGE | A matching edge book record is found. |
| CONFIRMED | The edge reports FINAL and Studio reads the returned confirmation. This alone is not independent cryptographic verification. |
| VERIFIED_STRICT | A separate operator verification result using independently pinned trust. Do not infer this from the Studio label. |
6. Complete the first check together
- Identify the organisation, actor and original for one action.
- Match the original commitment to the same book entry.
- Fetch and independently verify the returned proof.
- Reopen Studio and read the same record without submitting it again.
- Record the tested release, time and result, including any pending step.
Keep originals and local evidence files backed up under your organisation’s policy. A rail commitment does not preserve the original for you.
7. Connect one shared job
After both edges pass the connection check, use one work reference across the request, execution, result and acceptance. Result and Villanova AI are the proposed first pair; their connections and roles are still pending.
| Member | First connection | What comes back |
|---|---|---|
| Result · proposed requester | One synthetic input or permitted input reference, the intended recipient, expected output and acceptance criteria. | Receipt, progress and result for the same work reference. |
| Villanova AI · proposed provider | One existing callable service, its supported input/output and an authorised execution callback. | Result reference, execution status and error if the job cannot finish. |
| Authorised reviewer | The applicable criteria and mandate on the existing shared plan. | Acceptance or a request for correction; final rail proof is shown separately. |
The application executes the service. The edge records its events and uses the separate authorised sharing path for permitted business data. Only commitments go to the rail. Installing Studio verifies the record path; it does not by itself wire an application or launch an AI service.
Use the existing business host and its scoped work/actions interface. Your operator binds the two assigned identities, common work reference and existing callbacks; no public credentials or extra rail sender are needed. Test one request and returned result, then a controlled retry and a failed execution. Keep the same work identity and show who must act next.
Once the result is accepted, include the contribution in an agreed period. Cost treatment and allocation remain a proposal until members adopt them. See the dated LAB example and proposed partner flow ↗
If something fails
Record the Studio version, OS, time, non-secret status and error. Check the approved DNS/network route, TLS trust and assigned identity with your operator. Keep uncertain submissions on hold. Never post keys, authentication files, patient material or private originals in the repository. Use the maintained guide for recovery.