Transition and Implementation

Design the core as one system. Deliver it in governed stages.

The target architecture should be coherent from the beginning, even when implementation is phased. Ingestion, memory, work, outcomes and learning must share the same semantics, authority and evidence model.

Why not workflow by workflow

Sequential automation can reproduce the fragmentation it is meant to solve.

If each legacy workflow receives its own data model, agent logic and outcome format, the institution ends with faster silos. The architecture should first define the common Inputs, Requests, entities, authority, Work Objects, Outcomes and supporting capabilities that the workflows share.

Core scope

Begin with the institutional mandate.

Included

  • Information ingestion and institutional reporting
  • Mandate, authority and organisational understanding
  • RA 11930 and Strategic Plan compliance monitoring
  • Executive Director directive assignment and compliance traceability
  • Coordination and signal-to-action work
  • Prevention, training and awareness-raising delivery
  • Case, issue, decision and outcome memory
  • Structured reports, referrals and action packages
  • Result capture and policy learning

Deferred or integrated later

  • Generic HR administration
  • Routine procurement
  • Unrelated facilities and back-office activity
  • Commodity functions already served by fit-for-purpose enterprise systems

Existing enterprise systems may remain systems of execution. The organizational AI layer connects mandate-relevant context, work and outcomes across them. In particular, the CyberTipline management software already being deployed should remain the operational source and system of execution; the new layer integrates with it, streamlines internal handling and extends shared memory, coordination and result traceability around it.

Delivery approach

Five delivery waves, five capability tracks.

Waves are successive scoped deliveries: each one produces a complete, usable outcome before the next extends it. P1–P5 are capability tracks that grow across those waves; they are not calendar stages and not five infrastructure projects to finish first.

Each workflow consumes the capabilities it needs at each increment, so a complete first outcome can still cover only part of a workflow's broader agreed scope.

  • Wave 1 · Reporting loop

    Deliver an approved, source-linked ecosystem brief and the reusable reporting memory behind it: permitted submissions, checked evidence, corrections, review and release.

  • Wave 2 · Governance and internal execution

    Extend reporting and statistical products, directive tracking, and selected internal coordination and mandate-enabling administrative subtypes.

  • Wave 3 · Handoffs and registries

    Connect permitted operational intake, one receiving-party feedback loop and an agreed registry update and query scope.

  • Wave 4 · Specialist-domain expansion

    Configure validated investigation, cross-border, legal, compliance and service pathways with their own authority, exceptions and acceptance.

  • Wave 5 · Full agreed scope and improvement

    Complete the remaining agreed catalogue scope and introduce approved evaluation, policy-change and institutional-improvement cycles.

Capabilities expanded across the waves

  • P1 · Ecosystem memory

    Governed, persistent knowledge of the institutions, evidence, rules and work each release needs.

  • P2 · Coordination and execution

    Owners, configured lifecycles, reviews, handoffs and closure for each workflow subtype.

  • P3 · Core business support

    Domain-specific assistance and controlled integration with existing operational systems.

  • P4 · Cross-agency collaboration

    Participating institutions, governed exchange, permissions and feedback agreements.

  • P5 · Evaluation and improvement

    Quality baselines, outcome evidence and authorised change to rules and configuration.

Proposed scope, sequence and coverage are a discussion baseline for NCC, not a signed scope, duration, cost or acceptance commitment.

Every scoped release

The same implementation checklist repeats for each release.

Shared architecture reduces repeated engineering; it does not remove the configuration, discovery, integration and acceptance work each new workflow subtype needs.

  • Confirm the mandate boundary and the outcome this release must produce
  • Map the current evidence for the workflows in scope
  • Define the semantics: Data Blocks, entities, relationships and states
  • Establish governance: provenance, access, purpose, retention and human authority
  • Extend ingestion and Shared Memory for the sources in scope
  • Configure the Work Objects, review roles, handoffs and exceptions
  • Produce the structured outcomes the recipients actually require
  • Close the result loop with confirmations, exceptions and closure evidence
  • Accept against agreed evidence, then extend the coverage baseline

Discovery inputs required

Transition requires operating evidence—not only process diagrams.

Lists and reference data

  • Service, case, issue and request types
  • Entities and relationship types
  • Status, reason and outcome codes
  • Mandates, authorities and approval thresholds
  • Stakeholders, institutions and roles
  • Reports, registers, forms and templates
  • Standard communications and notifications
  • Approved email, Viber and online-messaging intake channels
  • Existing systems and authoritative data sources
  • Current CyberTipline management software and integration points

Questions

  • What event creates the obligation to act?
  • What information changes institutional understanding?
  • Who owns the final outcome?
  • What evidence is required before work can proceed?
  • Which decisions require human or institutional authority?
  • What constitutes completion?
  • When must a matter be escalated, reopened or reviewed?
  • Which information can be shared, with whom and for what purpose?
  • What are the most common delays, failures and rework causes?

Samples

  • Real cases and outcome records
  • Reports and their source material
  • Email and coordination threads
  • Authorised Viber or other online-messaging examples
  • Executive Director directives and evidence of implementation
  • RA 11930 and Strategic Plan compliance reports, indicators and exceptions
  • Registers and trackers
  • Policies, procedures and delegations
  • Forms, templates and system screenshots
  • Exceptions, complaints and dispute examples
  • Payment, referral and fulfilment evidence where relevant

Measures of improvement

The system must improve the institution—not only automate activity.

  • Completeness and quality of decision context
  • Time from Request to governed Outcome
  • Reduction in repeated data gathering and interpretation
  • Evidence traceability from source to report or decision
  • Accuracy and currency of entity memory
  • Coordination delays and unresolved dependencies
  • Traceability of Executive Director directives from issuance to closure
  • Timeliness and completeness of RA 11930 and Strategic Plan compliance evidence
  • Prevention, training and awareness delivery and observed outcomes
  • Reuse of structured institutional outputs
  • Exception, reopening and rework rates
  • Policy improvements supported by outcome evidence
  • User trust, accountability and reviewability

Open the detailed delivery plan.

Invited participants can review the wave-by-wave scope, the coverage of all 24 identified workflows, the acceptance units behind every percentage and the supporting evidence. Sign in with your invited email address to continue.