FORGEby AJAEX

Product

An AI partner for the whole TRIRIGA lifecycle.

Equip your team to take on support, investigate server-side Java, prepare proposals and designs, implement approved changes, and operate across multiple instances. FORGE connects live estate evidence to the actions needed to deliver the work.

Assess your TRIRIGA estateChoose a deployment model

Support, design, implementation, and operation

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

Use FORGE 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 can use FORGE 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. FORGE exposes 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. FORGE provides 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 FORGE 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 FORGE. Business decisions, estimates, completeness, and design sign-off remain review steps.

04

Implementation alongside your team

FORGE can be an active implementation partner. Enabled tools can create and edit supported application definitions through native TRIRIGA paths, with the AI carrying the design context into the work and your team reviewing the result.

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 model metadata, and supported integration definitions; exercise agreed record and workflow actions.

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 for supported configuration changes, 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, validate, export, import, and track the agreed release artifacts.
  • For supported JAR releases, capture the baseline, check content hashes, deploy, and activate the named classloader.
  • 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. 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 customer and environment to its own tool route, identity, and policy. 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 a TRIRIGA estate across multiple instances and customer engagements.

  • 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; continuous fleet monitoring and automatic promotion are not implied.

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.

  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, FORGE uses native platform paths to create or update configuration and execute named actions. These capabilities are scoped separately from read-oriented estate intelligence.

    • Explicit tool allow-list and environment policy
    • Confirmation before change actions
    • 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, FORGE uses Object Migration and signed deployment paths. Each engagement defines the approved artifacts, target environment, identity, rollback, and verification controls.

    • Named version and release identity
    • Object Migration packaging for agreed artifacts
    • Signed deployment paths with environment-specific approval

    Representative request

    “Package the approved change set and show the target 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
    • 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. FORGE is 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 with a bounded intelligence pilot.

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
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
  • Signed deployment operations
  • 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.

Talk to AJAEXRequest a demonstration