Generate a starting detection model tailored to your mapped attributes and event types. Marketplace model packages ask configuration questions and create editable rules, and in some cases features, in your workspace. You then attach those files to the steps where they should run.
Use these after collection and event mapping are working. A generated model cannot assess a signal that your integration never supplies.
Choose a model
| Package | Purpose | Files it generates |
|---|---|---|
| Account Takeover (ATO) | Build trust from authenticated activity and identify suspicious account changes | Features and rules |
| Bot | Assess automation indicators and short-term activity patterns | Features and rules |
| Mobile General | Assess mobile SDK forensic attributes | Rules |
| Web General | Assess browser profiling integrity, automation, connection origin and mouse behavior | Rules |
Example: generate a Web General model
In Workflows → Darwinium Marketplace, select Install for Darwinium Model – Web General. The configuration panel asks:
| Setting | Example | What to choose |
|---|---|---|
| Model Name | webgeneralcustomer_web_review |
A unique name for the generated output |
| Account Identifier Attribute | identity['ACCOUNT'].customer_token.customer_token |
The identifier your integration actually maps |
| Expected Countries | Your normal country set, or empty | Empty disables this model's expected-country rule |
Select Complete Installation and inspect the output in Explorer. Open the generated .rules file to review its conditions, weights and signals. In the walkthrough, this produced webgeneralcustomer_web_review.rules. Use the filename reported by your installed package.
Attach the generated output to a step
Open the intended .journey.yaml file from Explorer and select the step that should be assessed. Under Workflows → Models, add a code-execution operation and select the generated .rules file in Path. Give the operation a unique name and set dependencies on the mappings and profiling data it reads.
The underlying journey entry looks like this, with the path replaced by your generated filename:
models:
- name: web_assessment
execute_code: webgeneralcustomer_web_review.rules
For ATO or Bot, also add the generated .feature.yaml file as a feature-generation operation. Make the rules operation depend on that feature operation as well as any other required input stages. See Create features, Models & scores and Dependencies & execution order.
Add the model result to your decision strategy. Attaching a scoring model does not automatically define which score should trigger a block, challenge or review.
Answer the ATO and Bot questions carefully
ATO asks for authenticated event types and suspect event types. Choose events that represent the actual outcome: a successful login can establish an authenticated association; a generic login attempt may include failures. Review the days/events-to-ignore settings for your intended trust-building behavior, expected countries and whether browser or mobile SDK inputs apply.
Bot asks which event types and keyboard contexts to assess, along with browser/mobile options and feature naming. Match these to your mapped event types and profiling contexts. A LOGIN keyboard context in the generator cannot consume data recorded only under another context.
Mobile General asks for the account identifier, keyboard contexts, naming convention and expected countries. Review the generated conditions against the SDK data your supported app versions send.
Validate with representative events
Build and deploy to a test target. Exercise a flow with the expected input data and inspect the model's score and triggered signals in Investigations. Also examine missing profiling, a new account and ordinary repeat activity so you understand the model's behavior before connecting an enforcement action.
For feature-based models, include enough representative history to evaluate the intended behavior; one event cannot demonstrate a long-term association. Adjust conditions and thresholds through your normal review process.
Generation removes its temporary installer inputs. The catalogue may therefore continue to show Install even though output files exist. Check Explorer before rerunning, and use a new model name when comparing configurations so you do not replace an edited model.