Manager
May read and propose changes to assigned strategy, and read shared approved requirements. Engineering content requires an explicit grant.
Governed access to your enterprise model
Repository MCP lets people and their AI clients work with the parts of a Transitrix model they are allowed to see and change.
Recommended architecture. This is an implementation guide for enterprise teams, not an available Transitrix MCP server or hosted service.
Who can see and change what?
Model Context Protocol (MCP) connects an AI client to model operations. Your application must verify identity and enforce access policy before returning content. A professional title or an assistant mode does not grant access.
Keep four dimensions separate: expertise (what someone can judge), scope (which content they can access), permissions (read, propose, review, approve or administer policy), and assignment (their responsibility for this particular change).
Engineer
May read and propose within assigned data or infrastructure scopes, and read shared approved requirements. Restricted strategy stays closed.
Quality specialist
May read shared requirements and review an assigned change within an authorized scope. That assignment grants neither unrelated access nor approval authority.
These are illustrative grants, not fixed role presets. Deny access without an explicit grant; document how denials take precedence. New or unclassified content stays closed. A model owner grants approval within a defined mandate; an access administrator controls policy. Editing an element does not authorize moving it into a more public scope.
Automated validation checks schemas, references and formal constraints. Expert review assesses meaning, feasibility and completeness. Approval authorizes admission into canon. “Validator” names the expert-review function: a qualified analyst, engineer or quality specialist can perform it. Neither a passing check nor a favorable review admits a change; AI does not inherit approval authority.
One access boundary, one authoritative model
- Employee and approved AI client
- Internal HTTPS / MCP interface
- Verified identity + current access policy
- Model operations on an authorized scope
- Git snapshot + derived SQL index
Git and admitted canon remain authoritative. SQL is a rebuildable index, not a second editable registry. Preserve the difference between admitted canon, unadmitted source material and derived views. Every response identifies its repository, commit, authorized sources, material status, indexing time and actual coverage.
All interfaces must use the same authorization layer. A shared service account never lends its broad Git access to a user. Development-factory control, project dispatch, releases and deployments stay outside Repository MCP.
Choose the repository boundary first
One restricted repository
The simplest starting point when only trusted owners and services need complete Git access. Everyone else uses MCP or another interface enforcing the same policy.
Federated repositories
Choose independent repositories when teams need direct Git access or storage-level isolation. Split along stable access boundaries; authorized relationships and stable identifiers connect the logical model.
A complete Git clone bypasses MCP filtering. Sparse checkout is a convenience, not a security boundary. A federating service that reads every repository is still privileged; stronger isolation can require separate services and credentials. Model size alone does not decide isolation.
Choose a deployment your team can operate
Small: one node + SQLite
An HTTPS proxy, MCP application, local Git snapshot and SQLite index can share one VM or container host. Use one index writer and local storage; do not share the SQLite file across hosts. Enterprise identity and audit still apply.
Larger: PostgreSQL or MySQL
Use a server database for multiple application instances, concurrent work or high availability. A gateway fronts the instances; synchronization publishes completed snapshots, and analysis workers deliver controlled results.
Follow an established enterprise database standard. When none dominates, PostgreSQL is the recommended default for its query facilities and optional row-security defense. MySQL is a valid choice with established operations and tested scope isolation. Application authorization is mandatory with either. Even a small deployment can use an existing managed database.
Move beyond SQLite when measured latency, write contention, indexing time or recovery objectives require it. Rebuild the new index from Git, compare results and permissions, migrate non-derived records separately, and retain a rollback path.
Python or TypeScript? Choose one official MCP SDK and the language your team supports. Python fits existing analysis and document-processing libraries; TypeScript fits Node.js services and web integrations. Both support all three databases. Both need runtime input validation and tested client/protocol versions. Neither language nor database choice confers security.
Start basic; extend only when needed
Basic: describe available scopes and revision, retrieve and search elements, trace bounded relationships, run automated checks, prepare a reviewable proposal and inspect its state. A read-only first deployment can precede proposals. Proposals can be patches; direct default-branch writes are unnecessary.
Extended: impact analysis, revision comparison, federation, assigned expert review, approval requests, diagrams, documents, semantic search and long-running jobs. Discovering an installed extension does not grant permission to use it. Approval requests route to the authoritative approval process.
Mandatory in both: authorization, audit, provenance, revision correctness, pagination, size/depth limits, timeouts and quotas. Do not expose arbitrary SQL, shell commands or filesystem reads.
- Protect relationships and outputs. Authorize the relationship and both endpoints. Filter snippets, history, diagrams, documents and errors before AI receives them. Do not reveal hidden identifiers or automatically summarize restricted sources for another audience. Analysis states its authorized coverage.
- Apply current policy. Isolate caches by effective scope and policy revision. Reauthorize historical reads and delivery of stored or background results. Revocation affects subsequent access even if indexing fails; already downloaded content cannot be recalled. Protected operations fail closed when required authorization is unavailable.
- Keep snapshots consistent. Pin each request to one complete snapshot; federation records every source revision. A failed refresh retains the previous snapshot with an explicit stale/error state. An unavailable source is not an empty result.
- Bind changes to evidence. Record author, scope, base revision, diff and check results. Bind review and approval to the exact revision, recheck conflicts when it changes, and make retries idempotent. Proposal and CI audiences must match the content.
- Plan recovery. Rebuild indexes from Git, but back up authoritative reviews, approvals, audit and other non-derived records separately. Test recovery objectives. Service operation does not grant model approval authority; privileged storage access remains a trust boundary.
Internal hosting alone does not keep data inside the enterprise: an AI client may forward results to a cloud model. Choose approved clients and processing boundaries, protect transport and service credentials, and keep restricted content and tokens out of routine logs.
Before implementation
Agree identity, policy ownership, approved AI clients, the approval system and recovery objectives. Test a manager’s permitted strategy read and an engineer’s denied read; also test search leakage, revoked access, unauthorized approval, failed indexing and index recovery. Each control needs an allowed and a denied scenario.
Use the enterprise Repository MCP reference for implementation details and the full acceptance scenarios. The existing Repository MCP pattern remains the architecture entry point.