Skip to main content
These public docs are meant to be technically useful. They are designed to explain what ViceWire does, how the event model works, what the payload looks like, how the workflow is structured, and where the current limits are. They are not the full internal implementation pack.

What is public today

  • product overview and positioning
  • the event model
  • taxonomy concepts and the current L1 event-family map
  • payload structure and universal field concepts
  • affected business surface
  • directional layers and FinBERT
  • methodology, workflow, and QA approach
  • representative examples
  • current limits and maturity
In other words, the public documentation is intended to explain the product at the concept, payload, and workflow level rather than leave everything abstract.

What is intentionally not public

Some material remains gated. That includes:
  • the full field dictionary for every family
  • the complete schema pack in documentation form
  • every enum list
  • every routing condition, fallback rule, and adjudication edge case

Why this boundary exists

ViceWire is easiest to evaluate when the public docs are detailed enough to show how the system works, but not so detailed that they expose every low-level implementation rule. That is the balance this documentation is trying to strike:
  • enough detail to understand the event model, payload shape, workflow, and quality process
  • enough examples to judge whether the product is conceptually useful
  • not so much detail that the full internal decision logic is reproduced in public
The main intellectual work in a system like this is not just naming a few top-level categories. It is the full set of boundary rules, lifecycle logic, family-specific contracts, edge-case handling, evaluation checks, and model fine-tuning that make the extraction stable.

How to use the public docs

The public docs should be used to answer four questions:
  1. What does the product actually produce?
  2. How does one article become one or more event objects?
  3. What distinctions does the taxonomy preserve?
  4. Is the current methodology credible enough to justify deeper evaluation?
If the answer to those questions is yes, the next step is to request trial access.

What the public docs are not trying to be

These docs are not a full internal operator manual, a full schema dump, or a line-by-line prompt specification. They are public documentation for evaluating product fit, not a complete reconstruction of the internal system.