Repository Implementation

This page lists every step of putting the Rule Repository (RR), Audit and the MCP server into a web application, in the order that works best, with a link to the page that explains each step. Use it to plan the work, to hand it to a team, or to give it to an AI coding agent as its task list. Steps marked (optional) depend on which features you offer.

Estimated Time to Production

Referencing the libraries and scripts, running the database scripts and creating the database logins, setting up the endpoint, the configuration and its security, and setting up Audit and rule evaluation in your production code typically takes:

• A junior .NET developer: 3 to 4 days, plus 1 to 2 days of testing.
• An AI coding agent: 1 to 2 hours, plus 1 to 2 days of testing. Give it this page as its task list; the facts at the end are written for it.

The figures assume an existing ASP.NET application with its source objects already in place and a deployment process that works. They do not include deciding your roles and permissions, your organization's approvals, or writing the rules themselves. They are typical, not a commitment. A stand-alone implementation of the Rule Editor and the Rule Engine that builds its own rule storage, versioning and testing usually takes a team of two or three developers 2 to 4 months; see Code Effects Implementation.

1. Decide the Shape

• Choose the host. A new ASP.NET Core application created for the repository, or an existing web application (ASP.NET Core, or ASP.NET on .NET Framework 4.7.2 or later for RR and Audit). The MCP server needs ASP.NET Core on .NET 8 or later. See Rule Repository, Audit and the MCP Server.
• Choose the database: SQL Server 2012+ or PostgreSQL 14+. See The Database.
• Decide which applications do what. Usually: one web application hosts RR (and the MCP server); your production applications load live rules and evaluate them, recording through Audit. All of them share one database.
• List your roles and what each may do in RR. See Permissions.
• Decide on the AI features (optional): in-app AI (Assistant and AI Rule Editor), the MCP server for outside AI clients, both or neither. See AI Assistant vs the MCP Server.

2. Secure the Host First

• Sign-in through your identity provider, required on every RR page and endpoint.
• HTTPS only, HSTS in production.
• An authorization policy for who may open RR at all.
• No CORS policy that allows credentials on the RR endpoint.
• A secret store for the connection string and AI keys.

See Security.

3. Create the Database

• Download the scripts for your database type from the Code Effects Portal.
• Create an empty database to your standards.
• Run 00001.Database.sql with a deployment account.
• Create an application account with only SELECT, INSERT, UPDATE and DELETE on the repository's tables.
• Store the application's connection string in your secret store.

See The Database.

4. Add the Packages

• CodeEffects.Rule.Repository and CodeEffects.Rule.Connection.SqlServer or CodeEffects.Rule.Connection.Postgres in the host (they bring CodeEffects.Rule.Common, CodeEffects.Rule.Editor, CodeEffects.Rule.Engine and CodeEffects.Rule.Connection).
• CodeEffects.Rule.Audit in every application that evaluates live rules and records them (optional).
• CodeEffects.Rule.Mcp in the ASP.NET Core application that serves AI clients (optional).
• The browser files of the @codeeffects/editor and @codeeffects/repository packages in the host's static files.
• The assembly that holds your source object classes, referenced by the host.

5. Wire the Server

• Register one database provider for the application. See Connecting to the Database.
• At startup, call Context.CheckDatabase (and AuditRecorder.CheckDatabase if you use Audit) and stop or log when the database is behind.
• Write a configuration factory that builds a Configuration per request from the signed-in user: CurrentUserId, CurrentUserName, AccessMode, ActionList. See The Configuration and Users and the Acting User.
• Unit-test every role's permission set with Context.ValidatePermissions.
• Map the one POST endpoint that calls Context.GetResponse: sign-in required, JSON only, a body-size limit, and both exception types caught, logged and answered with their ResponseJson. See The Server Endpoint.

6. Put the Source Objects In

• Decide how your source objects reach RR: .NET types, Source XML documents, Adaptive Source providers, or a mix.
• Call Context.SyncSources at startup or as a deployment step, and log its result.
• Decide whether new source versions go live on their own (NewVersionsGoLive) or wait for a person.
• Run Context.Reindex when the synchronization reports source objects to reindex (after upgrades).

See Source Sync and Versioning.

7. Build the Page

• A page with an empty element, the four stylesheets and the two module scripts.
• A small script that calls $repo.init with the element's ID and a requestCallback posting to your endpoint.
• Theme and fonts to match your site. See CSS Styles.

See The Client.

8. Connect It to Your Processes

• A notification handler that emails or messages approvers and owners when approval is requested or a version goes live (optional). See Notifications.
• A translated user interface text document for each language you need (optional). See User Interface Text and Themes.
• Your production code loading live rules through AuditRecorder.GetRules (recorded) or Context.GetRules (not recorded), and reloading them when they change. See Live Versions and Approvals.

9. Add Audit (optional)

• One AuditRecorder per production application, created at startup and disposed of at shutdown.
• Rules loaded through the recorder and evaluated with it attached.
• Settings for what is recorded (values, analytics fields) and the local journal's folder.
• Monitoring through OnProblem.

See Audit, Recording Evaluations and Audit Settings.

10. Add the AI Features (optional)

• In-app AI: AssistantSettings with one or more models and their API keys, and permissions 110 and 111 for the users who should have them. See AI Assistant and AI Rule Editor.
• Agent limits in AgentSettings. See AI Agents.
• MCP server: AddCodeEffectsMcp, WithRepository / WithAudit, MapCodeEffectsMcp behind your OAuth, and MapCaller mapping a signed-in caller to a user and permissions. See Setting Up the Server and Authentication and the Caller.
• Instructions for your users on connecting their AI clients. See Connecting Users to Your MCP Server.

11. Before Production

• Every role signs in and sees what it should; a refused action is logged as a warning.
• A rule created, tested, approved and made live end to end; production code evaluates it.
• Backups and retention set for the database, including recorded evaluations.
• Your security reviewer has gone through the host's duties on the Security page.
• Business users have the Rule Repository Guide.

12. With Every New Release

• Read the release notes; download any new update scripts.
• Back up, run the update scripts in number order, check the Schema. rows. See Updating the Database.
• Update the packages and the browser files together (the browser files and the server library of one release belong together).
• Run Context.SyncSources (it reports source objects that need Context.Reindex after an upgrade).
• Review new permissions if you use AllowAllExcept: it grants new permissions unless you list them.

Facts for AI Coding Agents

If you are an AI agent implementing this, these facts prevent the most common mistakes:

• Context is a static class. There is no repository object to construct or register; register only the IDbProvider (once) and your configuration factory.
• Build a new Configuration per request. Take CurrentUserId from the authenticated principal, never from the request body, a header or a query string.
• AccessMode defaults to ViewOnly: a configuration that sets nothing can change nothing.
• The endpoint returns the string from Context.GetResponse unchanged, with content type application/json. Read the request body as a raw string; do not model-bind it. Catch RepositoryPermissionException before RepositoryException, and return ResponseJson from both with status 200.
• The libraries never create or alter the database. Run 00001.Database.sql (and later numbered scripts) yourself; Context.CheckDatabase only checks.
• Context.SyncSources is the only way source objects enter RR. Users cannot create them. Call it before anyone writes a rule.
• The browser needs both script files (codeeffects.editor.js and codeeffects.repository.js, in any order, both type="module") and both packages' stylesheets. $repo is not a global: read CodeEffects.Rule.Repository or import $repo.
• AI agents and services never make versions live, approve or delete, whatever permissions you grant; their saves always request approval.
• The MCP server requires ASP.NET Core on .NET 8+ and the host's own OAuth; it takes no credential in its tools.

Related

• Rule Repository, Audit and the MCP Server
• Rule Repository Guide
• CodeEffects.Rule.Repository namespace