Saltar a contenido

Business Observer Blueprints

Estado: CARPETA ACTIVA CON BLUEPRINTS FUNCIONALES PRINCIPALES

Scope: tenant

tenant_id: alpuntodeventa

portal_visible = yes

Que es un blueprint

Un blueprint es un documento funcional estable que define un dominio antes de contratos, mappings, design o implementacion.

Autoridad de autoria:

Debe explicar:

  • que dominio gobierna
  • que preguntas responde
  • que conceptos define
  • que fronteras tiene
  • que decisiones ayuda a tomar
  • que evidencia minima necesita
  • que documentos tecnicos debe referenciar

Blueprints vigentes

  • CUSTOMER-BLUEPRINT.md: define que es un Cliente para OpenClaw / APV, sus reglas de identidad, estado, contacto, territorio, ownership, frecuencia, sensibilidad comercial y relacion con otros dominios.
  • PRODUCT-BLUEPRINT.md: define Producto como entidad de catalogo comercial, anclada a tenant_id + sku, marca, proveedor, categorias, costos, precios, margen, mix y relacion con ventas y recuperacion.
  • SALES-BLUEPRINT.md: define Venta como hecho transaccional itemizado desde SOURCE-003 / Tabla 2 vNext, con line_key_v4 en estado AMARILLO ACEPTADO y atribucion a seller_transactional.
  • OWNERSHIP-BLUEPRINT.md: define ownership como lectura analitica de quien trabaja realmente una cuenta, preservando seller_assigned y seller_transactional separados.
  • TERRITORY-BLUEPRINT.md: define territorio separando zona logistica de territorio comercial del vendedor, con normalizacion territorial gobernada y relacion con ownership.

Que NO es un blueprint

Un blueprint no es:

  • un SQL
  • un DDL
  • una migracion
  • una query
  • un mapping origen-destino
  • un contrato de datos
  • una fuente de autoridad
  • un inventario de resultados
  • un dashboard
  • una implementacion
  • una autorizacion para tocar runtime

Relacion con sources

Los documentos en sources/ describen fuentes, disponibilidad, limites y semantica observada.

Un blueprint puede referenciar una fuente, pero no debe copiar su inventario ni redefinir su autoridad.

Relacion con mappings

Los documentos en mappings/ describen correspondencias origen-destino.

Un blueprint puede explicar por que un mapping es necesario, pero no debe duplicar campos ni reglas tecnicas de mapping.

Relacion con contracts

Los contratos definen compromisos funcionales de datos.

Un blueprint puede declarar que contrato necesita, pero el detalle contractual debe vivir en el contrato correspondiente.

Relacion con design

Los documentos en design/ bajan decisiones a arquitectura, DDL documental o implementacion futura.

Un blueprint debe terminar antes del design: define el dominio y deja que el design resuelva la forma tecnica.

Dominios principales cubiertos

La capa blueprint principal del Business Observer APV queda cubierta por:

  • cliente
  • producto
  • venta
  • ownership
  • territorio

Visibilidad en Knowledge Portal

La carpeta de blueprints principales del Business Observer APV queda clasificada como portal_visible = yes.

Los blueprints vigentes listados en este README deben aparecer en el OpenClaw Knowledge Portal mediante mkdocs.yml o mediante esta pagina navegable.

Documentos relacionados:

  • contratos funcionales de datos: portal_visible = yes
  • source authority SQL: portal_visible = technical_reference o portal_visible = internal_only
  • change packets vinculados: portal_visible = pending_review o portal_visible = internal_only
  • runtime, seguridad, credenciales o detalle operativo sensible: portal_visible = internal_only

Regla de creacion

Antes de crear un blueprint, confirmar:

  • dominio funcional claro
  • frontera con BUSINESS-OBSERVER-GOVERNANCE-MODEL.md
  • relacion con Core y Tenant
  • evidencia minima conocida o declarada como pendiente
  • documentos de source, mapping, contract o design relacionados
  • ausencia de duplicacion con un blueprint existente