TRIRIGA and MREF toolsbyAJAEX

Product

What your AI client can do with the tools.

Take on support, investigate server-side Java, prepare proposals and designs, and implement and release approved changes across your TRIRIGA instances, with a person confirming every change before it is written. Tried and tested on TRIRIGA and MREF.

Book a demoDeployment and security

Support, design, implementation, and operation

The work behind an end-to-end TRIRIGA service.

Use the tools with your approved AI client as a working partner throughout the application lifecycle. Begin with a bounded outcome, then agree the responsibilities, access, and delivery scope needed for ongoing operation.

01

Day-to-day support and incident investigation

Bring more of the support workload into your own team. Your AI client can use the tools to investigate an incident, explain the likely cause, propose a remedy, and prepare a useful handover when specialist escalation is needed.

An evidence-backed diagnosis and a proposed next action, with approved fixes carried into the change workflow.

  • Trace a failed action through record state, access, forms, workflows, and integrations.
  • Inspect workflow errors, queues, agent heartbeats, sessions, and permitted server logs.
  • Draft a root-cause analysis, remediation plan, support response, and reusable runbook.

Operational coverage, response hours, escalation, and production access are agreed for the engagement. Incident investigation does not imply unattended monitoring or a 24/7 support SLA.

02

Server-side Java investigations

Follow an application problem into the server runtime. The tools expose permitted logs, Java and JVM properties, thread listings, cache and performance information, and registered custom classloaders so an AI-assisted investigation can move beyond the TRIRIGA screens.

A technical diagnosis, a proposed Java fix where needed, and a testable release plan.

  • Correlate exceptions with workflow execution, integration activity, and runtime configuration.
  • Inspect deployed resource-file identity and capture an approved JAR baseline for release work.
  • With authorised source and build access, investigate the Java code, propose a patch, and test a candidate before deployment.

Source-code analysis and compilation use your approved coding workspace and build tools. The tools provide TRIRIGA runtime access and controlled release operations; arbitrary server-shell access, heap analysis, and operating-system administration require separately provided tooling.

03

Change proposals, FDDs, and TDDs

Give your AI the business requirement and the relevant estate context. Use the tools' evidence to develop the change proposal, Functional Design Document (FDD), and Technical Design Document (TDD), keeping the proposed behaviour connected to what is already implemented.

Connected design drafts that a business owner and technical reviewer can challenge and approve.

  • Proposal: describe the problem, options, dependencies, assumptions, delivery scope, and risks.
  • FDD: set out user journeys, business rules, roles, exceptions, and acceptance criteria.
  • TDD: identify business objects, fields, forms, workflows, reports, APIs, Java changes, tests, release steps, and recovery requirements.

The AI client prepares documents using your requirements, templates, and the evidence returned by the tools. Business decisions, estimates, completeness, and design sign-off remain review steps.

04

Implementation alongside your team

Once write tools are enabled for a named environment, they can create and edit supported application definitions through native TRIRIGA paths, with the AI carrying the design context into the work and a person confirming each change before it is written.

Implemented artifacts, their design context, and a defined test and review scope.

  • Create and update supported business-object, field, form, and portal definitions.
  • Build and revise workflows, including task graphs, conditions, mappings, validation, and publication.
  • Edit report definitions, Web API models, and supported integration definitions; create and update records, and run agreed state transitions and workflows.

Available actions depend on the installed version, enabled tools, integration permissions, and agreed change scope. Production changes require explicit authorisation and a verification plan.

05

Packaging, deployment, and verification

Keep the path from implementation to release connected. Use version labels and Object Migration to carry supported configuration changes between your environments, and the signed resource-deployment path for authorised custom JAR releases.

A release with an identified target, retained baseline, and evidence of what was actually deployed and tested.

  • Inspect package contents, then move the agreed package to the target environment with a content-hash check. Preflight runs native validation and platform checks, builds a rollback export, and warns where the import would overwrite changes made directly in the target.
  • Promote one release through the agreed stages in order, with soak periods. Each deploy waits for a person to approve it on the admin portal.
  • For supported JAR releases, capture the baseline, check content hashes, deploy, and reload the named classloader without restarting TRIRIGA.
  • Read back the target configuration and release identity, run the agreed tests, and record recovery or follow-up actions.

JAR deployment is a release-operator capability, and promotion is never automatic. Approval, interruption handling, regression, and recovery requirements are defined per release; configuration readback alone does not prove business behaviour.

06

Operations across multiple instances

Connect each agreed environment to its own tool route, identity, tool selection, and policy. Tried and tested on TRIRIGA and MREF. Your AI can repeat a scoped investigation across authorised instances and compare the returned evidence without treating one environment as proof of another.

A repeatable way to support and evolve TRIRIGA estates across multiple instances.

  • Establish an inventory and operating context for each connected instance.
  • Compare selected configuration, workflow, integration, and release evidence between environments.
  • Carry the incident, design, release checklist, and handover context across teams and delivery stages.

Each instance needs agreed connectivity, entitlement, and permissions. Cross-instance comparisons are scoped investigations, not continuous fleet monitoring, and promotion between environments always waits for human approval.

Illustrative engagement

From a recurring incident to a verified change.

  1. 01

    Investigate

    A work-order integration fails intermittently. Inspect permitted logs, runtime state, records, and related workflow and Java evidence.

  2. 02

    Propose and design

    Draft the change proposal, FDD acceptance criteria, and TDD covering the affected artifacts, implementation approach, tests, and recovery plan.

  3. 03

    Implement and test

    After approval, make supported configuration changes or develop a Java patch in the authorised build workspace. Test the agreed behaviour in non-production.

  4. 04

    Release and support

    Promote the approved artifacts to the named target, verify the result, and update the runbook and handover with findings and remaining risks.

This is a representative workflow, not a customer case study. The connected tools, source access, tests, and approval steps are agreed for the actual engagement.

Worked examples

Real questions, answered from the system itself.

Four everyday configuration questions, put to the tools on a demo TRIRIGA with made-up data. The tools read the instance's own metadata. Timings are as measured at the time.

Worked out in 2m 17s

A different SLA at each location

One customer, one service, two locations, and a different SLA at each. The answer: one service agreement, one service line per location with its own respond and due terms, and the SAM records that come out of it when the contract is activated.

Worked out in 2m 14s

Email the requester when a service request is submitted

Before building anything, it checked the instance and found that TRIRIGA already ships this behaviour: the Submit action triggers an out-of-the-box workflow that notifies the Requested For person. The job is to verify it and switch it on, then customise it if you need to.

Worked example

Map a work task's org stamp from the responsible org

Map a work task's organisation stamp from the responsible organisation with two new workflows and one edit.

What was asked

Show me what it would take to adjust this to map the org stamping from the responsible organization on that work task.

The change that would be required: two new workflows, one edit. On the associate organization, set customer org from responsible org.

It's called Cloud Login

Add an IdP in TRIRIGA without turning on SSO

TRIRIGA Platform 5.0.7 supports adding an identity provider while keeping SSO=N, under Tools, System Setup, Integration, OAuth Settings. For teams moving to IBM MREF, that means several identity providers can sit in one system.

The answers come from a TRIRIGA instance through the agreed tooling; your own estate's configuration determines what applies.

  1. 01

    Understand

    Build a grounded map of the estate you actually run.

    Read design-time and runtime evidence across modules, business objects, fields, forms, workflows, queries, reports, security, integrations, records, services, and deployment artifacts.

    • Inventory standard, customised, and overridden artifacts
    • Resolve names, IDs, physical storage, versions, and relationships
    • Orient a delivery team without relying on stale documentation

    Representative request

    “Which business objects define this field, and where is each version used?”

  2. 02

    Assess impact

    See what depends on a change, and what still needs checking.

    Traverse exact and qualified evidence streams across related business objects. Return source identity, warnings, confidence, and lower-bound counts when the available evidence cannot prove completeness.

    • Field and business-object where-used analysis
    • Workflow, form, report, query, and integration dependencies
    • Recently removed or changed references where evidence exists

    Representative request

    “What can be affected if we change this field, including related BOs?”

  3. 03

    Change

    Keep approval and environment policy in the path.

    When enabled by the agreed policy, the tools use native platform paths to author workflows, forms, portals, reports, and data-model and Web API definitions, create and update records, and run state transitions such as Submit or Approve. These capabilities are scoped separately from read-oriented estate intelligence.

    • Explicit tool allow-list and environment policy
    • A person confirms each change before it is written
    • Workflow request validation without execution

    Representative request

    “Create this approved workflow revision in the named non-production environment.”

  4. 04

    Package and deploy

    Move approved artifacts through a controlled release path.

    Where enabled, the tools carry Object Migration packages between your environments and deploys custom JARs through a signed path. Nothing is imported until an approver has reviewed the plan, its checks, overwrites, and rollback on the admin portal.

    • Preflight with native validation, platform checks, and a rollback export
    • Release stages in order, with soak periods and a person approving each deploy
    • A warning when an import would overwrite changes made directly in the target

    Representative request

    “Package the approved change set, promote it to UAT, and show the approval and release evidence.”

  5. 05

    Verify

    Read the deployed state back instead of assuming success.

    Re-query the target estate, compare the expected and observed state, and retain agreed verification evidence for the selected tool surface and delivery model.

    • Post-change metadata and version readback
    • Deploy status followed to deployed or failed, and a server smoke check after a JAR release
    • Expected-versus-observed comparison
    • Audit evidence appropriate to the selected deployment model

    Representative request

    “Confirm the deployed version and show what changed in the target estate.”

Demonstrations use real product behaviour within an approved environment and agreed tool scope.

Evidence model

A result should explain why it can be trusted.

Cross-artifact analysis can fail quietly when one query is treated as the whole answer. The tools are designed to expose the evidence boundary and route the next investigation step.

Source

Which live table, API, metadata family, or composed tool produced the evidence.

Scope

Which module, business object, version, environment, and policy boundary shaped the result.

Completeness

Whether the count is complete, partial, a lower bound, or blocked by an unavailable stream.

Next step

The drill-down or additional evidence needed before a decision can be made.

Scope before access

Begin with intelligence. Add governed change within an approved boundary.

Read-oriented intelligence

Start read-only in one environment.

Start with one named evidence outcome and the smallest useful read-oriented tool surface in a non-production environment.

  • Estate and metadata discovery
  • Business-object and field impact
  • Workflow and form analysis
  • Reports, queries, and integrations
  • Selected platform, queue, session, and deployment diagnostics
  • Version, provenance, and relationship evidence
  • Record reads through TRIRIGA's own OSLC and query APIs
  • Platform reference and a per-environment knowledge base
Governed change scope

Add change capabilities within an approved scope.

Authoring, administration, and release tools require a separate policy, approval, identity, rollback, and verification boundary.

  • Record and configuration changes
  • Workflow and builder actions
  • Object Migration packaging and promotion between environments
  • Signed JAR deployment and classloader reload without a restart
  • Post-change verification and readback
  • Administrative actions agreed for the named environment

Test the product against a question you already know is hard.

A technical demonstration can focus on a concrete metadata, dependency, migration, or governed-change case, with capabilities limited to the agreed scope.

Book a demoSee prices