Skip to main content
Version: 2.12.X

Scaling Models

Scaling a model is the process of changing its size, scope, or reach while preserving its overall logic and functionality.

This section outlines strategies for scaling models. It also discusses approaches for working on a model as a team, both simultaneously and asynchronously.

Planning How to Scale​

The first step to scaling is to ensure that you have a viable proof-of-concept (POC) model that you have already used to test an idea. If the model works, and you wish to expand on its core idea to include additional variables, patterns, and rules, then it is time to consider how to scale the model.

Depending on your project, you might consider one of two approaches:

These approaches are examined in greater detail under the corresponding topic headings.

Expanding Existing Projects​

Continuing to work within the same project is advisable if:

  • Your model's patterns take many inputs from multiple other pattern outputs.
  • Your model's patterns output to many other patterns.
  • Your model contains many relationships between patterns.

Working within the same project reduces the number of event types and schemas that must be copied and kept in sync with other projects.

Use tags to create logical separations between groups of patterns, even if they are highly linked to one another, to help navigate and manage a growing project.

Creating Adjacent Projects​

Creating new, adjacent projects is the recommended approach if your project meets the following criteria:

  • There is logical separation between the models.
  • There are minimal shared topics or event types across the projects.
  • There are minimal dependencies between projects.

As a rule of thumb, the fewer the shared resources that need to be kept in sync, the more advantageous it is to create separate projects.

Creating new sister projects carries the following benefits:

  • It reduces loading times within a project, thus improving maneuverability.
  • It encourages specialized feedback and collaboration from different specialized groups or subject matter experts (SMEs).

Example

Suppose you started with a POC model for bank fraud. You already demonstrated that you can compute risk reasonably with three different fraud types (such as money laundering, counterfeiting, and identity theft).

You have started modeling each of these fraud types in its most simplistic form. Now you have decided to expand on each of these fraud types to make them more detailed, accurate, and complex by adding additional rules and dimensions.

In this case, it might be reasonable to start a project that exclusively detects money laundering, another to detect only counterfeiting, and another for identity theft. The original project that computes a bank’s risk will take high level results from each of the projects, combine them and compute an overall risk.

Money laundering SMEs can be directed to the money laundering project, and experts for all other fraud types can be directed to the project on their specialty without the unneeded cognitive load from an otherwise giant project with lots of patterns that are irrelevant to their expertise.

When working with adjacent projects, remain mindful of the following:

  • Make sure any topics or schemas shared with other projects are kept in sync. At the moment, this must be done manually.

Working as a Team​

Cogynt Authoring supports both simultaneous and asynchronous multi-user collaboration.

Working Simultaneously​

Multiple users can open the same project in Cogynt Authoring without fear of overwriting one another's work.

Authoring prevents accidental overwriting by locking objects when they are in use. When a lock is acquired, no other user can make changes to the locked object until the object is released. Locks are acquired when:

  • A user clicks an object's Edit button (i.e., an event type, a deployment, a user data schema, and so on).
  • A user opens a graphical view (i.e., the hierarchical project view, the pattern view, the computation view, and so on).

With this in mind, the key to working simultaneously is to plan which elements of the model each team member will work on in advance. This way, the team can continue developing the model without trying to work around one another's locks.

Working Asynchronously​

Users can open the same model at different times to continue working on it. This can be useful for geographically dispersed teams in different time zones.

The main obstacle when working asynchronously is ensuring that the work one user performs is intelligible to another. That way, other users can pick up where the original user left off. The easiest way to facilitate this is to provide descriptive names when adding new content to a pattern.