A trust registry combines identity information with the keys and lifecycle context needed to interpret signed records. The Truthlocks codebase implements its registry service in Go and uses PostgreSQL for persistent records. The more important architectural questions concern boundaries: who owns a record, who can change it, and how a verifier interprets its history.
Keep identity and access distinct
An issuer profile identifies the source responsible for a record. A user membership determines which workspace that person can administer. A platform role grants a different scope of responsibility. Combining these concepts into one “user” object makes it harder to reason about business and individual accounts.
Design queries and interfaces around their actual scope. A business reviewer should see the workspace evidence they are authorized to use, while platform administration needs explicit cross-organization authorization.
Apply boundaries at more than the interface
Hiding a navigation item is not an authorization control. Validate the caller and intended scope on the server, and ensure database access follows the same boundary. Queries that work with an administrative connection can still behave differently for the application’s restricted role.
Test the account types the service actually supports. Include a permitted workspace read, a prohibited cross-workspace operation, and the separately authorized platform view. Check real responses rather than assuming that an empty list means there are no records.
Preserve lifecycle context
Keys, profiles, and status change over time. Keep enough information to interpret records issued under earlier conditions. Plan key rotation and historical verification material as part of the storage design, not as a cleanup task after a migration.
Where the system cannot supply a required key or proof, present the limitation. Substituting an unrelated current key would not verify an older signature.
Design operationally useful errors
Distinguish unauthorized access, an absent record, a validation problem, and a service failure. A dependency error should not silently become an empty business dashboard or a successful verification result.
For the public-facing concepts, see issuer registry and governance. Developers connecting a registry to their own application should use the current API documentation and test the customer-event workflow under the correct workspace permissions.