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)

Columns are listed in alphabetical order by feature name — the same order the screen uses:

Painel de Regras, Upload PDF and Upload URL predate the matrix — each had its own endpoint and lived in the platform's global settings. On 2026-09-06 they were migrated: all seven columns now share one endpoint and one file, and the "legacy" label is gone. What remains of that era is the historical note at the end of this page.

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. The table shows five contexts at a time and scrolls vertically from the sixth on; the feature header and the context column stay fixed while scrolling. The Configurações por Contexto list right below follows the same five-visible-rows rule.
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:

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 and Upload URL columns, tick every context except "Consumidor".
4. Every click persists instantly. Reload the rules or upload 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 — no screen since 2026-09-28

The Ontologia column used to filter the context picker of the former Ontology screen (part of Investigation). Since 2026-09-28 that screen is DATTA Investigation, the Chat in deep-research mode: the contexts come from the Chat bar — your context choice, the workspace and the contexts you can read — and the Ontologia column no longer filters any screen. The ticks stay stored, like the governance columns.

DATTA BPM — active enforcement

The BPM context selector honors the matrix in both places it shows up: when creating a flow in the Process Modeler, and in the dialog that changes the context of an existing flow. Each one loads the registered contexts and the contexts visible to BPM in parallel and, when the second list is non-empty, filters out whatever is not in it. Unticking a context in the DATTA BPM column removes it from both lists, effective as soon as the screen reloads.

As elsewhere, a failed matrix lookup degrades open: the selector falls back to showing every context instead of going empty.

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:

{
  "rules": ["CPC", "CDC"],
  "pdf": [],
  "url": ["CPC"],
  "ontology": ["processos", "cnpj"],
  "dattabi": [],
  "extract": ["processos"],
  "bpm": ["processos"]
}

Historical note — the 2026-09-06 migration

Until that date, Painel de Regras, Upload PDF and Upload URL lived in named fields of runtime-config.json and each had its own pair of endpoints. Those six endpoints were removed, the three features joined the generic endpoint's allowlist, and the values were copied into context-visibility.json at service startup — once, idempotently: the copy only happens while the feature has no key in the new file, so a change made through the screen after the migration is never overwritten. Once copied, the old fields were cleared from runtime-config.json.

Two consequences worth knowing:

• Rolling the platform back to an image older than the migration does not bring the configuration back. The old code would read the three lists as empty — and empty means "all visible" — so the restriction would vanish with no error. Rebuild it from a runtime-config.json backup, or reconfigure it on screen.
• The read filter that dropped deleted contexts still exists, now only on the server side that decides writes. The HTTP response hands back the list as stored, for all seven: filtering there would turn an allow-list whose names are all dead into an empty list — that is, into "all visible" — converting a restriction into a permission exactly when the configuration is most broken. The real cleanup happens when a context is deleted, which removes the name from every feature.

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: rules, pdf, url, dattabi, extract, ontology and bpm. 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, DATTA Extract and Ontologia without screen filtering. The flags are persisted and exposed, but the screens do not yet filter contexts (Ontologia since its screen became DATTA Investigation, on 2026-09-28). 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.

Diagnostics