Determines the project’s overall activation state. When active is selected, the project becomes available to user operations and automatic-run eligibility checks; when passive is selected, automatic data preparation does not start even if the schedule is valid. An automatic run additionally requires the life cycle to be “working” and automatic data update to be “yes”.

Provides the human-readable name used to distinguish the project in lists, the record screen, and process tracking. A descriptive and unique name prevents projects that use the same data source from being confused; an ambiguous name makes operations and error tracking harder.

Determines the source and preparation flow used to build the dataset. Manuel mode expects data to be uploaded or edited by the user; Wtransfer uses the selected database map and main rule; Wisdombase uses platform layer data; MSSQL executes the connections and queries in the SQL list. Changing this selection also changes which dependent parameters are required.

This is the text stored as the "product code" within a project record. The project screen displays this value in a read-only format; the Wanalyzer management code compares this value against the codes in the product list to identify the corresponding pre-configured product project. It is a specific product code assigned to products created by WisdomEra. It is used in scenarios where matching is required during product installations or when it is necessary to verify the existence of a product. For instance, if a product is installed with the product code "123," another instance of the same product can be installed using that same code. This mechanism establishes the relationship between WisdomEra’s pre-configured products and the products actually installed.

Identifies the project’s design and operational stage. Automatic data preparation can become eligible only when “testing” or “working” is selected; no automatic process starts for planning, designing, maintenance initiated, or cancelled. This prevents the scheduler from running projects that are not ready or have been taken out of service.

A free-text field for the project purpose, data source, target users, and operational notes. Sufficient context lets a future maintainer understand why the project exists and which assumptions it uses; leaving it empty does not technically stop execution but makes maintenance and auditing harder.

Selection that classifies the project’s business context and is displayed by label in the project list. The code does not use this field to change the data-preparation query. Backend label conversion defines values 0 through 5.

Specifies the concrete subject within the selected scope type. For example, if the scope type is clinical decision support, the scope may be “readmission risk”. A clear scope distinguishes projects of the same type; this field does not directly change data-preparation behavior.

A list containing one or more connection and query records to execute in MSSQL data-preparation mode. Each item contains an SQL name, server address, username, password, port, and query. If MSSQL mode is selected without a valid SQL item, the data source cannot be reached; when several items exist, the system processes them through the defined list.

The human-readable name of a connection and query item in the SQL list. A descriptive name makes selection and troubleshooting easier when several databases or queries are present; the name does not change query results.

Specifies the network address or resolvable host name of the MSSQL server. With the correct address, the application attempts to connect to the target server; an incorrect or unreachable address causes a connection failure before the query can run.

The database account used to authenticate the MSSQL connection. Data can be prepared when the account has the required read permissions on queried objects; an invalid account or insufficient permissions causes a connection or authorization error. Grant only the permissions required by the principle of least privilege.

The connection password of the MSSQL account, entered through a password field in the interface. The correct password permits authentication; an incorrect password causes authentication to fail. Never place a real password in documentation, screenshots, or query text, and manage it according to the organization’s secret-handling policy.

Specifies the network port on which the MSSQL service listens. When it matches the server configuration, the connection reaches the correct endpoint; a different or closed port prevents connection. Although 1433 is commonly the default MSSQL port, verify the actual value with the infrastructure team.

This is a query executed during MSSQL data preparation that generates the rows for a dataset. When a query is created for the first time—and before any design for the columns to be retrieved has been defined—the columns are generated automatically. If a column with the same name already exists in the project, the data is simply added to that existing column. Only read-only queries should be used for this process, and both the query cost and the number of rows returned must be tested beforehand.

Stores, as JSON, the database maps used in Wtransfer mode and the servers selected for each map. The interface produces this value through the map and server selection dialog; during data preparation, the system iterates through the listed maps and servers. Invalid JSON, deleted identifiers, or an empty selection may prevent the data source from being found, so create the value through the selection interface instead of editing it manually.

More than one database map can be defined in the same project. In this case, the same queries are performed on all selected database maps. This is often used for the polycentric integration model. For example, separate database maps are produced for two hospital information management systems that are in different server locations and have different table structures. Because integration structures and SQL constructs are different from each other. The targeted query contents of the parameters of the layers in these two database maps may be the same. For example, let's assume that it is planned to get gender values ​​from both of them. While gender male is 1 in the HBYS-1 system, gender male may be expressed as 0 in the HBYS-2 system. Additionally, table names and column names may be different. In the wtransfer application in the WisdomEra system, both databases can be imported into the common data query project by using the same query model by creating different database maps.

Identifies the main layer that serves as the starting point of the target population in the Wtransfer data model. The system evaluates the main rule in this layer’s context to find base records before preparing related column data. If the value does not match an actual layer name in the map, rule and data queries cannot be generated from the correct root.

For instance, if the primary layer in a hospital database concerns patients, it is structured so that each individual row represents a single patient. If the primary layer concerns encounters (or visits), then each individual row is structured to represent a single encounter.

Limits the total number of rows that may be added to the dataset in one data-preparation run. When a value greater than zero is entered, the Wtransfer and MSSQL flows reduce query batches according to the remaining allowance and stop fetching new rows at the limit; an empty or inactive value applies no limit. A small value during testing reduces query time and resource consumption.

This is the application identifier that determines which Wanalyzer application node within a WisdomEra installation will handle an automated process. WisdomTimer will only prepare the project configuration and proceed with automated process controls if this value exactly matches the configured identifier of the running application. If the field is left blank or specifies a different application ID, the timer code being evaluated will not execute the project on that particular application node. When a new project is defined in the system, the number of projects already assigned to each application is calculated using this value. The project is then assigned to the Wanalyzer application node with the fewest existing assignments, thereby distributing the workload for project execution.

For example, if high CPU or RAM usage is observed on an existing server node following an initial WisdomEra installation, a second server node with a Wanalyzer application can be added. This additional Wanalyzer application will then begin sharing the project load and taking on tasks. New Wanalyzer nodes can be added via the WamServer application interface.

Enables or disables scheduler evaluation of the project for automatic data preparation. With yes, an automatic process may start when the project is active, its life cycle is testing or working, and its time filters match; with no, no automatic process starts even when every other condition is valid. User-initiated manual preparation remains independent of this setting.

Determines the timing logic that makes automatic data update eligible. Instantaneous is eligible at every scheduler evaluation; minute, hour, and day cycles wait until the time-cycle value has elapsed since the latest process start; specified times during the day is eligible only in selected hours and at most once within the same hour. Month, weekday, and day-of-month filters are applied before every cycle type.

Specifies the numeric interval for minute-, hour-, or day-based cycles. For example, with an hourly cycle and value 6, the project becomes eligible again at least six hours after the latest process start. Interval cycles do not become eligible unless the value is a positive number; instantaneous and specified-hour cycles do not use this field.

Stores the time options for the cycle based on the hours specified for the day. Selecting 24 corresponds to 00:00 (midnight).

Filters the weekdays on which automatic update may run. When the list contains values, the time cycle is evaluated only if the current weekday is selected; when empty, every weekday is accepted. For example, selecting Monday through Friday prevents automatic runs on weekends even when timing and all other conditions match.

Filters the months in which automatic update may run. When the list contains values, other timing conditions are evaluated only if the current month is selected; when empty, every month of the year is accepted. Selecting only relevant months for a seasonal project prevents automatic data preparation outside the season.

For example, the seasonal allergic rhinitis algorithm can be selected for months such as March, April, and May—periods when allergy symptoms tend to intensify.

Filters the calendar days, from 1 through 31, on which automatic update may run. When the list contains values, the time cycle is evaluated only if the current day of the month is selected; when empty, every day of the month is accepted. A selected day such as 29, 30, or 31 cannot trigger a run in a month where that date does not exist.

Determines how automatic data-preparation results are applied to the existing dataset. Delete all and add performs a full refresh; add new rows only preserves existing records; update and add modifies matches and inserts new records; update only changes existing matches. Evaluate it with business requirement.

Determines whether algorithm-based column calculations start automatically after data preparation completes. With yes, algorithm columns are triggered during final data-preparation operations and configured automatic analyses may then be evaluated; with no, the dataset is prepared but algorithm columns must be run separately by the user.

Stores, as JSON, the rule tree that filters target records in the Wtransfer main layer. During data preparation, this rule is sent to the Wtransfer query together with the main layer name; a correct rule returns only the target population, while an incorrect or overly broad rule creates unnecessary data and cost. Build it through the rule editor and do not manually alter layer or parameter identifiers.

Individual rows associated with the primary layer that satisfy the established rule are retrieved into the dataset. For instance, if the request is to retrieve data where the primary layer is "patient" and the age is over 65, each row represents a unique patient. Conversely, if the request is to retrieve data where the primary layer is "encounter" (or "application") and the age is over 65, then multiple encounters for the same patient—provided they are over 65—will be included; in this case, each row represents a unique encounter.

Stores the source project client identifier when a project is created by copying another project. It provides traceability to the project from which the copy was produced and is displayed as a read-only source reference; when empty, the project may not have been created through copying. Because the system writes this identifier, it should not be changed manually.

This is the status value in the column record. The active mode is managed automatically by the system; no user adjustment is required.

The client identifier of the Wanalyzer project to which the column belongs. When it points to the correct project, the column is loaded and saved in that project’s column list; an incorrect identifier may associate the column with another project or make it unavailable. The system should manage this value while creating the relation, and it should not be edited manually.

The name displayed in dataset headers and design screens. A descriptive and unique name makes the correct column easy to select in rules and mappings; duplicate or ambiguous names make index-based relationships especially difficult to maintain.

Explains the column’s meaning, unit, source, and calculation assumptions. A sufficient note helps users interpret the generated value correctly; an empty or outdated note does not stop technical execution but may cause the analytical result to be misunderstood.

This is an integer representing the column's position in the list. Since the root column, NLP analysis column, machine learning fields, and API fields rely on column indices, these index-based mappings must be verified following any reordering.

The value is managed by the system and cannot be modified manually.

Determines whether the column value comes from a database or is produced inside Wanalyzer. With manuel, the value is created through user entry, rules and functions, machine learning, natural-language processing, or an algorithm application programming interface; with database, Wtransfer field data is fetched through the layer rule. An incorrect selection prevents the intended configuration group from being used.

Determines the data type of column values and how they are edited in the interface. With the correct type, rule comparisons, numeric operations, options, and date evaluations work appropriately; a type incompatible with the source value may cause conversion or analysis errors.

Determines whether an option-based database column writes the raw option value or the user-facing label to the dataset. Value preserves the integration code; label uses the readable caption. Select value when algorithms expect codes and label when the result is intended for human-readable reporting.

For instance, in API integrations, it may be necessary to send an ID value rather than a label for a given piece of data. In such cases, the value—that is, the ID—can be used. Data from a "gender" column can be written into a cell in two ways: either as the term "Male," or, if the ID for the "Male" label is 1, then that value (1) can be used instead. If specified as a header/label, the cell will display "Male."

Determines whether values ​​should be treated as a numerical summary or as a selection of text-based records when multiple database entries are retrieved. If "numeric" is selected, operations such as average, median, maximum, minimum, or sum are applied; if "text" is selected, the system uses an approach based on the oldest, most recent, or all available records.

This setting defines how data should be handled, regardless of whether the underlying database data is numerical or textual. For example, if a laboratory value—which is numerical in nature—is retrieved in a text format, it is presented as a list within the target cell, without any calculations like averages being performed. If "numeric" is selected, a specific calculation model must then be chosen. The numeric mode is typically used in cases where a single cell contains multiple data entries.

- If a single row contains multiple blood sugar values ​​and you intend to calculate their average and record the result in the cell, you can use the numeric mode.

- If you prefer to have all blood sugar values ​​listed in the cell—along with their corresponding dates—you should select the text format.

Determines which summary is written into one cell for a numeric column with multiple records.

For example, mean produces the arithmetic average of valid values and maximum produces the largest value.

Determines which historical record is used for textual data with multiple records. Oldest or most recent produces one record. Without date information, ordering may remain dependent on the source order.

Determines how to handle repeated identical values ​​within multiple records. A selection that is unique and excludes dates removes duplicates. A selection that allows duplicates while including dates preserves every occurrence, even if the same value appears across different events. Preserving duplicates is necessary if frequency or temporal analysis is to be performed.

For example, in a project where the primary entity is the patient, one might plan to list all diabetes diagnoses associated with a patient in a single column. There are two possible approaches here: if the specific dates are not significant, there is no need for the same diagnosis code to appear multiple times in a cell. In this case, the option to retrieve unique values ​​(excluding dates) is used.

Conversely, if it is necessary to retain the same values ​​along with their respective dates, the option to retrieve duplicate values ​​(including dates) should be selected. For instance, if one wishes to calculate a diagnosis value from an ICD column based on a date range found in another column, the option to retrieve duplicate values ​​(including dates) would be specified.

Determines which engine produces the value of a manually sourced column. Depending on the selection, direct entry, rules and functions, machine-learning mappings, a natural-language processing phrase definition, or algorithm application programming interface settings are used.

Specifies whether a database column is derived from the related sub-records of another database column.

For example, consider a column that retrieves a patient's first internal medicine encounter in the system. If we want to pull the list of diagnosis codes associated with this encounter into another column, the "first internal medicine encounter" column is selected as the root column for the "encounter-related diagnosis codes" column.

This is the index of the parent column that should be processed first when the root-related column status is enabled. The code uses this relationship to determine the execution order of database columns and to identify the related field ID; an incorrect or reordered index may result in a connection to the wrong column or cause a preparation error.

This value cannot be edited manually. It is assigned automatically upon selection from the column list.

The rule object defining the Wtransfer layer, parameter, and filter conditions for a database column. A valid rule is added to the field query algorithm; without it, no field algorithm can be produced for the database column. Create it through the rule editor and do not manually alter the JSON or identifiers.

This is a field in a column record that contains an image in base64 format. It represents the column itself. In WAI algorithms, it can be used as an image displayed next to the column whenever the column is shown on screen. It is not frequently used in routine data analytics.

Holds one or more conditional function definitions for a manual column generated via rules and functions. Each item contains both the function code and the rule under which that code should execute; if the code references other columns, the system automatically determines the order of dependencies. Missing or circular dependencies may prevent the calculation from being performed.

The code or predefined function expression that generates a column value when the corresponding rule in the function list is satisfied. References such as col1 and col2 in the code ensure that other manual columns are calculated first; invalid column references or unsupported code expressions may cause errors.

Function code syntax rules:

The JSON rule that determines on which rows a function code runs. A correct rule applies the function to matching rows; an incorrect or empty condition may produce values on unintended rows or produce no value. The rule editor creates the query list and compilation arrays together.

The client identifier of the record selected from the user application programming interface layer for the algorithm API method. With a valid identifier, the backend loads the application programming interface name and executable code; if the record is deleted or the identifier is incorrect, the configuration cannot be resolved and the column cannot be calculated.

The instruction or context text sent to the algorithm application programming interface in the algo_message field together with row data. A clear message lets the target algorithm interpret rows for the intended purpose; an ambiguous message may produce inconsistent or semantically incorrect results from the same input.

The JSON rule object that determines which dataset rows run the algorithm application programming interface column. A row is prepared for the API operation when it satisfies the rule; otherwise no unnecessary call is made. This allows expensive algorithms to run only for the target records.

Text stored as the algorithm operation identifier in the column record. ProjectConfig reads it and ColumnManager saves it, but no other inspected Wanalyzer backend usage starts an operation, associates a result, or performs tracking with this value. It must therefore be treated as a transported configuration field whose operational effect is not verified in the current code.

Specifies whether the column is marked as Wisdom Artificial Intelligence input in a cell-calculation request. With yes, the column configuration is sent with wai_input=1; with no, it is not assigned an input role. Marking only necessary columns as inputs keeps context and cost controlled.

Specifies whether the column is a target output in Wisdom Artificial Intelligence cell calculation. With yes, the configuration is sent with wai_output=1 and the generated result is understood to belong to this column; with no, no output role is assigned. Incorrect input and output roles make the calculation contract ambiguous.

Contains the allowed values of a categorical column together with each value, label, and optional rule. The technical value is used for data mapping, the label for display, and an option rule can produce the value according to row conditions. Repeating the same technical value creates ambiguous mapping.

The option’s technical value used in datasets and integrations. Keeping it stable allows historical records to continue representing the same category; changing it later may prevent old values from matching the new option. Use parameter 29 for user-facing text.

The human-readable name displayed to users for the option. Changing the label updates presentation while preserving the technical option identifier; therefore it should contain descriptive, translatable text rather than an integration code.

The JSON rule that determines under which row condition an option is assigned in a manual categorical column. When the condition matches, the option can become the column value; if several option rules overlap on the same row, the design may become ambiguous. Test rules together for priority and mutual exclusivity.

The client identifier of the user-specific or global phrase definition selected for the natural-language processing method. When the identifier and natural-language processing layer type point to the correct record together, phrase options are loaded; a mismatched layer type or deleted record prevents analysis preparation.

The zero-based index of the source text column read by the natural-language processing model. The indexed column is calculated first and supplies its text to the natural-language processing engine; an incorrect index may analyze a different text or cause a type mismatch. Recheck the mapping whenever column order changes.

The identifier of the trained machine-learning model that predicts the manual column value. With a valid model, mapped columns become model inputs; an incorrect, deleted, or project-incompatible model may prevent prediction or produce meaningless results.

The list that maps model training variables to current project columns. Each item contains the variable name, selected column index, and categorical option conversion when needed; when every required input is mapped, the model receives the data layout it expects. Missing or incorrect mappings damage prediction quality or execution.

The name of an input variable used during model training. When it exactly matches the model schema, the selected project column is bound to the correct input; a spelling or semantic difference may cause the input to be interpreted incorrectly.

The zero-based index of the project column supplying data to the machine-learning variable. The code also uses this dependency to order manual-column execution; an incorrect index makes the model receive data from a different column.

The JSON list mapping training group values of categorical model inputs to the current options of a project column. For example, the female value represented by 0 during training can be connected to the project’s woman option; without mapping, category codes may represent different meanings.

Determines whether the natural-language processing phrase identifier is resolved in the user-specific phrase layer or the global phrase layer. User queries user phrase records and global queries system-wide records; the wrong type prevents the selected identifier from being found.

The list mapping variable names used in an algorithm application programming interface request to project column indexes. Each row’s column value is added to API data under the defined key; when a mapping is missing, the target application programming interface does not receive the expected field. The same list is also used to prepare customer rows for Wdigitalchannel integration.

The key name of a field sent to the target algorithm application programming interface. When it matches the application programming interface contract, the value reaches the correct parameter; with a different name, the request may be sent successfully while the target code cannot find the field.

The index of the project column supplying the application programming interface variable. During algorithm execution, the value from this column in the current row is bound to the key name; an incorrect index sends the wrong data to the external service.

Stores the user-facing name of the selected natural-language processing phrase record. The identifier is used for technical resolution while the name makes the selected phrase understandable in the design screen; when the identifier changes, update the name from the same record.

Determines whether the algorithm application programming interface result is used as a Wdigitalchannel campaign-customer transfer instead of a standard column result. With yes, customer rows are prepared from mapped application programming interface variables and sent to the Wdigitalchannel service with the campaign identifier; with no, the normal algorithm application programming interface flow is used.

The user-facing name of the selected Wdigitalchannel campaign. It lets the operator verify the intended campaign; because service routing uses the campaign identifier, the name alone is not sufficient.

The technical identifier of the Wdigitalchannel campaign that receives customer rows. When the Wdigitalchannel application programming interface is enabled, the correct identifier is sent as the campaign_id query parameter; an incorrect or empty identifier prevents customers from being recorded in the intended campaign.

Identifies the process lifecycle state. Continue allows data-preparation, manual-column, and algorithm flows to resume from saved progress; cancel causes execution to stop at control points; complete indicates normal completion. The active-process service treats continue records as running work.

Client identifier connecting the process record to its Wanalyzer project. With the correct identifier, process lists, active-process checks, and latest-process configuration resolve the intended project; an incorrect identifier may associate the process with another project or make it untraceable.

Classifies which Wanalyzer job the record tracks. Scheduler and resume code route data preparation, algorithm triggering, and manual data preprocessing to different worker flows; operations such as column recording, Excel upload, and project copying also create process records under their own types for tracking.

Carries through the process how prepared data is applied to the existing dataset. Delete and add represents a full refresh, add only preserves current data, update and add performs an upsert, and update only changes matching records. Value 4 — calculate total count exists in the layer options, but current ProjectConfig label conversion recognizes only values 0 through 3, so value 4 is not resolved in labeled configuration.

Timestamp recorded when the process is first created. Interval-based automatic scheduling adds the configured duration to this date from the latest process to calculate the next eligible time; an invalid or unparseable date causes automatic eligibility calculation to fail.

Records the time at which a process completes. Start and end together support examination of duration and normal completion; the field may remain empty while a process is continuing.

Stores the time of a cancellation or stop action. It is read for operational tracking and can be written by the edit service; the inspected execution code decides whether to continue from the cancel status rather than from this timestamp.

Progress value storing the processed row position in the data source. The MSSQL flow updates offset after each successful part and a continuing process can resume the next query from that position; moving it backward may cause the same source rows to be processed again.

Field retained in the process record to carry location progress for Wtransfer data preparation. It is preserved during process updates; an incorrect location may resume a multi-map or multi-location flow from the wrong point. MSSQL code saves the field but updates active row progress primarily through parameter 7, offset.

Stores the server position being resumed in the Wtransfer flow. When a map contains several servers, the value carries which server stage the process has reached; an incorrect server position may repeat or skip sources.

Cumulative counter of new or processed rows during the process. MSSQL data preparation writes the total added-row count, Excel upload records the uploaded data-frame row count, and algorithm and manual-column processes update the value as a progress counter.

Stores the number of dataset parts in the project. Algorithm and manual-column operations iterate dataset parts from 1 through this count and mark completion when the current part reaches it; Excel download uses the same counter to visit every part. A value that is too low skips parts, while a value that is too high causes attempts to access nonexistent parts.

Selection carrying whether external algorithm application programming interface steps may be triggered while algorithm columns run. AlgorithmColumns permits API execution when this value is yes. However, ProjectConfig value mode mistakenly reads parameter 3, data update mode, instead of parameter 12; labeled mode correctly reads parameter 12. Therefore, flows using value mode must not assume this selection is resolved correctly until the code is fixed.

Identifies the dataset part at which an algorithm or manual-column process stopped. When a continuing process restarts, code uses this value as the starting part and updates progress after each part. An incorrect value may reprocess earlier parts or skip remaining parts.

Stores descriptive, error, or progress text associated with the process. Data-preparation updates preserve it and the process-edit screen displays it; it does not replace structured counters and instead provides diagnostic context.

Counter of rows whose algorithm evaluation result is positive. AlgorithmColumns increments it for every record with a true rule result; interpret it together with parameter 16, the negative counter, in the context of total evaluations.

Counter of rows whose algorithm evaluation result is negative. Records with a false rule result increase this count; if positive plus negative does not match the expected number of evaluated rows, missing or failed records require investigation.

Counter of algorithm application programming interface or Wdigitalchannel calls recorded as successful. It increments after a successful service response; because only positive algorithm results can produce rows eligible for an API call, interpret it together with the positive counter.

Counter of algorithm application programming interface or Wdigitalchannel calls recorded as unsuccessful. A service error code, unsuccessful response, or error state from executed application programming interface code may increment it; inspect the log and process report for the detailed cause.

Stores the number of relevant project columns when a process starts or its progress record is updated. MSSQL data preparation writes the current column-list length, Excel upload records the number of generated columns, and algorithm and manual-column processes carry this value in progress reporting.

Timestamp of the latest progress-record update from the process. The active-process service reads it to report the latest heartbeat of a continuing record, and worker flows update it while processing parts. A timestamp that remains unchanged for a long time is an operational sign that the process may be stuck, but it does not by itself cancel the process.

Stores triggered algorithm-column identifiers as comma-separated text; ProjectConfig splits the text into a list when reading it. The record supports tracking which algorithm columns were handled in the process. Commas inside identifiers would break list parsing.

Date carried into later algorithm, manual-column, Excel-upload, or copy processes to represent the project’s latest data preparation. New process records may preserve the previous process value, helping identify which prepared-data version an analysis is based on; it is not the same as process start date.

Selection carrying whether final operations run after data preparation. Wtransfer and MSSQL gate last_operations calls with this value; final work may include saving column information and, according to project settings, triggering algorithm columns and automatic analyses. However, current ProjectConfig mistakenly reads parameter 3, data update mode, instead of parameter 23 in both value and labeled modes; the parsed configuration must not be trusted until the code is corrected.

Carries the total amount of data in the source query or preparation scope in the process record. Wtransfer and MSSQL process updates save the value; new row count represents only the added or processed amount, while this field reports the total source size. Depending on the process type, the value may remain empty.

Stores the status selection of a dataset part. The inspected manual dataset update, Excel upload, Wtransfer, and MSSQL record-creation flows write 1 — active directly instead of taking a user selection. The dataset-by-number read service fetches the record by client identifier and does not filter by status; therefore, current code does not guarantee that 0 — passive removes a part from reading or calculation.

Client identifier connecting the dataset part to its owning Wanalyzer project. The dataset record client identifier is generated in the form `project_id_dataset_no` by combining the project identifier and dataset sequence number; with the correct project identifier, the by-number read service finds the correct part, while an incorrect identifier produces a different client identifier and may make the part unavailable or write it under another project context.

Row count or progress counter associated with the dataset part. Manual dataset update, Excel upload, and MSSQL creation code writes the length of `dataset_json.rows` to this field. Current Wtransfer creation code writes cumulative `last_row_no` instead of part length in some records; therefore, for Wtransfer-produced records, compare this field with `rows.length` inside `dataset json` before treating it as the number of rows in the part.

Stores the actual dataset-part content as JSON text. The top-level `rows` array contains cell objects in project-column order for each row, while the `row_info` array contains tracking information at matching indexes, such as row number, source record identifier, client identifier, map identifier, and server identifier. Some producers also add `cd` or `updated_at` timestamps. If `rows` and `row_info` order diverges, the interface, Excel export, and cell calculation may combine values with incorrect row metadata; when a row has fewer cells than the project column count, DatasetProcess appends empty objects, but it does not truncate extra cells.