Use the Darwinium Assembly Script SDK Marketplace package when a custom scoring model needs logic beyond a rules configuration, such as comparing device measurements against a reference table. It installs helper source and an example model that you can inspect and adapt in the workflow workspace.
For an initial configurable detection model, start with Detection model templates. This package is for developers authoring model logic.
Install and inspect the example
Open Darwinium Marketplace and install Darwinium Assembly Script SDK. The package creates:
| File | Purpose |
|---|---|
src/darwinium/lib/dwnHash.ts |
Hashing helpers |
src/darwinium/lib/dwnLanguage.ts |
Language and phonetic comparisons |
src/darwinium/lib/dwnMatch.ts |
Matching and numeric comparisons |
src/darwinium/lib/dwnScreen.ts |
Screen-size and aspect-ratio reference tables |
src/darwinium/models/screenModel.ts |
Example model entry point |
Keep the helper files with the model: its imports depend on them. Open screenModel.ts in Explorer to review modelMain() and the attributes it reads and writes.
Follow the example's data flow
The model reads screen width and height from browser profiling, falling back to iOS and then Android values. When either dimension is missing or zero, it returns an Ignore result because the assessment is inconclusive.
When dimensions are available, it normalizes them to landscape order and compares the size and aspect ratio with its tables. It writes selected results to:
profiling.device.screen_res_x
profiling.device.screen_res_y
profiling.device.screen_orientation
profiling.device.screen_type
profiling.device.aspect_ratio
The last two depend on matching reference data. It also produces signals such as standard_size, top_ten_size, non_standard_size, standard_aspect_ratio and unusual_aspect_ratio, then combines their weights into a score.
Those weights and reference tables are example policy choices. An unusual screen dimension alone does not establish malicious activity; review them against your supported devices and combine the result with other evidence.
Attach the source model to a journey
Open the journey from Explorer and select the relevant step. Under Workflows → Models, add a code-execution operation. In Path, select the AssemblyScript .ts file. The file picker accepts AssemblyScript alongside rules and PMML files.
For a journey in the workspace root, the model reference is:
models:
- name: screen_assessment
execute_code: src/darwinium/models/screenModel.ts
Adjust the relative path for your journey's location. Set dependencies so profiling is available before execution and consuming operations run after screen_assessment. Save, resolve editor diagnostics, and use the normal journey build and deployment workflow, which handles the model source as part of the configuration.
The Marketplace package supplies helper files and an example; it does not replace the model runtime or automatically attach the example. If imports or runtime symbols are unresolved in an older workspace, resolve its model build configuration before deployment rather than treating the source file as a standalone browser TypeScript program.
Check the score and written attributes
In a test deployment, inspect the model result, signals and normalized screen attributes. Cover a known screen size, the same dimensions in the opposite orientation, a size outside the tables, and missing dimensions.
Check that an Ignore result remains distinguishable from a completed assessment. Review whether downstream logic should use the normalized attributes, the model score, individual signals or a combination. Models & scores explains how these fit into the wider decision workflow.