Security & Access Control - Conceptual Model

Conceptual Model

Date: 2026-06-27

1. Design intent

Synallagi operates across organizational boundaries. A person may work for one producer, represent another party under contract, participate in several Joint Operating Committees, perform a specialized duty for a limited period, support a marketplace, and possess different authority in each context.

A conventional statement such as "assign the user a role" is therefore insufficient. Synallagi must determine who the person is, whom they represent, where and in which organizational construct they are acting, what duty they are performing, which information and transaction are involved, the limit of their authority, and whether the current circumstances provide sufficient assurance.

This need for context becomes more important as Synallagi advances hyper-specialization and the division of labor. A geologist may specialize in a formation or geophysical theory. An engineer may specialize in a particular form of hydraulic-fracturing design. An administrative or accounting specialist may manage one narrow process within the Material Balance Report. A single producer or Joint Operating Committee may not generate enough demand to sustain these capabilities within only one producer. Synallagi must enable specialists to work across many producers, Joint Operating Committees, markets, and assignments without receiving broad or permanent access to all of them.

Synallagi is ecosystem-informed, user community-led, service provider-enabled, and technologically supported. Producers participate in this environment, but they are not its exclusive or dominant source of operating knowledge. The relevant community includes service providers, engineers, geologists, accountants, administrators, contractors, service-industry firms, financial participants, technology providers, artificial intelligence specialists, cybersecurity specialists, and other disciplines required to rebuild oil & gas accounting, administration, operations, governance, and marketplaces.

Industrial Command and Control remains the business model through which authority, responsibility, coordination, and accountability are established. Security and Access Control is the policy system that faithfully enforces that model. Its practical objective is to enable the right person, with the right access, to the right information, at the right time, in the right place, on the right device, with the right authority, and through the right method of engagement.

2. Governing principles

1. Explicit representation: every consequential action identifies the organization, market, Joint Operating Committee, or other recognized construct on whose behalf it is performed.

2. No authority by implication: access to a function does not by itself grant authority to commit a party, approve expenditure, disclose information, publish market data, or direct work.

3. Contextual least privilege: access is restricted by duty, information, organizational construct, Joint Operating Committee, property, agreement, market, transaction, time, authority, and accountability.

4. Independent revocation: ending one assignment removes only the access derived from that assignment.

5. No permanent trust from network location: identity, policy, and current context determine access.

6. Foundational accountability: every material decision remains attributable to an authorized human or explicitly governed automated authority.

7. Complete evidence: Synallagi records the basis on which material access and authority decisions were made.

8. Safe failure: uncertainty about identity, representation, policy, scope, authority, cybersecurity condition, or accountability results in denial or controlled escalation.

9. Technology-independent requirements: Oracle capabilities implement the model but do not define Synallagi's organizational concepts.

10. Governed change: roles, policies, conflicts, authority templates, market rules, wallet rules, and artificial intelligence guardrails are versioned and reviewed like other critical product configuration.

3. Core objects

3.1 Identity

An identity is the persistent digital representation of a human, service, integration, device, wallet, or automated agent. Its purpose is to give Synallagi one reliable subject to which authentication, organizational relationships, assignments, actions, and accountability can be attached. A human identity normally remains the same while the person's employer, producer representation, Joint Operating Committee memberships, market participation, duties, and authority change around it.

An identity is not an employee record, Joint Operating Committee member, role, wallet, account, or market participant. Those are relationships or assignments attached to the identity.

Identity is broader than federated identity. Federation is one method by which Synallagi may trust another organization's authentication of an identity. It does not create Joint Operating Committee membership, market participation, wallet authority, or business authority.

Each identity consists of a unique identifier, type, status, authoritative source, assurance information, and lifecycle. Non-human identities must have a named human or organizational owner.

3.2 Organization

An organization may be a producer, service company, supplier, regulator, auditor, financial participant, service provider, People, Ideas & Objects, or another recognized legal or commercial party. A market, Joint Operating Committee, user community, role, or wallet community may influence access but is modeled separately because it is not necessarily an organization.

3.3 Organizational relationship

This object establishes why an identity may represent an organization. Examples include employment, directorship, partnership representation, professional engagement, service contract, regulatory appointment, audit engagement, or approved marketplace participation.

The relationship represents an owner, sponsor, effective dates, status, and evidence. Ending it triggers review or revocation of all derived assignments.

3.4 Organizational construct

Synallagi organizational constructs define, support, and constrain what the application, its participants, and its automated processes may do.

The nine organizational constructs currently identified are:

1. Joint Operating Committee.

2. Endogenous Technical Change and sharing of infrastructure.

3. Hyper-specialization and division of labor.

4. Markets.

5. Innovation.

6. Intellectual Property.

7. Information Technology.

8. Trust.

9. Transactions.

An organizational construct is represented in security policy when it creates membership, authority, responsibility, information, process, market, technology, trust, or transaction boundaries. The constructs must not be reduced to technical roles. They are part of the institutional design that determines which relationships and actions Synallagi recognizes.

3.5 Joint Operating Committee

A Joint Operating Committee is the key organizational construct of Synallagi and a governed multi-party operating context. It has members, participating organizations, agreements, properties, decision rules, authority structures, information boundaries, effective dates, and accountability requirements.

The Joint Operating Committee is not merely a data-security segment. It is a domain object from which scoped authority and access may be derived.

3.6 Representation

Representation connects an identity, organization, and operating context. It answers: "For whom is this identity acting here?"

An identity may have more than one representation, including arrangements in which a small producer participates through another producer as a non-novated member. The active representation must be unambiguous when a material action occurs. Where dual representation creates a conflict, policy must prohibit the action or require declared mitigation.

3.7 Business role

A business role describes a recognizable position in an organization, Joint Operating Committee, market, user community, or service-provider process, such as working-interest representative, production engineer, controller, external auditor, formation specialist, transaction designer, wallet administrator, marketplace participant, or Material Balance Report reconciliation specialist.

A role groups duties but does not itself define all information access or authority.

3.8 Duty

A duty is a coherent responsibility such as preparing an Authorization for Expenditure, reviewing a voucher, approving a work order, reconciling production, certifying access, administering security, designing a transaction, qualifying a market participant, or reviewing blockchain settlement evidence.

Duties are the primary units used for least privilege, work rotation, segregation-of-duties analysis, and assignment of accountability.

3.9 Privilege

A privilege permits a system action such as view, create, amend, approve, post, export, administer, settle, tokenize, revoke, or invoke an application programming interface operation.

Privileges enable functions. They do not independently grant information access or business authority.

Synallagi application programming interfaces are private. Direct access is restricted to licensed developers, approved user-community participants, service providers, and authenticated runtime integrations. Public users receive only the compiled or runtime application functions intentionally exposed to them.

Unauthorized release or use of private application programming interfaces is a license, security, and intellectual property concern. The specification should state Synallagi's product policy clearly without relying on legal interpretation inside this module.

3.11 Authority

Authority permits a subject to make or approve a business commitment. It may be constrained by monetary value, ownership interest, voting threshold, technical discipline, geographic area, property, transaction type, market, wallet, settlement instrument, or emergency condition.

Authority is granted by an accountable body and must have an effective period and evidence for accountability and auditability. The system must make the origin, exercise, result, and subsequent review of authority visible.

3.12 Responsibility and accountability

Responsibility identifies the party expected to perform or supervise work. Accountability identifies the party answerable for the outcome. Neither should be inferred solely from technical access.

Accountability must persist from the assignment of authority through the transaction, resulting records, financial statements, investor communication, performance evaluation, and audit evidence.

3.13 Delegation

A delegation temporarily transfers specified duties or authority. It identifies delegator, delegate, scope, reason, dates, approval, conflicts, and revocation state.

Delegation cannot create powers the delegator does not possess, evade segregation-of-duties policy, or silently transfer accountability. Synallagi should support innovative delegation patterns developed through our user community where they are needed to preserve organizational continuity.

3.14 Policy

A policy expresses the conditions under which a request is permitted, denied, or escalated. Policies may be global, organizational, Joint Operating Committee-specific, resource-specific, transaction-specific, market-specific, wallet-specific, or method-specific.

3.15 Audit event

An audit event records who or what acted, represented party, context, action, resource, before and after state, evaluated policy, decision, authority basis, time, assurance, result, accountability, and correlation identifiers.

Synallagi shall restore audit controls to a central operational role and demonstrate their value across distributed workforces, artificial intelligence-assisted processes, Joint Operating Committees, markets, service-provider activities, blockchain-supported transactions, and crypto-based asset participation.

In addition to audit controls, People, Ideas & Objects invites accounting firms to establish their own user-community members to actively participate in software development. The objective is to integrate higher levels of accountability, assist audit needs, and reduce the overall costs of annual audits and statutory reporting for the oil & gas industry.

4. Access-decision model

Every protected operation is evaluated as:

Subject plus representation plus operating context plus duty plus action plus resource plus information scope plus transaction state plus authority plus time plus session assurance plus cybersecurity condition plus applicable constraints plus accountability assignment.

The decision process should answer:

1. Is the identity active and sufficiently authenticated?

2. Is its authoritative relationship still valid?

3. Which organization is it representing?

4. Is that representation valid for this producer, Joint Operating Committee, agency, employment assignment, market, wallet, or other recognized context?

5. Does the identity hold the required role and duty?

6. Does the duty provide the required system privilege?

7. Does the data entitlement include this exact resource?

8. Is the transaction in a state where this action is permitted?

9. Does the identity possess sufficient business authority?

10. Would the action create a segregation-of-duties or representation conflict?

11. Are time, session, device, location, identity assurance, and cybersecurity conditions acceptable?

12. Is additional approval, step-up authentication, or independent certification required?

13. Is the accountable party identified?

The decision and its material inputs are retained as evidence for consequential actions.

5. Trust boundaries

Boundary A — home organization to Synallagi

The home organization may authenticate its people and assert selected attributes. Synallagi determines which issuers, authentication assurances, attributes, and lifecycle signals it accepts.

Boundary B — organization to Joint Operating Committee

Employment or authentication does not automatically confer Joint Operating Committee membership. A valid Joint Operating Committee representation and assignment are separately required.

Boundary C — Joint Operating Committee to producer-private information

Participation in a Joint Operating Committee grants no implicit access to a producer's strategy, reserves analysis, internal correspondence, unrelated properties, or other private information.

This boundary does not restrict information that is public by law or regulation. Production volumes, well configurations, drilling records, hydraulic-fracturing information, and other prescribed records may need to be disclosed in considerable detail.

Boundary D — Joint Operating Committee to marketplace

Information and authority used in a Joint Operating Committee are not automatically publishable or usable in a marketplace. Disclosure and commitment require separate privileges and authority, except where a defined public-disclosure obligation applies.

Boundary E — human to automated agent

An artificial intelligence system or automated service receives only explicitly delegated information and actions. The system records whether output is advisory, prepared for approval, or executed under governed automated authority.

People, Ideas & Objects' intellectual property and Targeting Framework are intended to define the objectives, permissions, constraints, and boundaries within which agents operate. These guardrails must be implemented as enforceable policy and monitored behaviour, not only as instructions to the model.

Boundary F — application to integration

Every application programming interface client and integration has its own identity, owner, credential lifecycle, permissions, information scope, and monitoring. Shared technical accounts are prohibited except under an approved transitional exception.

Boundary G — market to asset ownership

Market participation, wallet control, stablecoin payment capability, or blockchain address control does not automatically establish beneficial ownership, authority to sell, authority to pledge, authority to vote, or authority to receive Joint Operating Committee-level financial statements. Those rights must be separately represented, evidenced, and governed.

6. Assignment lifecycle

Join

1. Establish or federate identity.

2. Verify organizational relationship and sponsor.

3. Admit the organization and representative to the applicable context.

4. Assign governed roles and duties.

5. Define information scope and authority.

6. Evaluate conflicts.

7. Obtain required approvals.

8. Provision and verify access.

9. Record evidence and notify relevant owners.

Recurring transaction designs should be expressed as governed templates. A template defines the persistent, generic elements of a transaction type: roles, duties, workflow, information requirements, controls, authority patterns, and audit evidence. Each assignment supplies the people, organizations, Joint Operating Committees, properties, values, dates, and other context unique to that transaction.

Move

Changes in employer, contract, represented organization, Joint Operating Committee, property, duty, authority, ownership, pooling assignment, market status, wallet authority, or transaction template trigger reevaluation. New access is not simply added to old access. Obsolete derived access is removed.

Leave

Termination, contract expiry, Joint Operating Committee withdrawal, assignment, novation, farmout, farmin, subsequent joint venture, working-interest disposition, suspension, loss of qualification, market removal, wallet compromise, or termination of a pooling assignment causes prompt reevaluation or revocation.

Review

Access is certified periodically and after material events. Reviewers assess not only the assigned roles but Joint Operating Committee membership, information scope, authority, delegation, privileged access, market access, wallet authority, artificial intelligence access, and unresolved exceptions.

7. Segregation-of-duties model

Conflicts should be defined at three levels:

1. Assignment conflict: incompatible duties are held concurrently.

2. Transaction conflict: one person attempts incompatible actions on the same transaction.

3. Representation conflict: one person represents parties with conflicting interests in the same decision.

A conflict may be prohibited, require a different actor, or proceed only with an approved mitigating control.

8. Illustrative decision scenarios

Authorization for Expenditure approval

A partner representative may approve an Authorization for Expenditure only for the represented partner and applicable Joint Operating Committee, within a valid assignment and monetary authority, after required authentication, provided the representative did not perform a prohibited conflicting duty.

8.a. Voucher review

A working-interest participant may view joint-account voucher information and supporting evidence to the extent established by the governing agreement and pooled Joint Operating Committee structure. Producer-private analysis, unrelated properties, and another participant's private annotations remain outside that entitlement.

Implementation within Synallagi is defined in the Accounting Voucher module. What is an accounting voucher is unique with particular characteristics for North American oil & gas and use of the Joint Operating Committee. A point of discussion is the Accounting Voucher can be saved as a template, added to as time passes and reused. When a template is deployed and is active within the accounting month it is then called a Synallagi. The Greek word for transaction, deal, business or exchange.

Marketplace participation

A market participant may offer services, bid, negotiate, or accept an assignment only within an approved market role, qualification, representation, disclosure policy, and authority limit. Marketplace participation does not create access to unrelated producer-private or Joint Operating Committee-confidential information.

Crypto-based asset participation

A holder of a crypto-based oil & gas asset may receive financial statements or other disclosures only when identity, wallet control, beneficial ownership, asset rights, disclosure entitlement, and regulatory obligations have been established. Control of a wallet alone is not sufficient to establish every right in Synallagi.

Hyperspecialized Material Balance Report work

One service provider may capture industry-level balancing adjustments as controlled transactions. Another may analyze, verify, and reconcile the adjustments. Further specialists may support individual producers or Joint Operating Committees in validating their resulting records. Each specialist receives only the process, information partition, and evidence required for their duty.

Artificial intelligence preparation of a recommendation

An artificial intelligence agent may read approved information and prepare a recommendation under its own workload identity. It may not represent a partner or approve the decision unless a future policy explicitly establishes governed automated authority.

9. Oracle mapping principle

Oracle Cloud Enterprise Resource Planning can implement substantial portions of function and data security. Oracle security administration and risk-management capabilities can support role administration, analysis, access requests, segregation-of-duties controls, access certification, and audit reporting.

Synallagi should inherit and configure Oracle-delivered security where it meets the requirement, then use supported extension points to add Synallagi-specific capabilities while maintaining a consistent user experience.

Synallagi must own the domain objects and policy semantics unique to the product: Joint Operating Committee membership, representation, pooling relationships, agreement scope, working interest, transaction authority, delegation, marketplace participation, hyperspecialized service-provider work, wallet participation, crypto-based asset rights, cybersecurity policy, and cross-organizational conflicts.

10. Remaining decisions

The following matters remain open and should be developed with our user community and service providers:

1. A complete catalogue of standardized and hyperspecialized roles and duties.

2. The precise relationship among working-interest voting, monetary authority, technical authority, pooled capability assignments, market authority, and wallet authority.

3. The detailed information-classification rules for each Joint Operating Committee artifact and public disclosure obligation.

4. Actions requiring dual control, step-up authentication, independent technical certification, or Compliance and Governance review.

5. Required revocation and reevaluation timing for each lifecycle event.

6. The actions artificial intelligence systems may prepare, recommend, execute, or never perform.

7. The security consequences of the nine organizational constructs.

8. The detailed blockchain, stablecoin, and crypto-asset participation model.

9. The cybersecurity control model appropriate to Synallagi's cross-industry role.

10. The access rules for the Targeting Framework.