> ## Documentation Index
> Fetch the complete documentation index at: https://docs-attestly.code4source.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Builder visual
> Escribe rulesets visualmente en el playground — arrastra nodos, conéctalos y ejecútalos en un mapa.
El **playground** es un entorno visual donde escribes y pruebas
rulesets sin tener que escribir JSON a mano. Combina un mapa con un
**builder** basado en grafo: dibujas un polígono, sueltas nodos en
un canvas, los conectas y ves el verdict en la misma pantalla.
## Vista general
El playground divide la pantalla en tres áreas:
1. **Mapa** — dibuja o pega una geometría. Se convierte en el
`$input` de cada set anclado a ella.
2. **Canvas del builder** — el ruleset visual. Cada nodo es un
`set`, `projection`, `check` o `verdict`; las aristas
representan referencias (ej.: un check apuntando a un set).
3. **Panel** — el botón **Run** en vivo, la vista JSON, el verdict
y la evidence después de cada ejecución.
## Loop de autoría
El loop típico:
1. Dibuja un polígono en el mapa (o pega GeoJSON).
2. Elige un punto de partida — canvas vacío o un
[template](#templates).
3. Agrega nodos desde la paleta y conéctalos.
4. Haz clic en **Run** para evaluar contra el polígono.
5. Inspecciona el verdict y la evidence por check.
6. Itera.
## La paleta
La paleta en la sidebar tiene los tipos de nodo que puedes soltar
en el canvas:
| Nodo | Qué produce |
| ------------- | ------------------------------------------------------------------------------------- |
| `source_set` | Un set anclado a un source espacial (ej.: `icmbio_ucs_federais`). |
| `subject_set` | Un set anclado a un subject register (ej.: `ofac_sdn`). |
| `setop_set` | Un set construido vía `union` / `intersection` / `difference` de otros sets. |
| `projection` | Un valor escalar o geométrico computado sobre un set (`count`, `total_area_m2`, ...). |
| `check` | Un predicate booleano con una severity. Alimenta el verdict. |
Suelta un nodo, luego haz clic para abrir su **editor** en la
sidebar derecha.
## Editores
Cada nodo tiene un editor tipado. El editor aplica las mismas reglas
que la API aplica — las configuraciones inválidas se marcan antes
del run.
Para un `source_set` eliges:
* El **source** del catálogo (auto-sugerido vía `GET /v1/sources`).
* El **join** — `intersects`, `contains`, `within`, `covers`,
`covered_by`, `overlaps`, `touches`, `crosses`, `disjoint`,
`equals`, `dwithin`, `beyond` para sets espaciales; `equals` /
`ilike` cuando el set está anclado en un subject register.
* El **target** — `$input` u otro set del grafo.
* Un **filter** opcional (ej.: temporal, property-equals).
Para un `check` eliges:
* La **severity** — `critical`, `high`, `medium`, `low`, `info`.
* El **predicate** — `exists` (set no-vacío) o `threshold`
(la projection referenciada pasa una comparación).
## Conectando nodos
Arrastra desde el handle de salida de un nodo al handle de entrada
de otro. El builder rechaza conexiones que crearían ciclos o que
no cuadran en tipo.
## Run e inspección
Haz clic en **Run** en la topbar para evaluar el canvas contra la
geometría actual del mapa. El panel se actualiza con:
* El `status` (`ok` / `degraded`) y el `outcome` (`compliant`,
`warning`, `non_compliant`, `degraded`) en la cima.
* Cada check: `triggered`, `severity`, lista de evidence.
* Cada projection: valor computado.
Las features de evidence quedan resaltadas en el mapa para que veas
exactamente qué polígonos provocaron el verdict.
## Vista JSON
Cada edición visual sincroniza en los dos sentidos con un documento
JSON. Haz clic en **Show JSON** para abrir el modal — copia el body
para usarlo directamente con `POST /v1/evaluate`, o pega un ruleset
para cargarlo en el canvas.
## Templates
La sidebar ofrece puntos de partida listos cubriendo patrones
comunes:
| Template | Lo que muestra |
| --------------------- | ------------------------------------------------------------------------- |
| `overlap_ratio_tiers` | Checks en capas sobre razones de solapamiento (majority vs partial). |
| `distance_tiers` | Capas de severity basadas en distancia (very close / close / far). |
| `distance_band` | Match de features en una banda de distancia `[min, max]`. |
| `chained_sets` | Un set cruzado contra otro set en vez de `$input`. |
| `dynamic_buffer_app` | Buffer cuya distancia se lee de una propiedad de la feature. |
| `merged_hazard_zone` | Projection `merge` unificando geometrías de un set en una capa de hazard. |
| `temporal_recency` | Filtra features más nuevas/viejas que una ventana relativa. |
| `multi_join` | Múltiples sources en un único ruleset. |
Los templates se cargan en el canvas; desde ahí adaptas nombres,
sources, severities y thresholds a tu política.
## Cuándo usar el builder vs JSON crudo
* **Builder**: explorar políticas, demos a stakeholders, escribir
una primera versión visualmente antes de revisarla.
* **JSON crudo**: editar un ruleset guardado de forma programática,
code review en un PR, generación automática desde una config de
alto nivel.
Los dos son intercambiables — la vista JSON es canónica y el builder
es solo una renderización sobre ella.