Administration & Systems

Most of the knowledge base is about doing intelligence work. This article covers the surrounding scaffolding: the parts that keep a deployment accountable and connected. Some of it is administrator-only. If you do not see a panel mentioned here, your role does not include it. That is expected, not a fault.

The audit record

Every action that creates, changes, or deletes data is recorded: who did it, what they did, to which entity, and when. That covers sign-in and sign-out, events, units, annotations, sources, layers, areas of interest, and battlespaces.

This is not bookkeeping for its own sake. It is what makes the platform's output defensible. A conclusion is only as trustworthy as the trail behind it. The audit record means any finding can be traced back to the individual decisions that produced it, through review, audit, or disclosure. It plays the same role as a chain-of-custody log in evidence handling: the finding matters, but so does the ability to show every hand it passed through.

The record is append-only. History cannot be quietly rewritten, by anyone. If a mistake is made, the correction is a new entry, not an erasure.

User administration

On deployments where you hold an administrator role, the Admin area is where operator accounts and their permissions are managed: provisioning accounts, setting what each role can see and do, and removing access when someone leaves. This is also how deployments that disable open sign-up bring new analysts on board (see Creating an Account & Signing In).

Role-based access is the backbone of multi-team use. Read-only analysts, write-enabled operators, and administrators each see an appropriate slice of the platform.

Plans and resource quotas

Each organisation operates under a plan that sets limits on how many resources it can create and how much storage it can use. Plans are managed by administrators under Admin > Plans.

Quotas govern the following resources:

• Battlespaces, events, intel items, actors, and units: each has a maximum count per organisation.
• Investigations and published reports: creation is capped to the plan limit.
• User seats: the number of active user accounts.
• Storage: total disk space used by uploaded files (media, documents, attachments).
• Ingestion runs and report generations: metered operations that reset on a billing cycle.

When a quota is reached, the platform prevents the relevant action and shows a message that identifies which limit was reached. No data is lost. The operation is blocked before it begins. An administrator can raise the limit by changing the organisation's plan, or free capacity by removing unused resources.

Storage metering runs nightly. The platform calculates total disk usage across all uploaded files and compares it against the plan's storage allowance. If storage exceeds the limit, further uploads are blocked until space is freed or the plan is upgraded.

Systems panels

Two operator-facing panels live under ⊞ Tools > Systems:

• Infrastructure: a status view of the platform's own moving parts, so an operator can see at a glance that collection and processing are healthy.
• Webhooks: outbound integration. Webhooks let the platform notify other systems when something happens, for example pushing an alert or event into a downstream tool, a messaging channel, or your own pipeline. This lets Krataxis fit into a wider workflow rather than operating in isolation.

These are deployment-level and integration-level features. Day-to-day analysis never requires them, but they are how an organisation connects the platform into its own stack.

Managing data sources

Beyond the feeds individual analysts add (see Feeds & Sources), a deployment runs a set of platform-wide data sources that feed every battlespace centrally. These are administered under Admin > Sources.

The Sources view is a health dashboard: each source's credibility score, how many items it has contributed, how many ingestion runs and errors it logged in the last 24 hours, and when it last ran with what status. It is where an operator confirms collection is healthy. A source that quietly errors out shows up here first, long before an analyst notices the picture thinning.

Opening a source for editing exposes its core settings: display name, type, credibility score, poll interval, an active toggle, and a configuration field that holds the type-specific parameters. You can also poll now rather than wait for the schedule, and attach a source to a battlespace so its reporting is always included there.

The GDELT global-events source

The clearest example is GDELT — the worldwide news-event source described in Feeds & Sources. It ships pre-configured and active, polling every 15 minutes. Its configuration field exposes a few deliberate knobs:

• Event types: which categories of event to keep. The default watches conflict and crisis activity (protests, force posture, assaults, fighting, mass violence). Narrow it to cut noise, or widen it for broader awareness.
• Location precision: the minimum geographic precision to accept. Left at its default, the source keeps city-level and landmark-level events and discards country-centroid guesses, so the map is not cluttered with markers placed on a nation's centre point.
• Outlet corroboration: whether to pull the list of distinct outlets that report each event. With it on, an event's corroboration is seeded from how many independent outlets carried it (see Credibility & Validity).

Because GDELT is a shared platform source, its events are scoped into each battlespace by location automatically. A battlespace that covers Eastern Europe picks up Eastern-European events with no per-battlespace setup. To bring a deployment's GDELT picture online you typically need do nothing. To tune it, adjust the settings above and click poll now to see the effect.

Where to next

• Creating an Account & Signing In: how accounts are provisioned.
• Your Profile & Preferences: the per-analyst settings that complement role-based access.