Ruby Integration Guide
On-device PII detection, redaction and local receipts for Ruby applications with the tork-governance gem (0.2.0). Runs entirely in your process: no API key, no network call. Includes Rails, Sinatra and Grape middleware.
Prerequisites
- Ruby 2.7 or higher (3.0+ recommended)
- Bundler for dependency management
- No API key: the gem governs on-device and never contacts tork.network
Installation
Install the gem using Bundler or directly with gem.
Require it as tork_governance (underscore). The gem name on RubyGems is tork-governance (dash).
Configuration
Configure the shared client once, or create clients explicitly.
TorkGovernance.configure also accepts api_key:. The 0.2.0 on-device client stores it but never uses it: no request leaves your process.
Basic Usage
Govern a string and read the decision, the output and the receipt.
Redact or Deny
Choose what a PII hit does.
PII Detection
Run the detector directly and inspect every match.
Receipts
Every govern call mints a local receipt with SHA-256 hashes of input and output.
The receipt is a local Ruby object. It is not sent to tork.network and does not appear in the Tork dashboard; keep it in your own audit store.
Usage Statistics
Per-client counters for calls, PII hits and processing time.
The gem's cloud client does not work against the live API
tork-governance 0.2.0 also ships a Tork::Client namespace (require 'tork') with evaluate, evaluations, policies and metrics resources. Its default base URL is https://api.tork.network/v1, which returns 404 for every path, and the endpoints it calls (/pii/detect, /pii/redact, /jailbreak/detect, /rag/validate, /evaluate/batch) do not exist on the Tork API. An earlier version of this page documented those calls; they were removed on 24 September 2026 because they cannot succeed as written. Jailbreak detection, policy management, batch evaluation, RAG validation and TORKING-X metrics are not available from Ruby today. For server-side governance with dashboard receipts use the REST API directly (API reference).
Rails Integration
Rack middleware plus a controller concern, both shipped in the gem
Requiring tork_governance/middleware/rails in a Rails app registers TorkGovernance::Middleware::Rails through a Railtie with its defaults (POST/PUT/PATCH under /api/, the shared TorkGovernance.client). Adding it again with config.middleware.use would govern each request twice, so the initializer below only configures the shared client. A "deny" decision returns 403 with the receipt id and PII types; a "redact" decision leaves the request body untouched and exposes the redacted text as request.env['tork.redacted_content'].
Sinatra Integration
Register the extension; it adds a before-filter and helpers.
Grape Integration
Rack middleware with optional response redaction, plus helpers.
The Grape middleware also accepts client: (a TorkGovernance::Client, for example one built with default_action: TorkGovernance::ACTIONS[:deny]) and on_block: (a lambda receiving env, result that returns a Rack response) to replace the default 403.
Thread Safety
Decisions are pure; the stats counters are not synchronised.
Best Practices
Govern both directions
Run user input through govern before it reaches a model, and the model's reply before it reaches the user.
Keep the receipts
receipt.to_h is your audit trail. Store it with the request; receipt.verify(input, output) proves it later.
Pick deny deliberately
The default redacts and continues. Use default_action: TorkGovernance::ACTIONS[:deny] only where PII must never proceed.
Know the detector's scope
0.2.0 ships seven US-format patterns (ssn, credit_card, email, phone, address, ip_address, date_of_birth). It does not detect regional identifiers.
Let the middleware pick the field
The Rails, Sinatra and Grape middleware govern the first non-empty string under content, message, text, prompt, query or input.
Do not wait for the cloud client
Tork::Client in the same gem targets endpoints that do not exist. Use the REST API directly if you need dashboard receipts.
Automatic Retry Behavior
The SDK automatically retries failed requests with exponential backoff. Retryable status codes: 408, 500, 502, 503, 504. Default: 3 retries with 0.5s base delay and 2x backoff factor. Configure via max_retries and retry_base_delay.
Next Steps
Explore more endpoints for jailbreak detection, RAG validation, and multi-agent orchestration.