AISA v2.0 / Technical documentation / Non-Goals
Non-Goals
F verified factP decided planC open challenge
Deliberate exclusions. Challenge them here, not mid-build.
1. What is deliberately not on this list
P Three former entries are withdrawn, because they are targets (decision Vladimir, 03.09.2026 — D81, completing D76). Autonomous production writes, autonomous customer-visible communication and a customer self-service surface are what this platform is built to reach. A desk that runs without an operator on duty is the first goal (Support SG-15, Platform PG-26); a surface the customer works directly is what such a desk becomes. Listing them as non-goals states the opposite of the design.
What replaces all three is a single boundary — N-12, no autonomy the platform granted itself — plus a defined path each of them travels rather than an open door:
| The target | The path it travels | Where the path is defined |
|---|---|---|
| A write applied without a person | write-identity stages: observed → shape-approved → policy-confirmed, per case type and per target | Gating § 3–§ 4 (D65) |
| A message sent without a person | the same stages, plus the register rules for the customer's language and the drafted shape | Gating § 4, Stage Application and Verification |
| A customer working the desk directly | the work types that have earned policy confirmation, exposed on the surface after the operator surface and the gate protocol exist | UI, N-12 below |
P The withdrawn ids N-2, N-3 and N-9 are not reused; § 3 records what each became, so a reference written against the old numbering still lands on an answer.
2. The exclusions
| # | Non-goal | Why / source |
|---|---|---|
| N-1 | Replacing or re-implementing IPAL, INSIS, or ABACUS logic | AISA Next configures, investigates, and repairs the estate; it is not a PAS. INSIS code changes remain CRs to the customer (rule). |
| N-12 | Autonomy the platform granted itself | A write class leaves the always-human set only when the organisation accepts that named risk class in a recorded decision, per case type and per target. No policy row, no configuration value and no agent may move it, the set never widens as a side effect of a successful run, and one revert moves the class back and suspends the shape. Until a class is accepted, production execution is gate H5 and changes are simulated before promotion unless very small with no blast radius (Gating § 3, Failure and Recovery § 5). |
| N-4 | Camunda (or any BPM) orchestrating the agents | Agents control their own jobs; Camunda remains a configuration target (process registration for products) and a connected system. The estate's Ablera.Serdica.Workflow activity contracts are reused as the cross-service work-unit shape (Software Architecture § 9) — reusing a contract is not being orchestrated by an engine. |
| N-5 | Treating a plan request as implementation authority | A request for a plan ends at the plan; implementation needs its own gate, and an agent cannot promote one into the other. |
| N-6 | Deciding vendors, dates, named staff, headcount, or suppliers in this documentation | Web framework details beyond the serdica-ui page, database/queue/search suppliers beyond what the estate already runs, schedules, named staff and headcount are outside this wiki's scope. Capacity statements — how many parallel tracks a seam can absorb — are architecture and stay; what that capacity costs in people and time belongs to whoever owns delivery (D103). |
| N-7 | Equating technical capability with commercial approval | Contract boundaries stay authoritative; the platform executing something does not make it covered work (contract). Kept as an operating rule of the modules, not presented as a product boundary. |
| N-8 | Building new modules or new-product functionality in the Development module (id source) |
Its scope is defects and small extensions (DG-1). The reinsurance capability stream (DV-03) and cross-cutting currency programme (DV-08) follow the estate's programme process; the case records its referral/owner and can receive separately scoped implementation requests. Case journeys tests this explicit boundary. |
| N-10 | Writes to INSIS beyond data corrections under the CR rule | INSIS code and configuration changes remain CRs to the customer (N-1); data corrections through ABLERA_SUPPORT under a grant are the whole INSIS write scope. |
| N-11 | Replacing Jira as the system of record for tickets | Jira remains the record; the case is the platform's working object and links to it. |
3. Withdrawn entries
| # | Was stated as | Is now |
|---|---|---|
| N-2 | "Autonomous production writes" | A target. The exclusion that survives is N-12: reaching it by drift rather than by an accepted risk class. Read Gating § 3 for the stages and Failure and Recovery § 5 for what a revert does to a promoted class. |
| N-3 | "Autonomous customer-visible communication" | A target, on the same terms as a production write: an accepted risk class, an approved shape, the auditor's pass, and one revert suspending the shape. Until a shape qualifies, public comments, transitions and e-mails are drafted-then-gated and closure runs through the customer (rule). |
| N-9 | "A customer-facing self-service surface" | A target — it is what an operator-less desk becomes once work types run under policy. What was right in the old entry is only the ordering: it is not built before the operator surface and the gate protocol exist, because a self-service surface over gates no work type has earned would put a customer in front of an untrained system. |