Reglas avanzadas

Más allá de los ajustes por campo, un tipo de muestreo puede llevar tres clases de reglas a nivel de registro. Se editan en el panel Reglas avanzadas al final del generador y se validan al guardar, así que una regla mal formada nunca se almacena. Cada sección tiene por defecto un editor visual, y un botón Editar como JSON para la forma exacta o para el caso raro que el editor visual no cubre.

Comprobaciones de validación

Una comprobación es una regla sobre todo el registro: una comparación entre dos valores, donde cada valor es un campo, un número, o un agregado sobre un grupo repetible (la suma de un subcampo, o el número de entradas). La comprobación se cumple cuando la comparación es verdadera; de lo contrario el registro recibe su mensaje, como error o advertencia.

En el editor visual cada comprobación se lee de izquierda a derecha: elija un valor, una comparación (=, distinto, como máximo, menor que, al menos, mayor que) y otro valor, luego escriba un mensaje en lenguaje claro y elija Error (bloquea el guardado) o Advertencia (solo señala). Las listas de campos vienen de los campos del muestreo, y «comparar con otro campo» está al mismo nivel que «comparar con un número».

Use las comprobaciones para lo que un solo campo no puede expresar:

Un grupo repetible debe sumar un número fijo (por ejemplo, un conjunto de conteos debe sumar 20).
Un campo debe ser menor o igual que otro (un inicio en o antes de un final).
Un conteo debe estar dentro de límites.

La misma regla, mostrada por el botón Editar como JSON:

[
  {
    "key": "counts_total",
    "message": { "en": "The counts must total 20.", "es": "Los conteos deben sumar 20." },
    "left": { "sum": { "repeat": "rows", "field": "count" } },
    "op": "eq",
    "right": { "const": 20 }
  }
]

Una comprobación cuyos valores aún no se pueden resolver (un campo está vacío) se omite, así que los datos incompletos nunca fallan. La vista JSON también expone una condición when (evaluar una comprobación solo en ciertos casos) y un field (para adjuntar el mensaje a un campo).

Una regla que no debe ocurrir

Además de comparar dos valores, una comprobación puede fallar cuando se cumple una condición, que es la forma de expresar una regla del tipo «estas dos cosas no pueden ser ambas verdaderas» que una comparación no puede. Por ejemplo, un espécimen puede conservar una muestra de estructura de edad o llevar una etiqueta, pero no ambas.

Esta forma de «prohibición» se escribe con el botón Editar como JSON (el editor visual cubre las comparaciones). Se ve así:

[
  {
    "key": "structure_or_tag",
    "message": { "en": "A specimen keeps its structure sample or carries a tag, never both.", "es": "Un espécimen conserva su muestra de estructura o lleva una etiqueta, nunca ambas." },
    "failWhen": {
      "all": [
        { "field": "structure_no", "op": "not_empty" },
        { "field": "tag_no", "op": "not_empty" }
      ]
    }
  }
]

La comprobación falla cuando se cumplen todas las partes de failWhen. Ajuste severity a error o warning como en cualquier comprobación.

Cuando una comprobación suma o cuenta sobre un grupo repetible, el subcampo que nombra se verifica al guardar, de modo que un error tipográfico en el campo sumado se detecta en ese momento en lugar de convertirse en una regla que nunca se activa en silencio.

Campos calculados

Un campo calculado lo rellena el motor a partir de otros campos en lugar de escribirse. Es de solo lectura en el formulario y se almacena con el registro, así que los informes, la exportación y las comprobaciones ven el valor.

En el editor visual elija un campo numérico para hacerlo calculado, luego construya su valor eligiendo una función: un campo, un número, un total o un conteo sobre una lista, una duración entre dos campos de hora, o una fórmula (a +−×÷ b, donde cada lado es a su vez una expresión). Las listas se filtran a los campos compatibles: una duración solo ofrece campos de fecha u hora, y un total solo subcampos numéricos.

La misma expresión como JSON (la clave es la de un campo existente; ese campo pasa a ser calculado):

{ "soak_hours": { "duration": { "from": "set_at", "to": "haul_at", "unit": "hours" } } }

Un valor calculado se actualiza en vivo a medida que rellena los campos de los que depende.

Planes de submuestreo

Un plan de submuestreo decide qué registros seleccionar para muestreo adicional, a una tasa que puede variar por grupo (zona, temporada, especie, clase de tamaño). Es algo que la mayoría de las herramientas de campo no pueden hacer, porque necesita un conteo en marcha entre registros, que CensusIO mantiene incluso sin conexión.

En el editor visual agregue un plan, póngale un nombre y elija un Método: cada N registros (sistemático), una probabilidad aleatoria por registro (muestra aleatoria), una cuota por grupo (conteo fijo), todos los registros (cada unidad), o tomar lo que se pueda (oportunista). El campo de tasa se adapta al método (un porcentaje, un intervalo 1 de N, o una cuota por grupo). Una semilla hace la selección idéntica en todos los dispositivos. Variar la tasa por agrega dimensiones de grupo a partir de los campos del muestreo (los numéricos pueden dividirse en tramos, por ejemplo clases de talla de 5 cm), y una tabla de excepciones de tasa fija una tasa distinta para grupos concretos. También puede activar la numeración de especímenes (prefijo, inicio, fin, relleno) y reiniciar el conteo en cada registro padre.

El mismo plan como JSON:

[
  {
    "key": "subsample",
    "label": { "en": "Sub-sample", "es": "Submuestra" },
    "strategy": "systematic",
    "rate": 3,
    "seed": "subsample-2025",
    "stratum": { "keys": [{ "field": "species" }] }
  }
]

Durante la captura, el formulario muestra la decisión en vivo (seleccionado, una selección próxima, o no seleccionado) y un número de espécimen cuando se configura. La decisión se almacena con el registro para que las tasas de muestreo puedan aplicarse en el análisis.