Context Visibility Matrix

The Context Visibility Matrix governs, in a single table, which features may use the data of each context. When the platform accumulates many contexts, every screen ends up listing all of them: triage users stumble on pilot contexts, the BI team sees databases it should not use, and nobody knows where each context "counts". In the matrix, each row is a registered context, each column is a feature, and the checkbox at the intersection says whether that context appears in that feature — the exposure of every context governed from one place, with immediate effect.

The matrix sits at the top of the Sistema›Contextos›Gerenciar screen (screens/settings-contextos.html), between the header and the "Configurações por Contexto" section.

Columns (covered features)

The first three columns (Painel de Regras, Upload PDF and Upload URL) already existed before the matrix and are still kept in the platform's global settings, each with its own endpoint. The last three (DATTABI, DATTA Extract and Ontologia) are the most recent extension.

Semantics: empty list = all visible

The rule holds for every column:

• No context ticked in a column → all contexts stay visible in that feature. This is the initial state.
• One or more ticked → only the ticked ones appear; the rest are filtered out.

This semantics prevents you from "locking yourself out": unticking every context in a column falls back to all-visible, never to an empty screen.

How to use it

1. Open Sistema›Contextos›Gerenciar.
2. In the Matriz de Visibilidade dos Contextos (top of the page), find the context row and the feature column. The row shows the context's display label, not its internal name — the context whose internal name is Emprestimos shows up as "Análise de Crédito — Empréstimos". Notices that point here name the context both ways, Label (internal-name), precisely so you can find the row.
3. Tick or untick the checkbox. The change persists immediately — there is no separate "Save" button — and survives a page reload.
4. In the Painel de Regras column, the matrix notifies the triage rules screen right away and it updates in real time. For the others, reload the corresponding screen to confirm the effect.

Required permission. Viewing the matrix requires CONFIG_VIEW; changing a checkbox requires CONFIG_EDIT. Without CONFIG_EDIT, the write is denied with a message in Portuguese. See the roles and permissions guide.

Worked example — restricting a pilot context

You just created the "Consumidor" context and, for now, want it to appear only in triage — out of document upload and Ontology:

1. Open Sistema›Contextos›Gerenciar and find the matrix at the top.
2. In the Painel de Regras column, tick every context that should remain visible — including "Consumidor". (Remember: while the column was empty, everything appeared; once you tick, only ticked ones appear.)
3. In the Upload PDF, Upload URL and Ontologia columns, tick every context except "Consumidor".
4. Every click persists instantly. Reload the rules or Ontology screen to confirm the effect.

What each feature does with the matrix

Painel de Regras, Upload PDF and Upload URL — actively applied

The triage rules screen receives the context list already filtered. The upload screens (PDF and URL) filter the list as they load; if the visibility query fails because of a transient outage, they degrade by showing every context — you are never left without an option because of a hiccup.

Ontologia — actively applied

The Ontology screen (part of Investigation) honors the matrix when listing contexts: while building the domain list, it queries in parallel the list of configured contexts and the list of contexts visible to Ontology and, if the latter is non-empty, filters out the ones missing from it. Unticking a context in the Ontologia column removes it from the Ontology screen, with immediate effect after reloading the screen.

If the matrix query fails, the screen degrades by showing every context — the same pattern as the upload screens — so a transient outage never leaves the user without a context.

DATTABI and DATTA Extract — governance recorded

The DATTABI and DATTA Extract columns persist the visibility intent and expose the flags for consumption, but do not yet filter the corresponding screens. The reason is concrete: today those screens operate on connections, datasets and free-form references, and do not enumerate contexts — quick extraction lists connections, and the DATTABI Prep Neo4j destination is a free-text field. As soon as those pickers start enumerating contexts, they will be able to consume the flags to apply the filter.

In practice: ticking or unticking DATTABI and DATTA Extract records the governance and stays available for future consumption, but does not change what appears on those screens in this delivery. The matrix is interface and governance visibility, not a server-side data ACL.

Where the configuration is stored

The three new features live in a dedicated file, context-visibility.json, in the same directory as the runtime configuration, inside the platform's configuration volume. The store uses a read/write lock plus an in-memory cache and applies the "empty list = all visible" semantics.

The file format is a feature -> context list map:

{
  "ontology": ["processos", "cnpj"],
  "dattabi": [],
  "extract": ["processos"]
}

The legacy features (rules, PDF upload, URL upload) did not migrate — they remain in the global settings, for zero migration risk.

Reading and writing from an integration

The platform exposes endpoints to read the full feature → visible contexts map, to read the visible contexts of a single feature and to write the list of a feature. Reading requires CONFIG_VIEW; writing requires CONFIG_EDIT. The method and path of each one are in the API reference.

Two rules apply to those calls:

• The feature is restricted by an allowlist: dattabi, extract and ontology. Any other value is refused with a message in Portuguese in the format {"error": "Funcionalidade desconhecida: <feature>"}.
• On write, a missing or null context list is treated as an empty list — that is, back to the all-visible state.

Known limitations

• DATTABI and DATTA Extract without screen filtering. The flags are persisted and exposed, but the screens do not yet filter contexts. The next step is to consume the flags once the pickers on those screens start enumerating contexts.
• Interface governance, not a data ACL. The matrix does not restrict server-side data access per context — it controls what appears on the screens. Per-context data restriction is the scope of another spec.
• Ontology filtering happens on the screen and degrades open. Filtering runs in the frontend and, if the query fails, every context shows up again.

Diagnostics