Thanks for that feedback. Much appreciated.
Any other viewpoints?
Anyone...
Anyone...
Bueller...
Bueller...
~PM
From: [email protected]
To: [email protected]
Subject: RE: [agi] Plans vs. Policies
Date: Mon, 16 Mar 2015 03:13:46 +0200
In brief then...
The example model by itself is no silver bullet. It is suggested that it be
seamlessly integrated with 2, other quantum-based methodologies known to me.
Recently-verified research on the potential for the 3 integration has proved
successful. Thus, it forms a 3-body approach, which is significant in its
holistic value. All 3 the base methodologies operate as a platform of synthesis
in entangled and/or disentangled states of thesis and antithesis. By viewing it
in this way, one would notice that it potentially offers full support for the
content of your ongoing discussions on coding?
In most-normal form, the ontological model already contains all the inherent,
system policies. This is an emerging by-product of the engineering process. It
is robust in that it has 2 hierarchies of control (Criticality and Priority).
There are various strategies for dealing with the hierarchy at any level of
abstraction.
The inherent policies are transcribed into simple sentences, exploiting all the
implications of the possible, compound functions (adaptive associations - not
dependencies). Except for components of the value "outcome" - never present in
the existentially mature ontological model as submitted - all other components
are potentially self recursive. Cursiveness would probably emerge at the
reductionist level. In general, all contexts contain their own, particular
level (graining) of policies. These could be tweaked in terms of coarseness,
and thus perspective. Scope of work could be managed into programs and
projects, budgets, and so on.
As such, the ontology presents as a superpattern, which is repeated
consistently throughout any life cycle of any ontological event. Any triggering
of the system would be treated as a state and an event. States and events would
hold different values of the same, related data. Ambiguity becomes a non issue.
This would provide elasticity to allow for dynamic routing within the policies
of the hierarchy and scalable, parallel processing. A basic, optimization
algorithm would come in very handy at this point. Policy statements may further
be converted into plans, but these may never be in conflict with the
superposition policy framework in the "superpattern". Thus, plans become
objectively testable for ontological viability.
Once entangled, policies assume a watchdog role. However, due to the nature of
the entangled hierachical standard, not all policies would have to consume
system resources at all times. Thus, policies could be created and destroyed
for functional value, without negatively affecting the e-governance competency
and performance. During intital systems development, policies would become
semantically embedded into processes, via rules. Processes would also include
functions, procedural workflow (program logic), and data. The value of
information (views, products, and reports) would depend on the
event-eco-systemic and end-user requirements, but be determined via the
collective elements of process.
Overall, the ontology is supported by a problem-solving framework, which is
fully integrated with the systems-management framework. The elements of the
problem-solving framework are People, Organization, Technology and Process.
These elements are synthesized by its own version of an inference engine,
namely E-Governance. For practical purposes, all policies are registered in the
e-Governance layer, but co-managed by the actual policies and a
policy-inference component, and so on to reduction. This layer provides the
external ontological boundary, or People seam, to all MMI events.
Even further, the ontology is supported by a practical, systems-management
framework, which is driven by various aspects of system events, across workflow
(content), including closed and open-looped feedback (feedback), of the
emergent value chain (competency) for each event of the instantiation of a
plan. In addition, the ontology is directly strenghtened by a researched,
systems model for generative methodology. By design, all parts of the whole
speak the same systems language, and when in synthesis, should theoretically
generate the exponential value of being worth more than the sum of its parts.
Trade-offs? So far, field research has yielded only 1, significant tradeoff.
This tradeoff occurs during the process of migrating a systems model (logical)
to a functional process (logical). The absence of reliable science for process
remains an actual constraint, but some strategies for testing the consistency
of process has been designed to deal with possible quality and integrity issues
which may arise during the migration.
Further, for AGI, I would imagine tradoffs occurring in the form of programming
language(s), frameworks, and the selection of networked platform(s). In short
then, one potential process tradeoff and x number of emerging technical
tradeoffs. These tradeoffs should be dealt with as constraints or system
requirements within the various extended architectures. These could probably be
included as a standard model in any API, or API bus. To determine its
suitability to the ontology, all architectures have to be tested for retro
compliance with the policy implications of the superpattern.
In summary:
Within this ontology, a Plans vs Policies construct cannot exist within the
operational system. At a planning decision level, they could exist separately
within the same spacetime, but still not in opposition. Thye remain
semantically separated entities in their own right. This is where planning
could be used in a staging role, without having any direct performance impact
on the operational system, other than eventually-approved workload
(semantically integrated) or demand (workflow management) on system resources.
When finally implemented (institutionalized) all polices become events of
plans. Whn implemented (stage gated) plans become events of programs and
projects. Projects inherit policy-compliant processes, sub-plans, special
instructions (as problems), functions, resources, time, costs, and semantics.
It becomes the structure for all these elements of Plan in Action (as a
solution mechanism or value chain). In purely machine terms, Project could be
satisfied by a single character, status parameter of any element within the
ontology. In psuedo code; If project status = m, set elements {a,b,c,d...} to
0, else 1. This would auto-generate a mutally-exclusive construct for that
particular event instance (tweakable via a standards-driven range and/or
threshhold of graining).
Control over project elements may be strengthened by a cross-correlating state
function, which would relatively affect the mutual-exclusivity construct in a
dynamic manner if needs be, at optimal efficiency. For example, if any of the
excluded elements should be assigned a particular 1/0 workflow status, a
particular rule may update the construct automatically, and in theory
exclude/invoke another element in one step, and/or destroy the memory-resident
element if it were not required for any event-future processing. Thus,
resource-utilization could be pruned on a real-time basis, advancing the
overall platform and layered performance to a level of effective complexity.
Thank you. This was useful to me to explain.
I hope it was generally clear enough and pertinent to your questions.
From: [email protected]
To: [email protected]
Subject: [agi] Plans vs. Policies
Date: Sun, 15 Mar 2015 16:22:46 -0700
Reinforcement Learning uses "policies" to select actions while most work in AI
Planning emphasizes the construction and representation of a "plan" which
consists of a sequence of actions (or a hierarchyof composite and primitive
actions). Kindly compare, contrast, evaluate trade-offs, and recommend the
plans or policies approach
Your rationale is appreciated.
~PM
AGI | Archives
| Modify
Your Subscription
AGI | Archives
| Modify
Your Subscription
-------------------------------------------
AGI
Archives: https://www.listbox.com/member/archive/303/=now
RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424
Modify Your Subscription:
https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657
Powered by Listbox: http://www.listbox.com
