Customisation & Context Memory

Learn how Genesis preserves business context and supports governed changes to existing applications.

Customisation and Context Memory

Applications change. Their important decisions should not disappear.

Operational applications need to evolve as business rules, people, processes and integrations change. A change that appears small on one screen may affect permissions, underlying data, other workflows or external systems.

Genesis Context Memory retains relevant engineering context so that future work can consider the decisions and dependencies behind the accepted application.

What Context Memory preserves

Depending on the application and accepted scope, preserved context can include:

  • Business objectives and confirmed requirements.
  • Business rules, validations and operating constraints.
  • Roles, permissions and approval responsibilities.
  • Workflow steps, states, exceptions and dependencies.
  • Data structures, interfaces and agreed integration mappings.
  • Decisions, change history and relevant validation evidence.

Context Memory is not a substitute for current business approval. It helps a proposed change start from known evidence rather than treating the application as an unfamiliar collection of screens and code.

When Context Memory begins

Context Memory starts from a completed, customised and tested application whose agreed source, database structure, configuration and deployment baseline have been accepted. It reflects the accepted application, with supporting requirements and decisions linked where available.

After an authorised change is implemented, tested and accepted, Context Memory is reconciled with the new accepted application revision.

How a change is considered

  1. Request. Describe the required outcome and why it is needed.
  2. Impact. Identify affected workflows, rules, roles, data, integrations and tests.
  3. Clarify. Resolve missing requirements and any conflict with accepted decisions.
  4. Agree scope. Review the requested work, responsibilities and applicable AEU usage.
  5. Implement. Perform the approved Genesis-assisted or customer-led engineering work.
  6. Validate and accept. Test the affected behaviour and record the accepted revision through the agreed process.

The process and available controls depend on the current product release and the customer's engagement. An AI-generated proposed change should not be treated as accepted merely because it can be applied.

Example: adding a second approval

Suppose an organisation wants certain stock transfers to require two approvals. The change may affect the approval workflow, delegation rules, notifications, role permissions, API checks and test scenarios.

Context Memory helps bring those dependencies into the review. The responsible business owner still needs to define when the second approval applies, who is authorised and what happens when an approver is unavailable.

Illustrative example only. Actual implementation depends on the accepted requirements.

Ways to customise

Genesis-assisted customisation: The organisation requests an enhancement or change through the agreed Genesis workflow. AEU is consumed according to the assessed scope and complexity.

Customer-led engineering: The customer's authorised team may perform work using the access, tools and methods included in its agreement. Responsibilities for reintegration, testing, Context Memory updates, operations, support and acceptance are defined in the agreement. External changes are not automatically accepted into Genesis or covered by support.

Dalfin-assisted or delivered work: Dalfin AI can take agreed responsibility for specified enhancements, integrations or engineering work.

These approaches do not imply unrestricted access, unlimited engineering or unlimited use of shared platform services.

Large expansions are assessed as scope changes

Adding substantial new modules, workflows, integrations or other capabilities can materially change the application. The cumulative impact of several smaller requests may also be significant. Such work is assessed and agreed according to its actual scope, not only whether it shares the original application name.

Connected is distinct from AEU

Connected supports ongoing context and governed continuity. AEU measures Genesis-assisted generation and customisation work. Connected does not make engineering work free or unlimited.

AEU and Connected ยท Application ownership and deployment